Scope management, and ultimately change control, is a critical task on the project manager’s list – every day – but one of the least enjoyable tasks we must perform. It can require an iron fist mentality and the willingness to take a hard line with the very customer you are trying to satisfy. It’s sort of a Catch 22. It can result in increased revenue, but always at the expense of a customer that needs the change to meet a business process need or requirements clarification. It can increase project profitability, but only if you are very accurate in your effort planning and estimation because it can quickly decrease project profitability. It will almost always result in a longer implementation time because more work is required – not that you’re missing a deadline because the work is required, but it will always feel like you’re missing a deadline. You can win, but it often feels like you’re losing, too.
But the bottom line is this – tight change control / scope management must happen. And here’s why…
Staying on schedule
Adding tasks to do the work, but not adding any time to the project schedule as a result of a change order, means you’ll get the work done but you won’t likely be able to deliver the project on schedule. Especially not if you need to test adequately and do everything you planned to do on the project. Those tasks that were added to do the out of scope work have to hit somewhere and the time-line takes a hit with those activities.
Delivering the right solution
Without proper change control and scope management in place, we run the risk of delivering the wrong solution. How? Consider when customer requirements call for ‘x’ and we allow that to morph into ‘y’ because of small changes the customer may think are good. Once all of those little changes have stacked up, and it comes time to test, the solution being tested won’t match the requirements. And if no change orders were drawn up, there is no trail to test against. So which is really right? The requirements? or the solution that is being tested but doesn’t match the requirements? And does anyone really know?
Project profit margin
When changes are made but not tracked – via scope management and change orders – additional project revenue is missed. Because the changes weren’t tracked, there is work unaccounted for and time-frames that should have been extended – but weren’t. What suffers as a result? Profitability. You still did the work, but you didn’t add revenue. Therefore, those costs associated with the work just hit the project budget without bringing any new dollars with it. Added cost without added revenue equals decreased project profitability.
Minimizing change orders
Exercising disciplined change control helps you to alert the project client when changes become obvious. Engaging in well-rounded scope discussion with your customer will result in wise change order decisions. What we should allow to affect the project? What isn’t really necessary? When the client knows what is a change and what isn’t – because you’re doing a good job managing scope – then they can make wise choices. Some are changes will be regarded as necessary and indispensable… others will be deemed luxuries and tossed aside.
Summary / call for input
It’s never fun to be the one who has to yell “out of scope!” to the client and come running with an expensive change order to sign. Just like it’s not fun to be the parent who does most of the disciplining in the family. But it has to be done or you’ll soon have a mess on your hands.
How about our readers? How good are you at managing scope? Do you hate it? What tips and tricks can you share that make scope management easier?
Latest posts by Brad Egeland (see all)
- Is Kanban Right for Your Organization? - September 21, 2017
- When Difficulties Arise with Project Team Members - August 13, 2017
- Why Keeping Scope Creep at Bay is Critical to Your Project - August 8, 2017
