An Eight Minute Read
To upgrade its security, an energy company approved a two-million-dollar project to install RFID (radio frequency identification) badge readers across its site. The capital committee approved a scope of work to mount readers, tie them back to a central database, and purchase two badge-making machines – one for Human Resources and one for Procurement (to make contractor badges); this was to be online by the end of the year.
Shortly after New Year’s, I was called in to work with the project team to get it unstuck.
The “team”, as it was, consisted of the project manager, the HR manager
, the procurement manager, counsel, accounting, various operating department heads, the Safety Committee Chair, and others whose titles I didn’t bother putting in my notes. The project was stalled as the budget approached five million dollars.
Procurement was causing a fuss because it wanted onsite contractor administrators to print badges (adding several machines); Legal wouldn’t sign off on until department heads approved (which they wouldn’t, without additional staff, which wasn’t budgeted). Safety was in a rut because the system wasn’t tied to individual contractor performance records; this required integrating the badge readers with three other databases, two of which had not been created yet, and would entail an entire new layer of administration.
They were months behind, the budget had bloated, and everyone was frustrated. Why?
One word: Scope creep.
Every project manager has a campfire tale regarding Scope Creep; there are as many definitions as there are projects (“I can’t define it, but I know it when I see it!”). Most commonly, Creep refers to “uncontrolled” changes in a project. It manifests in growing costs, deadlines permanently hovering on the horizon, or new-and-improved features being added. Scopes don’t necessarily wait until execution to start creeping – that potential is there on Day One.
Fundamentally, Scope Creep comes down to a violation of the project triangle. Good project managers know at the 
outset of their project they need to set boundaries around three areas: performance, time, and money. The project triangle (sometimes a “Scope Statement”, “project statement”, or “Scope of Work”) becomes a contract between the project’s sponsor and manager and the rest of the stakeholders. In essence, the agreement is, “You give me this much money and this much time, I will give you this much benefit.”
Once that is established, the triangle is “in balance”: Each leg is the equivalent of the rest. In the badge reader project, the agreement was: For two million dollars, the company would have an RFID-based security badge system installed by the end of the year. Its project triangle looked like this:
Once the “team” started monkeying with it, the performance leg grew: Additional badge machines, creating databases, and more, all increased the deliverables.
Since the triangle was already balanced, these additional demands require some combination of time or money (or both) to restore equilibrium.
Why Scope Creep Is Bad
A creeping project is a project out of control. While little had actually been outlaid on the badge reader project, the paralysis during the features debate was destroying deadlines. Ongoing discussions and meetings do cost money, even if time isn’t charged directly to the project– there are always better things to do. And once you call in the consultants, well, forget about it.
Further, Creep calls into question the viability of the project itself. This breeds lack of confidence in the project manager, the sponsor, and the team. It becomes more difficult for new projects to get funded, resources shy away from projects, and so on.
Causes of Scope Creep
There are always opportunistic stakeholders. The manager advocating linking the badge database to the safety index no doubt felt it was the ideal time push that agenda – the equivalent of saying, well, the ceiling is open, we may as well run wiring for overhead lighting. Even though it is “easy” and (arguably) only marginal Creep, it is Creep nevertheless. (Because now you need new permits, and electricians, and supplies. Then you have to open the walls to add switches…) The motives for this can be pure or more manipulative; either way, it’s Creep.
Those cases do happen, and often the drama lingers large in our memories; in my experience, though, the most common cause of Creep rests with the project manager.
Sometimes, the project manager locked the Scope before truly understanding the business needs; this means what feels like Creep is actually the project being right-sized.
Most projects – including the badge reader– creep because of either a lack of clarity or a lack of understanding of the project’s scope. These are two sides of the same coin; misunderstanding is a symptom of lack of clarity. In most projects, when Creep begins, the project manager (and/or the sponsor) has not communicated the Scope clearly and completely.
The badge project PM had already thought through the alternatives, and baked them into the Scope of Work that was approved. What he did a poorly was communicating the project’s limits. In his mind’s eye, he knew the boundaries, so he was frustrated as he was perpetually challenged by others.
Additionally, he did not use his tools to fight back. SOWs are not written in stone, and do not possess mystical powers of compliance, but they do provide documentation of the previous agreements of the project’s borders.
Fighting Scope Creep
If the cause is indeed poor communication, then the cure is simple: Communicate. But first, the project manager needs something tangible to communicate.
Begin by clarifying the Scope itself – the project triangle. Ideally, this is clarified at the outset. (If it hasn’t been, do it now.) Confirm all three legs – and double-click on each to determine the key objectives and goals. Develop and agree on unambiguous measures of success. If necessary, articulate what specifically will not be included. And document this.
Project managers run the risk of being “process weenies” by making sure this is done correctly – it can be boring, repetitive, and even frustrating – but nailing this paves the way for success later. This is imperative.
Take the Scope on the road – meet with stakeholders, resource managers, and more, to ensure that they know and understand what is going to happen. This takes time – but minimizes the schedule-destroying Creep meetings later. Additionally, the project manager can gain organizational buy-in as the triangle is presented.
Post the Scope (use the graphic) in the project’s war room. Post it outside the war room. Put it on the top of every communique. Put it in the project manager’s email signature. Depending on the scale of the project, put it on coffee cups, ballcaps, a blog… The more that people see the boundaries, the less likely they will feel the need to test them.
If others try to add features – like, say, a new database – the project manager can point to the scope (and its goals and objectives) and explain how the proposed addition does not accomplish what the project set out to do, or that while it may enhance the project, it does so at the expense of time or budget. This discussion does not guarantee success, but it stays rational and focused on the project, not politics.
At milestone meetings or other reviews, drag out the triangle and show how work is proceeding. If needed, create
one of those snazzy chevron/arrow “Smart Art” graphics to keep everyone grounded. When people begin to see a consistent image, and progress marching across it, they become reluctant to rock the boat. This also serves as a check-valve: Once the project crosses a threshold, there’s no turning back. Keeping this visible maintains momentum.
The project team should focus on adding value, not fending off Creeps. The project manager can start on the positive road: “Here is the triangle. If we do what you ask, it will do this to the schedule, or that to the budget.” If a stronger defense needs to be mounted, enlist the project’s sponsor. After all, they were key in getting the initial scope chartered, reviewed, and approved… Right?
As the Safety team became louder and more obstinate, the choices the PM saw included either capitulating (and destroying his Scope) or holding firm (and destroying relationships). If staying the course – that is, following steps one through five above – does not do the trick, there remain two options.
One is to re-balance the triangle. If adding features means the need for additional time or resources, calculate that, document it, and get it approved – in other words, go back to Step One. While this is stressful, it is nowhere near as stressful as dealing with these issues after deadlines have passed and money has been spent. (And the consultants called in…!)
The second option is to charter a second project. When pushing back against
Creep, the project manager and sponsor are not necessarily saying that the ideas are bad or the features unneeded, what they’re saying is, they are not needed now as part of this project. So draw a second triangle – and go back to Step One.
Stop the Creep
Projects, by definition, need to end. Perpetual Scope Creep puts that at serious risk. Clarifying the project’s Scope – frequently – minimizes that risk.
Clarity, and understanding, are in the ear of the beholder. It is the project manager’s job to ensure that the Scope is understood; it is not enough to hold one meeting and presume the work is done.
To say that “understanding” is a magic cure-all is, of course, naïve. There will always be opportunities (and bullies) where the Scope needs to be cracked open and re-built. By following these rational steps, that should happen less frequently. And when it does, it should be less painful than it was for that poor badge-reading team.
B-SPOKE 