Project Management

At this point in the project, you know what you are going to build, you have an idea of what you are not going to build, and your use cases provide the starting point to begin analyzing the structure of the software. This is the time to create a project plan, including a schedule.

Prioritizing Requirements

To prioritize requirements, consider at least these points:

• Must one use case be implemented before another? In our case, we needed to implement "Open a Project Database" before "Maintain a Project Database," because you can't maintain a database if you can't open it.

• Do you have to implement the whole use case? Sometimes you only need to implement a single scenario of a use case to enable other work to continue. For example, we only had to implement the basic flow of events on the "Open a Project Database" use case before we could begin working on maintaining the project database.

• Are there architectural or other project risks that can be addressed early? In our case, we decided that implementing the basic flow of "Record Personal Engineering Statistics," along with the alternate flow, "Create a New Task," would help us experience the most project risk earliest in the development cycle. Implementing these scenarios forced us to dive into learning about databases, Java Database Connectivity (JDBC), and other technical areas that posed risks because of our lack of experience with them.

• The most important input to prioritizing use cases is the customer input. What use cases, or parts of use cases, are most important? Which deliver the most value?

Planning

Planning is a continuous activity. Pragmatic planners know that you are most likely to succeed if you plan iteratively, starting at a high level and filling in the details as the project proceeds. RUP presents good advice on how to develop realistic plans. You develop them at different levels:

• You start with an overall plan for your project that does not include dates, at least in the beginning. The project plan describes how you plan to accomplish the work that you know about.

• The next level of the plan is developed for each iteration. You want each iteration to be short enough so that you can accurately plan work. If iterations are too long, there is an increasing chance that you will have to make significant changes to the plan before the end of the iteration.

During the Inception phase we developed a high-level project plan. ^[6] We also developed a detailed iteration plan for just the next iteration. At the end of each iteration, you assess what you accomplished, adjust the project plan if necessary, and make a detailed plan for the next iteration. This process avoids unnecessary and often massive rework of plans.

^[6] RUP defines a Software Development Plan, which includes the Project Plan. We did not create the more complete Software Development Plan for this project.

Once we prioritized the use cases, we assigned them to a proposed series of iterations. We had a rough idea of how long the project would take, the functionality we wanted to put into the project, and some initial guesses on the difficulty. We used this information to create the project plan. Using guidance from RUP, and prior experience, we decided to plan for six iterations: one Inception iteration (our current iteration), one Elaboration iteration, three Construction iterations, and one Transition iteration. This initial plan is only an estimate. You may find later that you need more or fewer iterations.

Starting with Elaboration, we scheduled use cases, or parts of use cases, for each planned iteration, through Construction. This activity is similar to a bin-packing problem. You want to put as many items as possible into the available space. Imagine that you are standing in front of a kitchen table and a set of items. You place items on the table in order of their value. To add an item, you find the appropriate place and push down towards the less valuable pieces to make room. Something falls off the edge of the table, but it's the least valuable item. If the items turn out to be larger than you expect, then again the least valuable items get pushed off the table. This is a simple way of understanding the value of iterative development.

Figure 5.8 is an excerpt from the simple project plan we created. The items in the plan are taken from the iteration plan. The project plan "rolls up" the information in the iteration plans and provides additional information, such as planned resource allocation. After our Elaboration phase, we decided not to update our project plan because for our small project it would have meant duplicating work. As we have said before, this does not mean that we did not have a plan. It just means that we decided not to make it a physical artifact. For our project, there was not enough extra benefit to warrant the separate plan.

Figure 5.8. Our initial project plan

Along with the overall project plan, which will constantly change throughout the project, we created a detailed iteration plan for our one Elaboration iteration. As in the Inception iteration plan, it contains a list of what we intend to do, who will do it, and when we expect it. It also contains a short description of how we will assess the success of this iteration.

Risk

Risk is a key concept in software development. Risks are those things that can cause your project to fail. ^[7] We want to build and deploy valuable software as quickly as possible. If we try to go too fast, we risk delivering software that has too many defects to be useful. If we go too slowly, we risk not delivering at all, or we risk the customer canceling the agreement. If we adopt new technology or techniques, we risk making mistakes. If we don't adopt new technology or techniques, we risk being left behind by our competition.

^[7] The RUP 2003 Glossary describes risk as "An ongoing or upcoming concern that has a significant probability of adversely affecting the success of major milestones."

The Risk List is a key artifact in RUP. Like most useful artifacts, it is a living thing. You don't just make a list of risks, agree on them, and file them away. In fact, every time we ignored our own Risk List, we ran into trouble. You continually revisit the Risk List to ensure that you are working to reduce risk and that you can deliver working software to your customers.

The Risk List can be informal. However, we recommend that you write it down, and keep it where people can access it, perhaps on a project Web site. Figure 5.9 shows a portion of our initial Risk List. The rank shows the risk's priority. When the rank is 1, we believe there is a high probability that the risk will be realized, and that the effect of that realization will be severe. A value of 5 means that the risk has little probability of occurring or the effect is not severe. If you create a large set of risks, you may choose to assign separate values to the severity of the risk and the probability that the risk will occur. Because we had a small set of risks, we decided to combine the two values. On our Risk List we also included:

• A description.

• An indicator so that we know how to identify the risk, should it be realized.

• A strategy and contingency showing how to either avoid or mitigate the risk. This point is especially important: If you can anticipate the risk, you should also figure out how to keep it from happening or how to minimize its impact, and you should do it before a crisis arises.

Figure 5.9. Sample risks

Each team needs to adopt its own standards and decide how to use the Risk List. The important thing is to keep a Risk List and to use it to help your team on the path to success.