Project Practitioners > Project Management Survival Tools - Part C (Planning Iterations)

Project Management Survival Tools - Part C (Planning Iterations)

By Matt Glei

As a project manager, you face many challenges in a project. Each of us can use all the help we can get. For this 3rd post on this subject, I'd like to focus on the value of iteration planning / iterative development.

One of the most difficult parts of project planning is breaking the project up into appropriate-sized pieces or phases so that the team does both the right things and does things right. In the classic waterfall model, the first biggest challenge is to essentially fully understand and specify the system, then plan the execution, then execute. In many cases it is difficult to understand enough detail until the design effort is underway to plan all parts of the project.

The rolling-wave method of planning is supposed to help for these uncertain projects. The essential goal of this method is to do solid high-level project planning, but then dig in and do more detailed planning on the earlier, better-understood iterations. There are no passes, however, on what the plan needs to accomplish. You must still have a solid definition of what the final delivered features are or must accomplish (even if you don’t yet know all the details or how they will be accomplished).

You must also do a certain level of due diligence to understand the key technical and schedule risks and factor them into the project plan. For example if you face fundamental design risks, you should move these into the earlier iterations so you can resolve the issues or remove technical risks as early as possible. One example might be to prototype a new data processing architecture to determine if it will support the throughput needed. Although not completed, the design prototype can be evaluated against the goals.

The challenge in completing the iteration plan is to determine which chunks of the design will be in each iteration , how long each iteration should take and how the team will gauge progress during and at the end of each iteration. The project manager also has to allow for the identified risks and move to avoid or mitigate them.

Recently I have heard that when people first start using Agile techniques, they sometimes jump into the first iteration without enough context. Experienced Agile project managers have told me not to forget "iteration 0," the one where you not only plan the 1 – n iterations, but also do enough of the fundamental design / architecture so that the team is oriented to the process and that basic agreements on the overall direction and approach have been reached. Even though subsequent sprints / scrums / iterations will include new information and discover new issues, not everything can be made up as you go along. One example cited was spending some time with the team working through the user interface approach and philosophy before jumping in to the first iteration. This can prevent a lot of rework and redesign later because the philosophical interface has been agreed to – not a full GUI specification, but basic approaches. Elicitation of good use cases can help frame the problem well enough to develop these fundamental rules.

At the end of each iteration the team should evaluate the risks resolved, new risks, issues or defects identified and how they will be dealt with in future iterations. This (hopefully minor) re-planning should result in slight tweaks to the original next-iteration plan. Because all is not understood up front, the project manager should not assume full allocation of resources. Instead the PM should assume that resources can only commit a percentage of their true capacity, since new tasks will come up and be added to future iterations. The farther out or riskier an iteration is, the less you should commit resources full time up front. One way to do this is to assume that for the first iteration each team member is available 100% of usable time (allowing for meetings, administrative time, vacations, holidays, etc.). For the next iteration assume a lesser percentage based on risk and level of uncertainty, maybe 75 - 85%. And so on. The goal is not "padding" the schedule, but recognizing that there are tasks that will certainly be added to future iterations than cannot yet be fully defined.

Although I am no expert on the Agile methodology, it seems to resonate with development teams and may well answer management’s need to predict and demonstrate progress even in the face of uncertainty. Achieving iteration goals on time is a great way to build team and management confidence.

I’d love to hear from you about good and bad experiences with iteration or rolling wave planning techniques.

-- Matt Glei,

Related Links
This example, from an actual project, shows how to use an iterative model with time-boxing to plan and execute a project. When you need to plan a review of an early prototype, our review checklists and worksheets can help you get better results. Even agile teams need a thorough understanding of the use cases for their project, and context diagrams can help.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.