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
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.