I love it when a plan comes together --- what the heck is planning?

 “Planning is everything. Plans are nothing.”

Estimating and planning are critical to the success of any software development project of any size or consequence. Plans guide our investment decisions: we might initiate a specific project if we estimate it to take six months and $1 million but would reject the same project if we thought it would take two years and $4 million. Plans help us know who needs to be available to work on a project during a given period. Plans help us know if a project is on track to deliver the functionality that users need and expect. Without plans we open our projects to any number of problems. 

(I bet everybody knows this already)

Yet, planning is difficult and plans are often (more or less) wrong.

Teams often respond to this by going to one of two extremes: they either do no planning at all or they put so much effort into their plans that they become convinced that the plans must be right and anything done, even slightly, not as per plan is taken as a serious, punishable by death offense

The team that does no planning cannot answer the most basic questions such as “When will you be done?” and “Can we schedule the product release for June?” The team that over-plans deludes themselves into thinking that any plan can be “right.” Their plan may be more thorough but that does not necessarily mean it will be more accurate or useful.

That estimating and planning are difficult is not news. We’ve known it for a long time. In 1981, Barry Boehm drew the first version of what Steve McConnell (1998) later called the “cone of uncertainty.”

The above figure shows Boehm’s initial ranges of uncertainty at different points in a sequential development (“waterfall”) process. The cone of uncertainty shows that during the feasibility phase of a project a schedule estimate is typically as far off as 60% to 160%. That is, a project expected to take 20 weeks could take anywhere from 12 to 32 weeks. After the requirements are written, the estimate might still be off +/- 15% in either direction. So an estimate of 20 weeks means work that takes from 17 to 23 weeks.

The Project Management Institute (PMI) presents a similar view on the progressive accuracy of estimates. However, rather than viewing the cone of uncertainty as symmetric, they view it as asymmetric. They suggest the creation of an initial order of magnitude estimate, which ranges from +75% to -25%. The next estimate to be created is the budgetary estimate, with a range of +25% to -10%, followed by the final definitive estimate, with a range of +10% to -5%.

Why do it? (as opposed to Just Do It!)

If estimating and planning are difficult, and if it’s impossible to get an accurate estimate until so late in a project, why do it at all? Clearly, there is the obvious reason that the organizations in which we work often demand that we provide estimates. Plans and schedules may be needed for a variety of legitimate reasons such as planning marketing campaigns, scheduling product release activities, training internal users, and so on. 

These are important needs and the difficulty of estimating a project does not excuse us from providing a plan or schedule that the organization can use for these purposes. However, beyond these perfunctory needs, there is a much more fundamental reason to take on the hard work of estimating and planning.

Estimating and planning are not just about determining an appropriate deadline or schedule. Planning—especially an ongoing iterative approach to planning—is a quest for value. Planning is an attempt to find an optimal solution to the overall product development question: What should we build? 

To answer this question, the team considers features, resources, and schedule. The question cannot be answered all at once. It must be answered iteratively and incrementally. At the start of a project we may decide that a product should contain a specific set of features and be released on August 31. But in June we may decide that a slightly later date with slightly more features will be better. Or we may decide that slightly sooner with slightly fewer features will be better.

A good planning process supports this by reducing risk, reducing uncertainty, supporting better decision making, establishing trust and conveying information.

Now, how does a plan do all that (see above)? and how does one make it ( good plans are so hard to come by, one cannot simple google it up :) )? Read the next post (whenever i blog it!)



Comments

Popular posts from this blog

Multitasking causes further delays in projects ( a logical deduction?)

A list of problems with traditional planning (which I have actually experienced more or less)...what the heck is planning? - III