Just being ready to run does not mean you know all of the requirements.

Just being ready to run does not mean you know all of the requirements.

When I recently asked a group of people the question “What are the two largest issues in project estimation?” I received one response more than any other: requirements, prefixed by words like unclear and changing. In the eight years I have been hosting the Software Process and Measurement Cast I end each interview by asking what two changes could be made to make it easier to deliver better functionality (the actual words vary), and requirements are one of the culprits that appear over and over.  The requirements/estimation conundrum has not changed much over the multiple decades I have been in the software development world.  We have described the budget, estimate and plan continuum that most large projects follow, the estimation “problem” follows the same continuum.

Most large organizations have follow a cycle of budgeting for projects. Plans are immediately put into motion based on the budgets including “guidance” provided to the markets in public companies. The budgets become part of how executives and managers are paid or bonused. In IT, projects can make up a significant portion of C-level and other managers budgets.  Projects at this level generally represent concepts and at best are estimated based on interpolations from analogies. However estimates of cost, duration and revenue are generated by a lot of thought and hardwork.  Anyone that has been in the business knows that the scope of projects at this point are dynamic, But even this early on, the die has begun to be set.  

As programs and projects begin, a better understanding of the central concept is developed.  Based on that better understanding the budget refined however the refinement generally occurs within the boundaries developed and placed in the budget.  I have known project and program managers that tried all sorts of techniques as they fought to respect the stakeholder’s central concept and the need to meet the numbers. Techniques include sourcing decisions (offshoring), buying packages or even shedding known scope.  All of this activity occurs as the concept and the underlying requirements evolve. This issue occurs both in industry and government.

As work begins budgeting and estimating shift to planning.  In waterfall projects, estimators and schedules build elaborate work breakdown plans that help guild team members through the process of delivering value. Each requirement and task is estimated to support the WBS.  [WBS?] This type of behavior also occurs in some pseudo-Agile teams. For work that is highly deterministic this approach may work well, however if the business environment is dynamic or requirements evolve to more fully meet the product owner or other stakeholders needs, it won’t work.

The natural tendency is to eschew budgeting and estimating, to change how public companies report and how executives are paid.  This will happen, but not overnight.  In the interim the best option in most cases is to manage the boundary between estimating and planning using tools like release plans and minimum marketable/acceptable products.  The release plan needs to identify what has to be delivered (minimum marketable/acceptable product) with the nice to haves acting as the buffer that is managed to meet the corporate promises. This approach requires all parties to change some behaviors, such as over-promising by both IT and stakeholders and treating IT less like a factory and more like a collaborative venture.  Both are difficult  changes but just holding out for better requirements has not worked for decades and probably won’t get better soon.