Literal Thinking

Real stories of workplace follies

Scope creep of a different kind

Posted by A Friend on 17 April 2009

No End in Sight 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.


One Response to “Scope creep of a different kind”

  1. […] Thinking presents Scope creep of a different kind which is about “A case when the project manager not only allows but encourages scope […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: