Imagine you're running a system implementation project. Everything is going well and milestones are being met. All stakeholders are happy.
Suddenly a user highlights to you that the system just HAS to do something that was never planned for. It just HAS to have a field to track a customer bankruptcy status. It HAS to have a maker-checker approval workflow for modifying transactions. It HAS to have the ability to attach documents against a customer's record.
The list goes on … you're flooded with numerous change requests and you realize you have serious scope creep issues. Scope creep is one of the most common things in projects and to be honest, I absolutely HATE it. It distracts everyone from delivering the base outcomes of a project, takes away hours and hours of our time as PMs.
In this article, let's explore 7 ways which I think can help you control scope creep. I come from a system implementation point of view but you can extend these ideas into any sort of project as well.
One of THE most important ways to control scope creep is to over-communicate with your users. You see, human beings are funny creatures. When a person is constantly engaged and updated on the status of a project, he or she will be more receptive to ideas and will give you buy-in.
So imagine that you've been updating a user regularly every two days about the status of a project, the issues you've facing and how the timeline is going. If suddenly there is an additional system enhancement item raised by this user, it is MUCH easier for you negotiate and ask for say, a deferment of the enhancement.
Compare this to a situation where you don't communicate with the user at all during the project. He or she will be adamant to push his enhancement through!
Case Study: I was the project manager for a large scale core banking system implementation in a Malaysian bank. Towards the go-live date, you could not believe the number of out-of-scope change requests we captured (there were literally a hundred plus change requests).
One of the users whom I communicated with regularly and was in touch with the project actually helped me bed down many of the changes raised by other user teams. I attribute it to the fact that I had involved her constantly and she felt she was “part of the team”. So communication with your users is key in scope management.
Ok, lesson number two to control scope creep - document EVERYTHING. As a project manager, there are thousands of small discussions and agreements that take place outside of official meetings.
DO NOT agree to anything outside of an official meeting. Always minute and document agreements and decision points though a formal meeting. That way, if a user disputes that something was signed off and agreed, you can whip out the meeting minutes as proof.
I know it sounds confrontational and all, but that is the reality. Remember, people forget about things. You have to have documentary evidence that things were agreed on.
The third way I'd control scope creep is to go into detail. Exquisite detail if possible. I'll give you an example. One of the common documents we use in system implementation projects is the “functional specification” document.
Now, a functional specification document can vary in terms of level of detail.
I've seen some which are just textual, with descriptions of system functionality like “The user keys in the client name, country of birth, date of birth and then clicks the Submit button”, etc.
I've seen other functional specifications which might say “The user keys in the client details and then clicks the Submit button”.
Do you see the difference? Details matter. Especially in system implementation projects.
In the latter requirement, you can expect a whole LOT of scope creep simply because a user would not know what “client details” are. Spell them out.
Make requirements very explicit. In fact, I'd go so far as to include screenshots, rules and additional documents to clarify the requirement. More upfront detail always beats out ambiguity later in the project.
Senior management support for a project is a pre-requisite for almost ANY project you undertake as a project manager. I've seen two projects go on for FIVE years (instead of a planned two years) because of lack of senior management support.
Tip:: Make use of the “Steering Committee Meeting”. All large-scale projects should have a Steering Committee Meeting made up of senior management stakeholders. Your project sponsor (the person who commissions and pays for the project) is a key part of that meeting.
What do I mean by “make use of” the meeting? Well, if you have out-of-scope items raised which are going to make your delivery timeline slip, RAISE these issues to senior management.
Often, the ground level users raising enhancement requests have very little idea of the strategic direction of the company. Senior management stakeholders, on the other hand, HAVE a strategic view. And they CAN make the call to defer unnecessary changes and push a basic system out first. Get them to help you!
Another trick for controlling scope creep is to phase out the project. Projects have phases. You usually roll out a simple, base version of say, a software product before moving on to more complicated, advanced versions.
What I like to do is to create a little timeline on Powerpoint showing people that there ARE subsequent phases on specific dates that will allow them to roll in additional features in the software. Many of my users worry that if they don't squeeze in every last enhancement into the system by a particular date, they will NEVER get it into the system.
Well, I take them to lunch, show them the timeline with phases and educate them.
I tell them “Look, there are subsequent phases for the project. You can roll in this extra screen in Phase 2. In Phase 1, let's get the basic functionalities in first”.
Reasonable users will agree to this approach.
One piece of advice when you're faced with project scope creep is to get creative. What do I mean? I mean think creatively. Is there anything in the project which you can do to control the scope? Maybe you CAN deliver the requested out-of-scope item within the timeline if you have an additional resource sitting somewhere. Maybe the out-of-scope item can be done by the user themselves.
Case Study: As a core banking project manager for a Malaysian bank, I had this user who asked for five reports to be crafted before the project go-live date. The reports were not catered for in my original timeline and estimation. I thought hard about how to deliver those five reports and still meet the original project timeline.
It turned out that on the user's Business-As-Usual (BAU) team - there were some resources who were very strong in creating Microsoft Excel macros and scripts. I approached them to create the five reports the bank needed. We delivered the project on time - in fact, we managed to deliver eight reports instead of five.
So, creativity is important in scope control - try to find ways to circumvent or mitigate the changes which come in. It does not mean you can't deliver the change request, perhaps you can deliver them in a different way, or use different resources - like in the above case study.
Particularly for software development projects, one good tip to control project scope creep is to build in a flexible design. Make sure the software being developed is flexible. Externalise any parameters or configurations that need to be made.
I'll give you an example. One of the most common records we keep in a trading system is the “trade order” record. For example, when you buy a stock or a bond, you key the order into the system, e.g. “Buy 50 units of IBM stock for $120 each”. The trade order gets stored in the system once keyed in and there is a status tied to it - Pending, Executed, Cancelled, and so forth.
If I “hardcode” these statuses into the system, the next time some user wants to change the statuses to a different set of descriptions - say, “Captured, “Executed, Reversed” - I'll need to spend effort going into the code to change this. Externalizing these statuses into a configuration file or screen that the user can change on their own will save that development effort.
This scenario is very common in software project implementations - which is why I recommend that when designing software - “externalize” your configuration parameters as much as possible and make it easy for the user to change the system's behavior - without involvement from IT.
And that's it! I've given you seven proven ways to control scope creep in a project.
Granted, these techniques won't guarantee that your additional scope items will just disappear.
However, you WILL have a better chance of bedding them down. Every bit of additional effort you remove from a project also means an increased chance of successful project delivery. Until next time, good luck running your projects!
Are you wondering how to break into a Project Management?
Would you like to understand how others have successfully switched to a PM career?
Or discover what skills, certifications and domain / industry knowledge are required to excel in a PM role?
I’ve written a practical, easy-to-read guidebook that will help you find your best path to Project Management – one that leverages your unique skills, experiences and career background to your advantage.