What to do when Scope is Fixed

Sally was a prospective customer of mine. She worked for a high profile but rather old school company and wanted a fixed price contract. Sally genuinely thought her business analysts had nailed down the scope and was confident nothing would change. From her perspective all I had to do was price the work and deliver the product. Sounds perfect except Sally was wrong. My experience is that, fixed price or not, scope is never fixed. Pretending nothing is going to change is a form of self-delusion. Sally was deluded. What should I have done?

Here are some options.

Talk about the inevitability of change

Don’t do what I did. This was early days in Agile and not many people had heard of it. I had. And I had embraced change. So I explained to Sally about the inevitability of change and that my shiny new process could cope with that inevitable change and that this would allow me to deliver with certainty in the face of a changing world.

Now-a-days that strategy might work. Things do change and the Agile principles are now widely disseminated and understood. So even in a context of a fixed price contract a potential customer might not be alarmed by talk of change. This might even be what they want to hear from a vendor.

Back then, and probably with some old school prospects even today, it was exactly the wrong thing to say. Sally didn’t hear pragmatism, resilience in the face of complexity, and confidence. She heard risk. A lot of risk. For her and for her company. I didn’t land the deal.

Walk away

Sally and I were suffering a clash of cultures. In her world change was bad. So bad we weren’t even allowed to talk about it. In my world change was to be expected and it was only sensible to put it on the table and talk about it.

I could have walked away when I realised how far apart our assumptions were. Accepted that this just wasn’t my kind of customer. And in fact that doing work for her would be hard and potentially risky for my company.

I could have walked away but I wouldn’t have got the work.

Build change in

Okay I didn’t get the project with Sally but I did lots of others. Usually fixed price. And I made these relationships work despite the inevitable scope changes that comes with software development.

Sally was wrong but I didn’t have to tell her she was wrong. Nor did I have to walk away. I learnt, when working with other customers, to build change into my process without making a big deal about it.

I have two simple guidelines for change control of scope:

  • People on the ground control scope via requirements trade off
  • Escalate on money and time

The new bit is the first one of these. As long as the contract allows a quick change control process by people on the ground then change can happen easily.

If all changes have to go to a change control board then the initiative is doomed. If that is what the prospect wants then you really should walk away.

This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.