Posts Tagged "forecasting"

Predicting Scope, Schedule, and Cost

Posted on Jul 16, 2014 | 0 comments

Predicting Scope, Schedule, and Cost

Every project has three key variables… The three key variables that project managers must manage are typically scope, schedule, and cost. Businesses tend to create project plans that assign constant values for these variables at the project outset, therefore creating the illusion that projects have fixed scope, schedule, and cost. So before we continue, allow me to dispel a myth so we can start down the road to improvement. Fixed scope, schedule, and cost is an insidious falsehood that undermines the entire project management institution and community. Whether or not you openly admit it… This is a true statement; and I must assume you understand and have seen the truth in your experiences on real projects. We propagate this lie despite the deleterious consequences. However, I believe that there are important sociocultural reasons why we do this, so don’t beat yourself up if you still live the lie. What is more important is the acknowledgement that in the real world scope, schedule, and cost are not fixed, and we must become excellent at predicting these things for business planning and management purposes, no matter what process we use. Agile projects have a unique set of challenges in predicting scope, schedule, and cost that differ from traditional projects. This is because Agile projects are managed differently… Different in key ways that impact scope, schedule, and cost. Below are some excerpts of the relevant principles of the Agile manifesto. Scope: “Welcome changing requirements, even late in development…” Schedule: “Deliver working software frequently, from a couple of weeks to a couple of months…” With constantly changing requirements… We need a way to measure and predict the final scope of a project that not only allows, but welcomes change. Furthermore, we must deliver a working product on a shorter timescale than the 12+ months that is sometimes typical in the IT industry. Lastly, if our customers and executive sponsors are accustomed to infrequent product revisions, then it is quite likely that despite any incremental releases, we will still need to predict and communicate the future delivery dates of major product features that are in development for several months (or even years) at a time. Okay, enough build up, how do we predict successfully? I will share with you some tried and tested techniques that I have been applying very successfully at my clients for some time now. However, I must warn you in advance, these are advanced techniques that will take some time and patience to understand and apply, so be prepared to run experiments and learn from your mistakes. Create a predictive model. I have found that the best way to model Agile software product development is by first assigning a relative point scale to user stories, which we refer to as “Story Points.” Numerically speaking, using a fibonacci scale seems to yield the best predictions, so we will use that scale. It’s important that this step is done correctly, and that the story points are relative to other user stories, not a point of reference, like “1 point is equal to 1 day of development.” Instead, a 1-point story must be roughly equivalent in effort to any other 1-point story, and a third less effort than a 3-point story. On Agile projects it is wasteful to break down long-term projects into fully defined user story backlogs because we expect detailed requirements to change, so we must also assign relative sizes to larger work items (I will use the term “feature”) that we haven’t broken into user stories yet. We can use the same fibonacci scale, but to avoid confusion, I recommend...

Read More