5 Mistakes to Avoid When Defining Your Project Scope

Imagine you’ve been selected to manage a trip to California; however, you’re not sure where you’re going in California, why, who’s along for the ride, how you’ll get there, traveling constraints, or markers that let you know when you’ve actually arrived.  Where do you think you’ll end up?

Although this scenario may seem absurd, it actually represents a common problem that occurs in business-a bad project scope that leaves you wondering “Which way do I go?”

Project Scope is the detailed description of what will be achieved at the end of the project.  This description includes the time frame, budget and any other parameters associated with the project. All too often, organizations do a poor job of defining a project’s scope.  The consequences of this oversight are tremendous and include major cost overruns, excessive delays, bad estimates and inadequate resource scheduling, to name a few.  In fact, poor project scope is considered to be among the primary reasons for project failure.

Avoiding the 5 mistakes below can help ensure you have a well-defined and clear project scope.

1. Rushing the project planning process.

Project Managers must take ample time to pull the right planning team together and collect answers to all the questions needed to take “the trip”.  What are we doing, why, who is affected, what are our constraints (time, budget, resources, regulations)?

2. Using vague language and terms in the project scope statement.

A scope statement that is not clear, too general, or not measurable is of little use to the stakeholders. Instructions like, “Take the I-10Highway” could land you in the mountains of Tucson, AZ instead of the beach in San Diego, CA. Though you may love both places as much as I do, the preparation and planning is different for each of those destinations. Consider these tips:

• If your audience includes global team members, avoid language that does not translate well. Remember that people are the key to a successful project and they must understand the scope
• Just like you did in high school, ask for a peer review of your scope statement.  Solicit feedback from someone not on the project team.  Is the scope clear to them?
• Include an Appendix listing acronyms and terms used throughout the document

3. Not including the types of deliverables that are “in scope” and “out of scope”. 

The planning team (project manager, team members, stakeholders) should list requirements of the project and any associated deliverables. Remember:

• Requirements that do not tie back to project objectives are likely “out of scope”.  Side Note: Don’t forget to include training deliverables.  Training is critical as you close the project and transition to ongoing operations
• Prioritize items that are “in scope”
• Check completed work against the list of “in-scope” deliverables to make sure all the expected work is being done
• Document and validate assumptions made by the planning team.  Leave no room for ambiguity
• I find it helpful to manage a list of stakeholder expectations throughout the project.  Once the project work begins,  capture casual comments from project sponsors or management that you hear in meetings, product reviews, and in hallway conversations.  Listen for comments and triggers like, “It would be nice if..”, “Yes, that screen functions well and I anticipate that…”, “Once this is in place, our buyers can …”, “By the way, …”  Don’t ignore these comments; instead, manage those expectations in the appropriate forum.  Throughout the project, refer back to your list and check off things that have been affirmed as part of the scope or get clarification on comments that seem “out of scope”

4. Not including procedures for how completed work will be verified and approved. 

Without these procedures, you’ll have difficulty closing the project and maintaining control over the quality of work being done.

5. Omitting guidelines for handling project change requests that alter the scope.

As you execute the project, you’ll be challenged with changes to scope.  Changes that aren’t properly managed can cause schedule delays, cost money, and hinder the success of your project.  Take time at the beginning of your project to document how you will manage scope changes.  Consider things like:

• A formal change request template or form
• A change request approval team or approval board to review and approve changes
• A defined process to identify impacts of a change to the scope, schedule, and resources (e.g. budget, people)
• A process for communicating the change request guidelines to all stakeholders

Avoiding these mistakes will lead to a better project start; however scope definition doesn’t stop there.  After your initial scope is identified, don’t fall into the following traps.

• Assuming stakeholders are fully aware of the project scope; many times they aren’t. Plan ways to make stakeholders aware
• Altering the scope without approved and documented scope change requests
• Not updating the scope documentation as things change
• Not verifying the final deliverables against those documented in the scope
• Not reminding the team and any new team members of the project scope and objectives

Make every effort to identify as many aspects of the scope that you can.  Additional items in project scope include project objectives, deliverables, stakeholder expectations, cost, milestones, limits, assumptions, and risks.  Are there additional items you normally include in your project scope?  Feel free to share.

Chrystal Richardson is CEO and Managing Partner of  CE Wilson Consulting, a project management and business efficiency consulting firm that has managed projects for technology, mining, medical and  manufacturing clients since 2001.