Scoping Scrum Projects (Part 1) – Things Change

Most projects are doomed from the start because they aren’t scoped properly. Clients will always want to know up front how much something is going to cost, and how long its going to take. This is perfectly acceptable, assuming you follow the right steps and set expectations properly. An all too common method to provide this is to measure the coastal wind speed, roll a pair of dice, split two card decks, and chisel a time and cost estimate into a stone tablet. This phenomenon is known as the “Fixed Bid Project”.

Clearly, measuring the coastal wind speed has nothing to do with determining how many resources its going to take to implement a fixed set of features within a fixed time frame. However, committing yourself to a fixed amount of time and money based upon a supposedly fixed set of requirements that are guaranteed to change isn’t much better. When dealing with projects that are heavy on the creative, the problem is exaggerated even more.

The problem with Fixed Bid projects is the assumption that cost, time to deliver, and features/deliverables are constant. For a variety of reasons, requirements are going to change throughout the lifetime of any project. New requirements, change requests, and overlooked details will add new complexities and complications to every project. Everyone “knows” this, yet it routinely gets overlooked when the project is being scoped. This is usually because people aren’t sure how to account for it, and figure they can deal with it later. In actuality, “dealing with it later” means running your teams ragged trying to meet a date that shouldn’t be feasible, all for a smaller profit margin because you’re using more resources. Good times.

This is a very solvable problem. Fixing it turns stressful and tiresome projects into ones that you actually enjoy working on. If you embrace your variable by planning for changing requirements, you can still provide a fixed cost, with a fixed date. For real.

Ready for more? Then continue on to Scoping Scrum Projects (Part 2) – Great Expectations.

Submit to: