Incremental delivery planning is not an oxymoron. You just plan the soon-to-happen tasks in detail, and keep the distant tasks more vague. Does this make sense?
Rolling-Wave Planning
Johanna Rothman has posted an article that provides a good introduction to rolling-wave planning. She explains that she manages incremental projects with biweekly deliveries, and manages the project schedule four-weeks out. Each week, she updates the plan. At the beginning of the project, she outlines the milestones (which are subject to change in incremental projects). She only goes into details on the tasks that will happen in the next four weeks.
Johanna describes two reasons for picking four weeks. First, less time provides less visibility into project risks. And more time leads to more errors (and more changes to the plan). She suggests managing tasks at the 1 to 2 day task-size.
Quick Thoughts
Johanna’s ideas are good ones. We should always have a detailed plan for the current delivery cycle, as well as the next delivery cycle. This allows us to manage requirements changes and the impact of changes.
If we are using a monthly iteration cycle, that means two-months of detailed planning.
When we complete one cycle, while the development team starts to work on the (now) current plan, the project manager is working to build out the plan for the next release. This begins (for the project manager) by meeting with the product manager to identify any changes in prioritization, scope, or content.
As the (now) previous release was coming to a close, the product manager should be meeting with stakeholders to manage expectations about what is included in this release. This communication should be a reminder only. The product manager will also let the stakeholders know what is being developed in the (now) current release.
When the release is delivered to the stakeholders, the product manager will get the feedback needed to adjust priorization or make requirements changes. Those changes will make it into a future release. If they are critical, they could potentially be worked into the “next” release – although that may cause some process pain for the project manager.
So, at any given point in time, we have the following roles and activities:
- Stakeholders review previous release (release n-1) and provide feedback to product manager.
- Stakeholders are informed of content for the current (release n) and the next release (release n+1).
- Development team works on defined plan for the current release (release n).
- Project manager is defining or managing the plan for the next release (release n+1).
- Product manager is updating priorities and managing requirements changes for the release after that (release n+2).
- When urgent changes are required, the product and project managers will coordinate to make changes to the next release (release n+1).
Scott,
Thanks for the link to the rolling wave. In aerospace RW is the core process for planning. But for it to work, the entire plan needs to be in place at some level of granularity. The out-months (planning waves) still need to be detailed enough to determine risk, dependencies, resources and cost.
Johanna’s yellow stickies are similar to the Program Events of Integrated Master Planning. The IMP defines the maturity assestment points, the Significant Accomplishments needed to provide the planned (or desired) maturity, and the Accomplishment Criteria for judging the success of these accomplishments. Then the tasks (work) needed to deliver these accomplishments is detailed in the current and planning waves.
The key to success is to not see the milestones as points in time but as the delivery of specific levels of maturity. RW then describes future levels of maturity in terms of past accomplishments and allows reassessment of these needs from past performance and deliverables.
RW should not be used as an excuse for “not thinking in detail about the future.” This seperates planning from scheduling – which has turned into a red herring in the agile community. Schedules are the executable actions that implement a plan. The plan is alway vague, changing, and reacting to the future. The schedule defines the work actions to produce the current deliverables.
This technique is great when the project is full of uncertainty. We managed the IT projects associated with a major program recovery this way (although we used a 6-week increment). When we started the recovery, the client identified over 100 distinct IT initiatives that needed to be completed. We reviewed the resources available and decided that we could realistically tackle 6-8 at a time, so the management team of the program prioritized their top initiatives, and I worked with the IT group to plan them out and then tracked the plan. When we were 1-2 weeks out from completing each 6-week iteration, we would meet and decide on the next wave of projects (sort of a Pareto Principle meets Portfolio Management kind of thing). It actually worked very well and kept the client out of litigation as they were able to recover the project and save face.
Thanks guys for reading, and thanks for the comments!
Glen, when you are talking about milestones as ‘levels of maturity’ – what do you mean? Can you offer an example? I think about the ‘vague’ long range milestones in terms of high level requirements (but not tasks). As priorities shift, they can shift too.
Timothy, great to hear another anecdote of success. I used this a couple years ago with 3-week cycles to great success. The project had about 250 SRS-level requirements (and roughly 3 implementation tasks per requirement), and four developers on the team. We managed the project through 7 or 8 cycles, and we were able to easily manage customer expectations while adapting to their changes.
Scott,
The maturity based planning processes found in IMP/IMS define Program Events (PE) as “maturity assessment” points. In the spacecraft construction domain, Progarm Events follow a standard path: Systems Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design Review (CDR), First Review Fabrication Review (FRF). The mass of the spacecraft is an important piece of information for many reasons, not the least of which is “how much fuel to we need to get the orbit?”
At SRR we may know the mass to -10%/+25%, at PDR -5%/+10%, at CDR -2%/+5%, at First Article we can actually weigh it. This is an increasing maturity of the attribute of mass. As a planner, there will be Significan Accomplishments and their related Accomplishment Criteria (exit criteria for the underlying tasks) that move the spacecraft mass along its path of maturity. Planning on knowing the mass to -1%/+5% at PDR is simply not possible – its too early in the design process for that level of maturity.
Now in the IT world, let’s say we’re deploying an ERP system. At the first maturity asessment point (since we’re buying this thing there will be little development, but lots of configuration and setup). At the first Program Event, we’ll need to have all the tier one suppliers on the system with EDI purchasing of their products. The success of this “maturity” is defined by the SAs and ACs for the effort needed to get them one. We can then assign a “value” to having met that level of maturity. Usually soem sort of Earned Value can be developed for possessing that level of maturity.
At the next maturity assessment point, we may want 100% of the Tier Two suppliers on line and operable. etc.
In the airframe business (F-22 is a good example), the contractor gets paid for meeting pre-defined levels of maturity. The Award Fee Management process is focused around meeting all the Program Event criteria for a specific set of capabilities defined by the level of maturity of the work articles.
Some attributes of this maturity might include: the number of unassigned requirements to 3rd level subsystems (one of my training backgrounds is systems engineering, which starts with requirements partitioning, assignment and management). If that Accomplishment (along with others) is met, then the system would be considered at a specific level of maturity.
The planning processes associated with this approach start with the dictionary of the Program Event, define the Significant Accomplishments needed to fulfill the PE and their Accomplishment Criteria. This is referred to as the Program Architecture. It is the programmatic architecture that delivers the techncial architecture. Architecture being the Systems Engineering paradigm – how the product and processes come to gether to deliver the end goal.
With the PE/SA/AC in place, then a schedule can be built (tasks) to deliver the ACs. As each AC is completed, SA complete, and PE complete. The Program “matures” as a result of these accomplishments, rather than the passage of time and consumption of resources ($’s and time).