Project Management with the IBM Rational Unified Process: Lessons From The Trenches - page 59


Summary

  • Remember to stay focused on the goals of the Inception phase. If a vision has already been established, try to determine if it can be achieved with the time and resources provided. If a Vision Statement has not been developed, help your customer create one.

  • Try to avoid fixing price, duration, and functionality for the entire project during the Inception phase.

  • Communicate the vision to your team, and obtain their commitment toward achieving the vision.

  • Familiarize the team with the customer's businessnot just in terms of requirements, but in their day-to-day professional lives as they relate to the project.

  • For medium to larger projects, establish a project Web site. The more dispersed the stakeholders (including the project team) are, the more they will benefit from a project Web site.

  • Decide how to customize the RUP process for your project. Identify the artifacts from the RUP your organization will use. It is not necessary to adopt every artifact suggested by the RUP. In addition, your organization may have other ideas for artifacts that should be adopted on the project.



What's Next?

Chapter 8 discusses the types of risks encountered on software projects. The sources of risks are identified and explained. The RUP places great emphasis on identifying and managing risks. If you're concerned about risks (particularly if you're a project manager), I invite you to peruse the next chapter.



Chapter 8. Identifying and Managing Risks

Some projects never reach a successful conclusion because of failure to identify or mitigate specific risks. As software projects grow in size and complexity, project managers must be aggressive in identifying and dealing with these risks. This suggests that a comprehensive approach must be taken for each project.

To meet this challenge, I recommend taking a proactive approach to identifying the risks. On small to medium-sized projects, the project manager usually leads this effort. Large projects may have a dedicated risk manager role for this purpose.

Complicating any risk management strategy is the fact that risks can come from nearly any source. The following are some examples of sources of risk on an outsourced project:

  • Technical risks. These risks are usually the easiest to identify and mitigate.

  • Unknown risks. "You don't know what you don't know" is a common phrase that applies here.

  • Political risks. These are perhaps the most difficult to identify and manage.

  • Funding risks. Unexpected or unplanned changes in funding can easily derail a project.

  • Business risks. If the project's success results in lost business, or the product reaches the marketplace too late, the project's success may result in a contractor's going out of business.

  • Schedule and cost risks. I have placed these in the preceding category because they are very common risks and are closely related.

  • Dependencies on external sources. This could be another contractor, a vendor, or any other external source providing a critical resource to the project.

This chapter discusses ways of identifying and managing these risks.



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.