©2003 Johanna Rothman, www.jrothman.com
Do you sometimes feel partway through a project, that you now have some key information that would have helped you plan the project’s tasks better?
If so, you’re not alone. Software projects typically unfold in unforeseen ways. One task might complete faster; another task might take longer. When I plan to replan — to iterate the planning — I can improve the overall project schedule.
Here’s how you can plan to replan:
- Define the five to six major schedule milestones. Choose milestones that have specific meaning for the project team, such as feature freeze, code freeze, system test start, Beta test start, and first customer ship. Outline the already-known tasks in the initial schedule for all of the project phases: requirements, design, implementation, test, beta, and ship.
- Specify criteria for each milestone. This way you will know whether or not the project has actually met those milestones. To see if my project team has met feature freeze, we hold a short project status review. For every feature, we ask, “Did we complete the requirements?” and “Did we complete the high level design?” If the answer is yes, then we have met our definition of feature freeze.
- Plan the tasks needed to get to the next date. During the requirements and design phase, I refine the planned tasks and duration for the coding phase. I start outlining the tasks in the integration phase. Once the project team agrees when we’ve met the feature freeze, I can fill in the outline of the tasks needed for the integration and test phase. Then I can start outlining the tasks for the following phases.
- Build the re-planning activities into the original project schedule. Use this project’s history to help update the project plan. This way the project team realizes the project is under control, but the project team and the project manager can continually assess and manage the schedule risks.
At the start of the project, when the requirements are clarified and the prototypes are under construction, I plan the initial activities to get to feature freeze. As the project team understands more about the project, I update the initial phase tasks as necessary. Sometimes this is as frequently as every day, but it is more likely to be weekly.
I plan in as much detail for each phase as possible, as early as possible, but the plan and tasks are not frozen. During each phase, I plan the next phase’s activities in detail. In addition to continually looking at the planning activities, I measure how long the different tasks take, and where the software faults are. This allows me to start gathering data about my project while I’m in the middle of it. During the project, I use the schedule and fault data to reassess risks and refine the schedule during the project. By the time I’m in the final test phase, I am certain of the schedule required to ship the product.
For example, during the initial (requirements) phase of the project, I plan that phase in great detail and the design phase in some detail. Then, once the requirements are complete, I can finalize the design phase and plan the implementation phase in some detail. During design, I can solidify the implementation phase, and fill in the integration and initial testing phase. During the implementation phase, I can finish the detailed scheduling for the final test and ship phases. By the time the project is in the integration phase, the schedule is pretty solid, and we already have knowledge of the potential project showstoppers.
Iterative planning is not for everyone on every project. It is most useful under these conditions:
- When you have an idea of what needs to be done, but not a clear idea of how to do it.
- When you are pressed for time, and want to take advantage of project advances.
Iterative planning and scheduling can help you on projects with technical risk or schedule risk — when you don’t have enough product knowledge or historical data to plan the schedule with certainty.
