Many managers do incomplete jobs at planning, or they do not manage the plan once it is developed, or they do not handle change appropriately. Each of these mistakes will affect predictability. I have seen some organizations that embrace some of these techniques as a facade for "it will get done when it gets done". The problem is that your CFO, VP of Sales and customers cannot plan appropriately in that kind of environment. Your company needs predictability in order to succeed.
I am a lot less interested in the form you use to plan than the functionality. All of these techniques can be applied using almost any method. Here are some basics:
- Do not commit to a date until you have preliminary specifications and detailed schedules
- Make sure every stakeholder physically signs off at each phase
- Adopt a train model
- Don't make top-down dates
- Complex projects require very detailed planning that will change
- Manage each slip with urgency and importance
- Deal with major changes as if you were starting anew
I have talked many times about the proposal and definition phases of a project. You cannot have predictability without specifications. Those specifications must be good enough to ensure you hare heading in the correct architectural and product direction. They must also be good enough to create schedules. The schedules must prove that you can make the target date. You must work with the information you have at the time and understand that it will change. The schedules should be manageable (< 2 week tasks, measurable deliverables, etc.).
Don't assume that verbal or incidental communication is enough to get buy-in from your company. Get a signoff sheet for each phase in writing. Make sure development, QA, docs, architects, sales(customers), support, and the CEO are all in the loop. It is awful to find out after you have spent money on developing something that you have done the wrong thing.
Feature driven releases often slip. If a major feature slips and the release slips, then there is pressure to add more features since it will be a while until the next release. Adding late features can cause more integration work and potentially more slip or worse yet cause quality problems. Separate features out from releases. Make releases time based with a shorter cycle (3 months). With a time based release, the features that are ready can go out. Big features can be developed independently. You can respond to customer needs more quickly. The train model requires adequate automated testing to be successful in order to reduce the overhead of more frequent releases.
Top down dates don't work. Schedules must be bottoms up. Managers must help there teams make aggressive but accomplishable schedules. Managers must help make trade-offs around function, quality and resources and have substantive business discussion to achieve the right balance. Don't commit until everyone on your team can look you in the eye and commit. This is a pay-me-now or pay-me-later issue. It is more than a burn-out issue. It is again about predictability.
Complex projects need detailed schedules. Even if they go out two years. Schedule re-scheduling events for long projects. If you use Agile, you can translate detailed schedules into sprints but you still need the homework upfront. You need the exercises to get predictability. The schedule is really a step-by-step design. It makes your developers think. It allows your team to identify many dependencies and resource issues upfront. It will change -- get over it. There is no free lunch. You cannot have predictability with coarse grain tasks. You cannot have predictability without having your best guess at the details upfront.
You need to manage the plan. Most slips start from day one of the schedule. Require your team to have at most two tasks open per person at one time as they accumulate risk (this may require scaffolding). Require that each slip have a mitigation plan on a weekly basis. Do not shove all delays into a bucket to be dealt with later. Your team needs to adjust quickly to issues.
Finally, if you have major changes including features additions or architectural surprises, you need to go back into a planning phase. Never assume you can just add it on. Do the resource planning, specifications and schedules. Do new signoffs. Anything less will affect predictability and cause slips.
We all face these issues. True leadership in planning is the foundation for success for your team.
More later ...
