How can we commit if we don't have all requirements?

I get asked this a lot.  Project Managers are asked to provide full project plans and are asked to commit to this plan.  In order for Project Managers to feel good about this, we try to get all of the requirements up front.  This allows them to derive a schedule and a cost for developing these requirements.  This makes perfect sense right?  If that’s the case, how in the world can an Agile team commit to a project that has a fixed cost and schedule? 

Here is the assumption – if we figure out the requirements – we can derive the schedule and cost.

Is this reality?  One of the reasons Agile has been embraced by so many is that no matter how hard we try.. we can’t get the requirements up front.  Requirements are a funny beast.  No matter how hard you may try, the reality is that “real” requirements, and especially the true value of those requirements, aren’t easily discoverable up front – and are usually emergent as the project progresses.  The more people actually use and consume what is there.. the finer and more accurate the requirements will be.  This is why we like incremental or continuous delivery.  It helps us fine tune our understanding and truly focus on value – which, for the most part, would only be a guess up front.

Many organizations work to minimize their guess.  For example, you can utilize an Assessment phases – where a team may work to further decompose requirements, perhaps even creating some prototypes – this will help increase certainty – but, this might not be enough (depending on the project).

Agile projects embrace uncertainty (ironically, uncertainty seems to be the only constant in the universe).  We know that we can’t know everything up front.  We embrace the fact that we may not completely understand and therefore be able to deliver value with only an up front perspective.  So, if that’s the case – how can we have a fixed cost/fixed price project – does this mean that every project is inherently going to go on forever?

Well, no.  I’ve been a part of and have helped coach teams on fixed cost and fixed duration projects.  On these projects, time and money are your constraint – and your team will focus on providing the MOST amount of value possible within those constraints.  

How can you determine these initial constraints?  Well, you’re going to have to do some high level planning of course to take into account what the business is willing to invest for the value they receive, but also to understand “the big rocks” that need to be in the software.  I call these “big rocks” or “broad strokes” that allow me to ballpark the areas that need to be focused on to help me determine what constraints should look like.  The reality here is that we can’t really do complete detailed level planning to derive the plan – but we can made some basic assumptions, time box and cost contain the project – and focus on the emerging value and details.

I’ve seen this model work VERY well on fixed capital projects (for example) because schedule and costs are the constraint.  The variable component is functionality – but in the agile model, we can guarantee that the most valuable requirements and thus the most value to the organization is delivered. 

Agile also works to continually identify and reduce waste on a team – thus, in most cases properly executed agile projects are not only delivered on time and on budget, but also deliver extreme value to the business.