Tuesday, January 20, 2009

Project plans (part 3 of 3): Planning cycles

This is the third in a short series of blog posts which started with me explaining why I don’t like Gantt charts as a “project” planning tool and then suggesting an alternative approach.

Short term project planning (1 to 6 months)
A regular release cycle is the first step to delivering. Decide what your cycle is, 1 month, 2 months - probably no more than 3 months and do work in those chunks. Size the work to fit in the cycle. Within the release cycle have several work cycles (iterations) of several weeks length. The more variable or unknown your work the shorter your cycles.

Its OK to sketch out what will be in upcoming iterations and cycles but don’t get too attached to what is allocated where. It will change. And for that reason don’t go into too much detail - certainly no estimates.

All work that goes into the iteration or cycle is rigourously prioritised - 1, 2, 3, ... to N. (As mentioned in Run Scope Creep backwards recently.) At the start of each cycle, then each iteration, the team - and business owner - can have detailed conversations about what is to be done and how it is to be done. It doesn’t make sense to have these conversations earlier - because less is know about the need and thing might change. And it doesn’t make sense to have these conversations later because that is too late.

These items aren’t done until they are completely done. All or nothing, no bugs left to fix, no UI to complete, no db schema to revisit, etc. Done as in ready to go to customer.

Ideally each release should have its own small goal but sometimes it ends up being a hotch-potch of things. And ideally the team should commit to doing the work. Many Agile books and methods talk about the importance of commitment, I agree but... its hard to get one day-1, it comes with time.

Roadmapping: Medium term (3 months to 1 year)
For the 3 months to 1 years period create a near term product roadmap. The roadmap is a living document which should be changing. It should be marked with the time buckets of your cycles and no finer. Things can and should move between buckets but everything except the bucket dates is flexible.

A roadmap is not a direct substitute for a project plan. Roadmaps are different. They are need driven not date driven. They are an artefact of product management not project management. They are a learning tool not a commitment. They create discussion not enforcement.

And yes, sanitised version might be shown outside the company to customer but only with the caution that it might change.

Roadmapping: 1 year to 5 years
All roadmaps are rolling but beyond the next year it doesn’t make sense to have so much detail so have another roadmap for the mid-term. You can get more general, more speculative simply because more things can change. So keep your near term and long term roadmaps separate.

This roadmap should show major events inside and outside your company: planned IPO, proposed legislation changes, anticipated competitor products and major event with your major customers.

So why are the roadmaps I describe better than project plan Gantts? Well...
• They are designed to keep the debate open and keep discussion on what is needed
• They do not forecast into the future they are one scenario
• Items in on the roadmap turn into goals supporting the larger visions for the product and company
• Dates are kept vague and planning is separate from commitment

See my Product Roadmap pattern for more about roadmaps, this is part of my business pattern series.

Beyond 5 years: Strategy and scenario planning
These technique tends to work best in the short term. In the long long term where you are going, what your product looks like are a matter of business strategy. Top management should pass down some direction here. Planning for the longer term needs different tools. For the long term - 5 years or more I suggest you start with some scenario planning.

There you go, a rough guide to project planning. Some people would call it Agile project planning, personally I don’t care what you call it. If you want more details it depends on your situation so get in touch.

Project plans (part 1 of 3): Why I don't like Gantt charts
Project plans (part 2 of 3): Turn the question around
Project plans (part 3 of 3) - Planning cycles
Run Scope Creep backwards

1 comment:

  1. I find your thought very interesting. I am a PMP certified project manager and also a PRINCEII practitioner. I have been leading software development teams for the past 12 years in the US. I think Gantt and other project management tools get immediately dismissed because of misapplication in software development. As you point out, most software plans more than a couple of months out are pretty much useless. While most teams I have lead are more traditional waterfall (go ahead and cringe now), our implementations are much more along agile principles. Software projects have to be phased and planned in those short phases. Project managers call it rolling wave planning. What it really boils down to is similar to a scrum sprint with tasks laid out sequentially. I agree that this is not the typical application for inexperienced software project managers, but if you have ever lead one that works, this is the only way to consistently get it right. I have to agree that since being exposed to lean and agile philosophies, I like many of the alternatives they espouse and have been implementing them. I still think there are scenarios when tools like a Gantt chart can be applied as a communication tool to upper management even on an Agile team. It just has to be used properly. Inexperienced project managers using tools incorrectly are not much different than taking a chainsaw to do some minor bush trimming. They may get the job done, but it will not be pretty or clean and may cause permanent damage.


Note: only a member of this blog may post a comment.