Scope Creep of a Different Kind

Scope Creep of a Different Kind
By Literal Thinking

Scope creep is often the bane of every project manager’s existence. High on project managers’ hate lists are the project sponsors, business process owners, and end users who seem to think that there is no time limit to the introduction of new requirements. This, while at the same time querying why the project takes so long to finish and costs so much to complete.

However, there are some project managers who not only tolerate, but sometimes even spearhead and encourage, scope creep. This typically happens when a project manager also wears the account management or business development hat. So while their project management side may want to complete the project on time, scope, and budget; their account management or business development side aims for more revenue and continuous work.

Take the case of Simon, who was enterprise applications manager of a large multinational firm. The company was implementing a customer relationship management (CRM) system that was to be rolled out globally, and Simon was leading the pilot implementation. The pilot had a fairly generic scope, the aim being was to deliver the solution to all locations and customizations done at country level.

This was good enough as a starting point, but Simon kept introducing module after module of additional requirements that extended project timelines and bloated project budgets. Simon argued that the scope creep was necessary to ensure the quality of the finished product. In truth, Simon only wanted to ensure that his department’s budget and personnel are maintained, if not increased.

Simon’s initial attempts to expand the pilot’s functionality easily passed the change request process. But the module expansions not only extended timeline and budget requirements, these also introduced various layers of complexity that likewise introduced additional deployment risks that required mitigation. And often, Simon’s risk mitigating action was the introduction of yet more components to the pilot module.

The scope creeping exercise eventually got out of hand, as what was supposed to be a six to twelve month pilot project had entered its third year with no clear end in sight. Alarmingly, Simon was still introducing additional, “risk mitigating” requirements. Not only that, he grew to become more and more adamant and insistent on these change requests. Ultimately, management decided that the only way for the project to be completed was if Simon was let go.

Simon was quite well known in the industry, so he did not find it difficult to find a new job after his dismissal. His next assignment was as a contract project manager with a national electricity distributor. The company was looking at building its own custom CRM solution, as most of the products offered in the market looked too expensive and complex for its requirements.

Even before Simon joined, the project had already been budgeted and scoped, with the charter and statement of work already approved. Simon arrived at the commencement of business blueprint, and his initial task, aside from slowly taking over the management of the project, was to facilitate the workshops with subject matter experts (SMEs) and key users.

A mere four weeks after joining the project, Simon started questioning the project’s scope and pointing out what to him were big gaps between the proposed solution and the business’s requirements. His points were initially taken on board, and he was given significant leeway in re-scoping the project.

But then, two months later, Simon was still documenting requirements and conducting workshops, with no clear end in sight. This frustrated the project sponsor, as it became apparent that Simon was not only allowing the SMEs to introduce additional requirements, he was actually encouraging them to, without regard to the limited resources allocated to the project. Another month of yet more workshops later, Simon was advised that his services were no longer required.

On the surface, project managers like Simon either hold scope restrictions in contempt, or have a high level of customer orientation; it’s likely that neither of these is true. Rather, it’s more plausible that the likes of Simon just want to ensure their indispensability by continuously churning out work requirements. As with Simon’s case, this can sometimes backfire badly and can lead to them being dismissed rather quickly.

Literal Thinking is a blog that aims to present real stories of workplace follies. While we may occasionally post some interesting high profile cases of corporate missteps and failures that we find in the news, our focus is more on typical working day experiences of typical working people.

Our goal is not to name and shame, but to share stories and experiences in the hope that the reader is able to take away some valuable, practical learning that they can apply in their own workplaces. So they can go to where others have previously gone to and failed, and succeed.