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:
These questions will help you discover and identify the technical risks existing in your system. Managing Technical RisksAfter 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 TrenchesOn 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:
Discovering Unknown Technical RisksIn 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:
|