Story time!

Finally, let’s introduce you to a concept called scope retreat.

Especially prevalent in internal projects (where the organization delivering the project is also the client of the deliverable) scope retreat is where things get dropped from scope until the deliverable is no longer fit for purpose.

Why would that happen? 

Usually, it is because the project budget and schedule are fixed.

Recalling our theory of the triple constraints, if something goes wrong and time and cost cannot change, then our only option in the pursuit of functional quality is to reduce scope.

And, unlike in scope creep, scope retreat can still occur even if you follow good change management and control processes.

Here’s the story. 

I worked with a business once that was upgrading its billing system for over 200,000 clients. 

Because the software version driving the old system was no longer being supported by the vendor after a certain date, the go-live date for the new software was fixed and could not be moved.

Management, too, had allocated a fixed amount to implement the new software, an amount that was based on the assurances of salespeople that it would only cost $x.

However, when the time came to collate all the customer records, migrate the data, and set up all the new accounts – well, as you can imagine, several issues popped up to frustrate that process.

You see, the old system was on its last legs, and had been patched and hacked so many times over the previous ten years that the customer data was stored in wildly inconsistent formats and certainly incomplete for what the new system required.

And this was just one of the many assumptions made in the business case and project plan that failed the test of project delivery.

So, what did my client do?

Well, they were locked into a delivery date, as the old software provider – who had been unsuccessful in winning the new contract – was unplugging their system, and secretly pleased that the new package wasn’t as promised. 

‘Told you so!’ they said.

It estimated, too, that the cost of crashing the project was more than the organization could afford, both in terms of dollars, resource availability, and risk. 

My client also had no contractual protection against this crisis. 

As the new vendor pointed out, the new software had been priced on the assurances that the data was up to standard and ready to go.

If it wasn’t, they would have charged much more (but probably wouldn’t have won the tender, either, so it wasn’t really in their interest to challenge this assumption at the time).

All that was left to the client organization then was to retreat from scope: drop features, turn off lower priority functions, and scramble like mad to clean the data they could use (which introduced even more errors).

The result was that the billing system implementation project was a disaster. 

When it went live, not only did you have the significant (but planned for) issue of customer resistance to change – why does my bill look like this, I don’t get it – but customer invoices were just plain wrong!

The 25% of customers who were overcharged – some by as much as five times – were livid. 

The 25% who were undercharged kept happily quiet, and, in the publicity firestorm that followed, it was considered not worth the effort to hunt them down.

This was a big deal that even blew back on the government of the day, for did I mention that we were talking about an essential public service here?

And every time I tell this story to friends or at training events and conferences, I hear three more, just like it, from people who have been in the same position. 

Horror stories that bring together planning, procurement, risk, change, and stakeholders told through the lens of scope retreat. 

Trust me, this is an issue that is not just confined to the IT sector.

And the moral of the story? 

Yes, scope can creep, but sometimes, it can also be too easy to sacrifice scope to the gods of project efficiency.

For even though as a project manager you are solely focused on delivering the project without distraction, every time you make a change – whether it be to scope, time, or cost – you should reference the original business case and ask how will this change, disturb or disrupt the purpose of the project and the starting assumptions we made.

That is why each change request should be a mini-business case in its own right. 

After all, many a good project has suffered the death of a thousand micro-cuts and delivered an output that can no longer hope to solve the problem originally identified.

Closing and reviewing projects for lessons learned is what we will explore in the next Unit.