Thursday, 17 April 2014

Reverse planning

In many cases projects starts with a rough idea of the scope and a rough a idea of a deadline. Depending of the size of the project "rough" means different things, but lets say the project is about 2 years, then the deadline is probably during a quarter.
This rough deadline is quite quickly getting cemented at the end of the quarter. I will not debate in this article if this is sane or not, just stating how it often works...

Given this and the rough idea of the scope, that probably is a large part "must" and a small part "nice" (part of the "must" is probably negotiable as well since there it also common to miss-use this term).

Since 2 year is a long attention span, much to long for humans to grasp, there need to be passages where your project needs to pass. Many project models has them:
- Tollgates, mainly used to secure fundings. I.e. we have achieved this, as we stated and need this additional funding to continue.
- Milestones, project achievements.
You can also call it a Checkpoint, might be similar to MS, but can be used more freely as both internal o external of the project. Agile methods adopt this to deliveries in short intervals.

If you do not have these planning cornerstone - get them. Once you have them in your sight, the hard part (planning wise) start -> what should be ready at each MS, CP TG...
If you have TGs and MS, they are probably already defined but not necessarily very frequent hence I will not spend much time on those here. If you have them, there is achievements required i.e. you can/should consider them as a deadline.
But, as mentioned, MS and TG can be very infrequent. And in projects, when velocity is needed, you need to keep deadlines in reasonable sight - introduce Checkpoints. By introducing them, it will generate some overhead to define and following up but that is a crucial step in gaining velocity, only drawing them in a time plan is not enough (similar to planning frequent releases in scrum but not follow them through does not make it agile).
At each CP (or Scrum release) you, aside from reflecting on achievements, you also plan for the next CP/Sprint and re-visit the final plan. But working actively at these stages will enable you to grow more confident of what you will deliver when.

I guess most of this can be found in many how-to-run-projects articles and project models etc, but I want emphasize the active work that needs to be done at frequent intervals in order to gain the benefits.

No comments: