Details Matter

Why is it that after so many software projects we have that familiar "discussion" about scope creep and deadlines?  It took longer than we estimated, we say requirements changed or were added, stakeholders say they weren't, rinse and repeat.  I really drilled into this on a few recent projects and I'm starting to think the answer is more about semantics and less about passing the buck.

So, into the field.

"Tell my why you believe so strongly that requirements did not change" I asked the stakeholders.  They told me that they asked for, say, a gambling website at the start of the project and at the end of the project they still just wanted a gambling website.  The label 'gambling website' has some basic defining properties; you can sign up, you can deposit funds, you can gamble these funds and you can withdraw winnings.  We didn't add anything else to that.  WTF?

I see.

"Tell my why you believe so strongly that requirements did change" I asked the engineers.  They told me that we started off needing to register accounts, but then added age verification, geolocation, and integration to another product.  We needed to build an odds manager, but then we added price feeds, client side push, and autopopulation of recurring markets.  WTF again?

Aha.

What's interesting here is that both sides are answering a slightly different question - and both are, in fact, correct.  The stakeholders are actually saying that their goals didn't change and the vision didn't change.  True.  The engineers are actually saying the details changed and the specifications grew.  Also true.  So which one is synonymous with "requirements"?  When we say requirements, do we mean goals or details?  Do we mean vision or specification?  It's become clear to me that business-types mean vision and goals and engineering-types mean details and specifications.  Now we're onto something...

Goals and vision are what stakeholders use to assess the commercial viability of a project and to communicate their high level idea to a delivery team.  This is all quite correct, but where we go wrong is in trying to live up to delivery guesstimates made from such information.  Because, unfortunately, what dictates how much something actually costs to build is the detailed functional and architectural specifications - not high level vision statements.

A working example.

Payments system - pretty easy to describe in a vision; money in, money out, a variety of deposit and withdrawal channels and a bit of diligence around anti-money laundering etc.  You can make a bunch of quite valid assumptions about what you need to build to put this together, but when your product management starts to expand on exactly how the system will perform in real life, you can't forget to also expand on exactly what it takes to build it - these things evolve in unison.

Imagine you're building a house, you can take a guess about what that's going to cost.  Then you might talk about the materials you want to use; bricks, wood, stone - but you'd need to update your cost estimate.  How about the number of bedrooms, bathrooms, ensuits etc?  Update again.  What about the number of levels you want to build, gradient of the land, and distance from utility trunks?  Again you'd need to rethink cost to avoid surprises later.  This is such common sense in the practical, tactile world of construction so why does it escape us in other engineering disciplines?