Ramon Ecung's Personal Blog

A scope statement is a document that details a project’s deliverables and describes it’s major objectives (Wikipedia). This document is essentially a high-level overview of what the entire project will encompass (including what it will not cover).

In order to develop a project scope document, certain key pieces of information need to be discovered. These include (Wikipedia):

• The project name
• The project charter
• The project owner, sponsors, and stakeholders
• The problem statement
• The project goals and objectives
• The project requirements
• The project deliverables
• The project non-goals (what is out of scope)

In order to develop the information contained within the project scope, key stakeholders should be involved with the project. By having stakeholders involved, you increase the odds of the project being a success by getting multiple sources of input. A project can be completed successfully, but if it doesn’t meet the users needs, it won’t be used, and the time and other resources used to complete the project will have been wasted.

A good project name needs to be descriptive of the project (Stallsworth). A project name like “ASP.NET 3.5 Traffic Monitoring and Routing Website for Building A” is a much better name than “Website Project”. This helps instantly identify key information about the project immediately. In my experience, I find it’s much easier if you come up with an acronym or nickname for a project as well.

In my opinion, the most important part of the scope statement is the problem statement, project deliverables, and the non-goals. These three sections of the document state what the project is designed to solve, how it will solve the problem specifically, and what the project won’t address. It’s important to state what the project will not cover so you know if another project is needed to address a stakeholder’s needs or if they’re critical enough to involve in the current project.

After the project scope has been finalized, it should be signed off on by the stakeholders to provide accountability and to ensure all key users in the project fully understand what the outcome will be. If the scope needs to be changed in the future, all stakeholders need to meet again to discuss the changes and sign off if the changes are warranted (Stallsworth).

In my experience, it is critical to manage the flow of communication between stakeholders and the project management team. I’ve seen situations where a stakeholder would communicate directly with a software developer to ask for features or changes that will improve their workflow, but having the developer work on unapproved changes takes time off of the approved goals and causes confusion.

“Scope Statement – Wikipedia, The Free Encyclopedia”. Wikipedia.org. 2/22/2010 <http://en.wikipedia.org/wiki/Scope_Statement>.

Stallsworth, Eric. “How to Write A Scope Statement”. BrightHub. 2/22/2010 <http://www.brighthub.com/office/project-management/articles/2491.aspx>.