Scope or: how to manage projects for organization success, part 1

Organizations rely on projects to remain competitive.  Projects are the way organizations deliver and realize their executive strategies.  The ability to deliver a project is the ability to compete.  Scope kills projects and projects that fail to deliver kill organizations.

Scope is one of the most important ways to manage project success.  And when projects succeed, organizations succeed.

Projects fail at an alarming rate:

  • 74% of all projects fail, come in over budget or run past the original deadline;
  • 90% of major IT project initiatives fail to be completed on time and on budget;
  • A survey by KPMG, an international consulting firm, finds globally that 56% of IT projects fail is underestimating the scale of the problem;
  • Certus, the UK IT director forum, believes that the failure rate of IT projects is closer to 90%

Why is scope so important?  When projects fail, people begin to lose confidence in their coworkers and their organization. The more that projects fail the more resistant people are to associate with new projects or to work on projects:  no one wants to fail.

This is a first in a series of scope and project management blogs to improve project delivery.  No prescription guarantees repeatable success.  Project management is not a process, but a business promise.

To understand scope we need to broaden our scope and this series will look tools, views, and principles from multiple disciplines.  After all the scope of an Information Technology (IT) department is to serve business, not technology.

The below CIO survey results are interesting.  The CIOs, however, are seeing downstream effects of an issue further upstream:  scope.  While Resistance by Employees or, obviously, No Organization Change Plan is a change management issue far bigger than any project management process addresses.  Successful change management relies on successful scope management.

How do projects fail?

Projects start with, what seems the best intention, but what happens along the way to make it difficult to deliver that project on time, on budget, or as expected?  Scope is usually the culprit.

Toby Elwin, Deloitte, consulting, CIO, Survey, Project Failure

Top Reasons for Project Failure

Scope is a fixed idea of what to deliver.  And scope can ruin projects in 2 ways:

  1. When scope is ill-defined
  2. When scope is modified (often called scope creep or gold plating)

In the zeal to start a project, people take too little time to interact with project sponsors, stakeholders, and customers to collect and analyze their expectations or the impact the project will introduce or require change to their world.

Starting the project without a detailed scope management plan is the difference between getting the project done or getting the project accomplished.

Projects fail when scope is not clearly defined.  Scope is not clearly defined when sponsors, stakeholders, and customers are not listened to or asked their needs.

Modifications to scope adds project risk down the entire project’s life.

Projects that fail increase the very real risk of an organization’s ability to compete.

What is scope?

Scope, in project terms, is simply, “what’s in…what’s out”.

When you change the scope of a project, an added feature, moving the delivery date, changing the quality criteria, you affect the clarity of what will get delivered, by whom, for whom, without understanding the impact each change has.  A project changing scope is just as negative as a trying to manage project success with a poorly defined scope.

Both poorly defined scope and constantly shifting scope will kill a project.

Poor scope definition hides the opportunity to accurately build a budget, understand the return on investment, staff the project, and manage progress against measurable objectives.

Constantly shifting scope does not allow the target to get clearly defined and no one knows what success looks like.

Scope is not a target you aim for.  Scope is the bull’s eye.  You either hit or you miss.

What’s scope got to do with it?

Scope management includes processes to ensure the project includes all the work required, and only the work required, to complete the project successfully.  Scope includes:

  • Features
  • Quality standards
  • Schedule
  • Budget
  • Resources
  • Risk

Without a clearly defined scope, projects fail to hit the bull’s eye, let alone identify the target.  When scope changes, budget changes, delivery dates slip, and resources might expire.  If scope is continually modified, how can anyone expect to deliver a project on time, on budget, and within anyone’s expectation?

Scope management includes the processes required to ensure the project includes all the work required, and only the work required, to complete the project successfully.  Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project.

Without this work upfront the project or product scope continually changes as people step forward to challenge the project or ask for change.  See Scope or: how to manage projects for organization success, part 2

Below is my first ebook, modified from a presentation I gave to the Project Management Institute Mass Bay Chapter on how to identify, manage, and control scope.  Included are tools, tips, and templates I’ve used for stakeholders management, impact analysis, communications planning, and risk management.

Sources:  A Guide to the Project Management Book of Knowledge (below).  There are better books, but this sterile guide to the Project Management Book of Knowledge is a must-have and one of the best places to begin.

toby elwin, project management, guide, project management book of knowledge, pmbok

email

{ 8 comments… add one }

  • John Burrows June 18, 2010 at 5:50 pm

    When projects fail, it can often be tracked back to an inadequate definition and agreement of the scope. In my experience, scope is left vague, because

    1) specifics often lead to disagreements disagreements.
    2) like prepping a room to paint, scoping a project is often hurried to get to the “real” work.

    Reply edit
    • Toby Elwin June 18, 2010 at 8:34 pm


      Twitter:
      Both your points really represent a risk averse approach that kicks the likelihood of project failure right off.

      Fear of disagreement is an unhealthy organization that has no diversity – if we can't talk about alternatives or perspectives with an eye towards creativity and innovation, poof there goes the project.

      Prepping a room for paint is a great analogy. The finished product is only as good as the scraping, sanding, smoothing, primer, cutting in, brush, and paint – but too many let those details get that in the way of saying we painted the room. What can't be said is painting it and painting it well are 2 different things.

      Thanks for your comments John and your posts at your site Management Leverage.

      Reply edit
  • David M. Kasprzak June 21, 2010 at 7:37 pm

    As John indicates, up-front planning is a far more efficient way to spend resources than with ad-hoc execution. I'm all in favor of creating early warning indicators so that deviations from plan (such as increases in scope) are caught early or, better yet, before they happen. The Department of Defense mandates the use of an Earned Value Management System (EVMS) to catch such things. While their implementation can be onerous, any usage that complies with the ANSI standard for EVMS should help to prevent things from spinning out of control

    Here's a link to the DoD EVMS site at Defense Acquisition University, which contains even more links to other resources: https://acc.dau.mil/evm

    Reply edit
    • Toby Elwin June 22, 2010 at 6:03 pm


      Twitter:
      Earned Value Management (EVM) is a clear, concise, and understandable way to know when and where your project is off-track, by budget, schedule or both.

      EVM desperately relies on an accurate work breakdown during the scope stage. Work breakdowns rely on the subject matter expert who is charged with delivery – as the worker, in the field, not as the lord of the manor.

      It is great you mention the DOD's use of EVM. It is unfortunate that the DOD, in a recent study of the brilliant, but unfortunately toothless, Government Accountability Office (GAO) found, in a 2008 report [click to download .pdf] that on 95 systems the average unforeseen schedule delay was 21 months and the total cost of these delays hit $295 B-I-L-L-I-O-N (billion).

      The trends GAO looked at were disturbing, in 2000 compared to 2008, the cost of delays, in absolute terms, increased 702%. The average delay in 2000 was 16 months and 2007 21 months.

      The cost of requirements changes of projects underway was a sobering, to tax payers at least 72%. 72% increase in costs [click to download .pdf].

      EVM as a tool is brilliant. It seems the cobblers children has no shoes.

      Thanks for taking the time to read and write – I appreciate your perspective.

      Reply edit
  • David M. Kasprzak June 23, 2010 at 3:08 am

    Now THIS is good stuff. Thanks for the link to the GAO report. I found that to be terrific.

    I did not see a condemnation of EVMS as a tool, however, and I think we'd agree that it is a powerful method. EVMS is not a determinant of program outcomes, however, only a set of indicators. If those indicators are ignored (due to a host of systemic deficiencies) the, clearly, we can see the outcome.

    To your point regarding scope creep, this statment in the GAO report would seem to support your remarks: “GAO found that 63 percent of the programs had
    changed requirements once system development began.”

    Spot on. If (always a dangerous word, but nonetheless) if it is done by the book, EVMS will provide the indicators necessary to depict a situation where things will soon fall apart. Unfortunately, internal politics within the contractor's organization, relationships between contractors and government entitites, as well as those within government bodies themselves will often result in a misinterpretion, or misrepresentation, of what the metrics predict.

    The root cause, unfortunately, appears to be the same here as we see almost everywhere, regardless of the industry or the level of the people involved: If you are afraid to tell your boss there's a problem, you will soon have a much bigger problem, no matter the tool used.

    Thanks for the additional GAO info, and a very thought-provoking post.

    Reply edit
    • Toby Elwin July 8, 2010 at 2:22 pm


      Twitter:
      GAO reports are just incredible sources of information across transformation, change management, IT integration.

      The GAO or Government Accountability Office as their site says: is known as “the investigative arm of Congress” and “the congressional watchdog.” GAO supports the Congress in meeting its constitutional responsibilities and helps improve the performance and accountability of the federal government for the benefit of the American people.

      Nice, but who's watching the watchdogs?

      As disappointing as the fact that the GAO rarely get listened to other than cursory white papers, any project I started with for the Federal Government I first went to the GAO to do research. Did they have studies or proposals in their archives, what had they written about?

      Their research always had a list of recommended steps for improvement. It was easy for me to start the conversation with, “so, what have you been able to accomplish since this GAO report…”

      Even if you are not working in public sector the GAO offers great human capital or transformation/change management-style tips.

      Thanks, as always, for your comments David.

      Reply edit
  • Vinish Garg September 27, 2012 at 11:38 am

    Interesting post on scoping. Among the reasons of project failures or going over-budget is less focus on functional scope clarifications. The proposal documents talk in detail about processes, tools, resouces, schedule, milestones, QA and payment terms; however, they fail to address what constitutes funtional scope, and what is out of scope, and what ‘can be’ considered as change requests.

    Every one including business analysts, project managers, programmers, assume certain things in scope but rarely ensure that they are ‘assuming’ the same thing in same sense.
    Vinish Garg invite’s you to read B2B Documentation: Clarifying Functional ScopeMy Profile

    Reply edit
    • Toby Elwin September 28, 2012 at 10:22 am


      Twitter:
      Each stakeholder or person a project touches has an assumption or filter that always asks “What’s In It For Me?”

      Scope planning is critical to get that on the table and level-set the scope of the project, not the scope of the stakeholder need. It is a fine line and very difficult to manage. But remains the single most important opportunity for a project to meet goals.

      Of course scope can change, but the way you manage it is not to let scope grow like a weed, but to discover changes or new conditions and actively assess the impact on the original thoughts: risk, both positive and negative.

      Thank you for the comment Vinish.

      Where do you find the greatest opportunity to engage in a real discussion around scope and who needs to be in that room?
      Toby Elwin invite’s you to read Change management is dead — the rumorMy Profile

      Reply edit

Leave a Comment

CommentLuv badge

This blog uses premium CommentLuv which allows you to put your keywords with your name if you have had 0 approved comments. Use your real name and then @ your keywords (maximum of 3)