Technical Risks


Technical risks are among the easier risks to identify and mitigate. The reason for this easier management is that most of the elements relating to the risk are under the team's control. The first step toward identifying technical risks is a close examination of the supplemental requirements. Here are some questions to ask to help you identify specific risks:

  • Does the system have particularly demanding response time requirements?

  • Does the system have to process an exceptionally large amount of data in a specific time period?

  • Do you have hardware considerations to contend with? For example, does the system have restrictive requirements for memory, disk space, or network bandwidth?

  • Does the system need to interface with hardware devices or external interfaces?

  • Does the system need to interface with other legacy systems?

  • Is a particular technology required with which the team has little experience?

  • Is a particular product or technology required on the project unproven or known to be unreliable?

These questions will help you discover and identify the technical risks existing in your system.

Managing Technical Risks

After you identify technical risks, the next step is to take positive action against them. The only way I have found to do this is to attack them directly.

More Tales from the Trenches

On one project I managed, the architect on the project determined that to meet the system's requirements, a technique known as phased transactions would need to be used. A phased transaction (sometimes referred to as a distributed transaction) is a set of two or more related transactions usually in separate databases that must be completed together. A common example is a balance transfer from a banking account. To be valid, a transfer involves a withdrawal transaction from an account maintained in one database and a deposit transaction in another database. You must have assurance that both transactions can be successfully completed, before committing them. There were two challenges, however. First, none of the developers on the team had any experience using this technique. Second, at the time, we had decided to use shareware application server software. We were not sure whether phased transactions could work with this application software.

It was clear in this particular situation that these two risks were directly related to the use of phased transactions. It was also clear after reviewing the requirements that phased transactions were needed. To mitigate these risks, we decided for the first iteration in the Elaboration phase to implement a complete thread of execution by implementing certain use case requirements that would require the use of this technique. This initial iteration was scheduled to be approximately 3 weeks long. After struggling with this for 2 weeks without success, the developers began to search for others who had implemented phased transactions with this application server software.

The developers discovered that this had never been accomplished with this particular application server software. They also found that implementation of this functionality in the application server software was poorly done and that portions of the functionality in the application server were either not implemented or extremely buggy.

As a consequence of these discoveries, this iteration was a failure. The goal of the iteration was to implement a thread of execution using phased transactions, but the team was unsuccessful. After meeting as a team to discuss what we learned, we decided that the best course of action was to drop the shareware application server software and instead use a Commercial Off-The-Shelf (COTS) solution. After some investigation, we found application server software that met all our requirements. As a bonus, the developers found lots of examples on the Internet of how to use this particular application server software with phased transactions. From that point on, the project never experienced any difficulties relating to the application server software.

What lessons can be drawn from this experience? In this case, a number of key lessons were learned:

  • What you think may be a risk may not turn out to be significant. In this example, we identified two risks related to the same technical problem. To mitigate the risks, we chose to implement a portion of the system's functionality. It turned out that one of the risks (the developers not having experience with implementing phased transactions) was trivial and not really a significant problem. The real problem was finding out that the chosen application server software could not handle phased transactions.

  • Identify and attack risks early. Because these two risks were attacked early in the Elaboration phase, it was possible to make a choice that otherwise may not have been possible had this discovery been made later in the project's lifecycle. It may not have been possible to simply change the choice of application server software late in the project's lifecycle. Changing the application server software late, after much code had been written, could have had serious repercussions. In this example, it was an easier decision to make because little code had been written that had dependencies on the application server software.

  • Early failure is good, if the failure occurs as a result of a deliberate effort of risk discovery and risk resolution.

  • Sometimes, unexpected benefits are uncovered through attacking risks. In this example, in the process of researching the problem, the developers found some useful assistance in the form of examples on the Internet.

Discovering Unknown Technical Risks

In the preceding example, the risk was clear and identifiable. What about unknown risks? How do you discover what you do not know? The answer is to use the principles of iterative development to your advantage.

Some best practices when employing iterative development are particularly applicable to risk management:

  • For risks that are known, or suspected, schedule the implementation of requirements involving those risks in your earliest iterations. This is what was done in the preceding example.

  • Have a "main purpose" for each iteration.

  • Make sure that each iteration exercises as many of the disciplines employed on the project as possible. It is through exercising these disciplinesconfiguration and change management, testing, requirements management, project management, environment, and so onthat you discover unknown risks.

  • Keep iterations short. A common mistake made by those unfamiliar with the RUP is to make iterations months long. This delays risk discovery, because it delays the exercising of each of the disciplines. In some ways, you can think of a traditional Waterfall lifecycle as the worst case of this situationa single iteration whose length is the project's entire duration! Chapter 2, "Overview of the Rational Unified Process," covered why Waterfall lifecycles delay risk reduction.

  • Be sure to schedule some time at the end of each iteration to assess what happened during the iteration. Did you achieve the iteration's main purpose? What went well, and what went wrong? Did you discover anything that bears closer attention? If so, how will you use this information? You may need to change the contents of subsequent iterations to explore any new concerns.




Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net