Article: What is Scope Creep?

Changes in Project Scope (Scope Creep) is the current leading cause of project failure globally according to the 2010 Global Survey, Top 10 Obstacles to Project Success. This article is meant as a high level overview of this complex and often misdiagnosed project obstacle.

To read the full article go to http://www.mutoperformancecorp.com/2010SurveyResults.htm

We welcome your comments. Join our blog at http://top10obstacles.blogspot.com/

On Change

“What obstacles do project managers face to successful completion of an Information Technology project?”

CIO: Government Department

I would stress that change management is a huge obstacle. So often technology is looked at like the magic bullet that will radically improve your process... but too often we just automate bad processes - and it isn't until we have started programming that the business unit start to dream up ideas to add features to the process - then everyone wants to add things... then the changes come - then the scope creep - then the delays, the costs, and the frustration...

It could all have been settled in the business case, charter, and scoping stages - but it rarely is... and granted, it is hard to see the building from the blueprints... so it's change management I think we really need to get a handle on - so everyone knows the impact of adding after the big "freeze"

MüTō Observation:

I firmly believe that 'Change is a Constant', and that means that a project manager must embrace it and prepare for it.

The PM is to be held entirely accountable to see that the change is mutually understood (by sponsors/beneficiaries, and suppliers), and to see the change through!

On Project Definition

“What obstacles do project managers face to successful completion of an Information Technology project?”

Information Technology and Services Consultant

“It is vital to define project boundaries.

Use a series of Product Descriptions to refine requirements & get Signed Agreements ... to include: Textual Description & Code ... Component Parts & Codes ... Performance Criteria ... Quality Criteria & Methods ... Responsibility for both Build & Test.

THE AGREEMENT SHOULD ENCOMPASS...
The Size, Scope & Deliverables ... How Big? ... What Features? How Many? ...By When? ... How Much? ... Quality Defined?

DOCUMENT ALL ASSUMPTIONS ... AND AGREE ON CHANGE CONTROL PROCEDURES. "

MüTō Observation:

These are among the top obstacles listed by Project Managers. I completely agree that defining the boundaries of the project, clarity in requirements, and solution (all unequivocally understood by ALL parties, equally) is tantamount to project success.

This requires a certain basic skill in the PM, called the ability to Communicate.

Just imagine the project manager that can bring parties together, and clearly negotiate the facilitate discussions so that at the end, requirements are clear to everyone, equally. Then helping to prompt the technologists/suppliers in such a way as to facilitate their expression of a solution in such a way that the sponsors/beneficiaries TRULLY UNDERSTAND what they are getting, and what it will do for them. Not to mention, the clear communication of all authority/responsibility/task accountability.

Then lets imagine the PM that can energize their team to a point that ALL issues/risks are promptly raised (instead of cya'd), and all focus is on driving the project to successful completion, not just because its a job.

Then, lets imagine that the PM can exert authority, and be on everyone's priority stack (placed on top) even when they are not around. ;)

Or, how about a PM that could do just 10% of that....

The entire responsibility for getting what you recommended done effectively, sits squarely on the PM. No-one on a project is more perfectly positioned than the PM to provide that facilitation.
But that's only step one eh?