When I first began meeting with the project team, things seemed to be going well. The project had been in progress for several months and was previously managed by the technical team. My assignment was to provide the project sponsor with more insight into what was happening and make sure everything went well. The first phase of implementation was scheduled to take place in just a few weeks. As I came up to speed and started asking probing questions, it quickly became apparent why I was asked to help. The team informed me there was only one thing that might delay the first deliverable. It was a big, complex issue and soon became clear we were not going to meet our schedule.  During an executive briefing I explained the delay and confidently explained only one issue was holding us back. It couldn’t have been more than a day later when one of the project engineers announced we could not deploy because our network was not set up to support the new hardware. A few days later another team member said we didn’t have power for the hardware in the data center. Quickly a new pattern of communications emerged in which, almost daily, there was a new surprise and each was directly related to the project’s scope.

Scope Creep vs. Scope Surprises

In A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Fourth Edition, on page 448, the Project Management Institute (PMI) defines project scope as the “sum of products, services, and results to be provided as a project.”  In other words, the scope of the project is what the project team will do.  The PMBOK goes on to define scope creep as “adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval.”  Scope creep then is not the same as scope surprise.  You can think of a scope surprise as:

1. Discovering the understood scope was incomplete or incorrect, or
2. Realizing some of the in-scope work previously believed to be complete is either incomplete or inadequate.

The focus of this article is on avoiding scope surprises rather than preventing scope creep.

Scope Management: Why Scope Surprises Happen

There are several reasons management gets hit with scope surprises.  Three of the more common are:

1. Poorly Worded Defining Documents

The defining documents referenced here are contracts, statements of work, project charters and scope statements.  The documentation a project team uses to define its scope is always subject to interpretation and subtle nuances of language.  Typically the authors of such documents know exactly what they mean when they wrote it.  These documents are used by many different people to develop their understanding of what the project will and will not deliver.  In the project mentioned at the beginning of this article part of the statement of work declared the vendor would coordinate the move of equipment.  The project sponsor interpreted this as “the vendor is moving the equipment” and the vendor interpreted it as “we will help the customer determine what they need to move”.  After the differing interpretations were discovered it took three weeks to agree who would move the equipment.

2. Undocumented Project Scope

It’s amazing how often organizations will start up a project without documenting the scope at all.  Under these conditions every project stakeholders develops an undocumented and sometimes unspoken set of assumptions about what the project team will deliver.  For obvious reasons this is quite risky.

3. Unverified Work Results

A third cause of surprises is lack of follow up or accountability.  Simply assigning a task to a somebody does not guarantee it will be completed on time or to specification.  While project managers cannot always follow up on everything, it is important to have checks and balances in place.  Each team member must be held accountable for delivering their contributions to the project when they are needed.

Project Management Tips: How to Avoid Scope Surprises

Here are a few tips for avoiding scope surprises:

1. Make sure your project scope is clearly documented.  A good place to start is with a work breakdown structure (see the September 2010 Sensible Management Article “The Power of Work Breakdown Structures”).
2. Review your scope assumptions (see the February 2010 Sensible Management article “How to Identify Assumptions”).
3. Conduct regular reviews of your project schedule.  Review your plans with the project sponsor, the technical project team and other key stakeholders.  Doing so will prompt questions about activities not represented in the plans and spark discussions about why or how the team will accomplish its goals.

By insisting on a defined project scope, testing assumptions about your project’s scope and following up on assigned tasks you can avoid many of the surprises that might otherwise come your way.

30 Seconds About Silvercloud Consulting

In his book “Management” Peter Drucker wrote:

In an organization, there is no such thing as a pleasant surprise.  To be exposed to a surprise in the organization one is responsible for is humiliation, and usually public humiliation.

One of the key benefits Silvercloud Consulting brings our clients is the ability to reduce surprises.  Whether it is developing custom dashboards or status reports, helping teams clearly communicate their issues and risks, or documenting project scope, Silvercloud Consulting can show you how to make surprises something that only happens in your office Secret Santa program.  Contact us today to find out how we can help.