Whenever you are defining what is "in scope", it's a good idea to note what related work is "out of scope."

This will help clarify understanding and expectations regarding project scope.

As a rule, any work item that is related to your defined scope that someone could assume is included, but is not, should be listed as "out-of-scope."

• Success Criteria Closely related to Goals and Objectives, this section should list the measurable, verifiable results that will determine the success level of this project. This section is often referred to as Critical Success Factors too.

• Project Context Documents how this project relates to other projects within the product program and/or within the organization as a whole. This section should also describe how the project fits within the organization and business process flow.

• Project Dependencies Closely related to Project Context, this section clearly documents any dependencies that could impact the results or success factors of this project.

• Scope Specifications Clearly designates the organizational, process, systems, and functional specification boundaries for the project. Should be high-level breakdown of the Goals and Objectives.

• Out-of-Scope Specifications To better communicate what is considered to be "in scope," it is recommended that you clearly indicate the high level work items that are related (or associated) to this initiative, but that are not of this project

• Assumptions This section clearly communicates the underlying basis or things to be considered true in regards to any other aspect of this document. In most cases, the Scope, Out-of-Scope, Assumptions, and Constraints section combine to clearly define what work will be performed by this project.

To expedite the process of getting agreement on the project definition document, walk through an initial draft that you develop with the stakeholder group rather than starting with a blank slate.

note The process of project definition and project planning is a process of iterative refinement (or what PMI refers to as progressive elaboration), so your draft will help facilitate the discussions, negotiations, and modifications that need to occur amongst the stakeholders.

• Constraints This section lists any business event, schedule, budgetary, resource, or technical factor that will limit the options available to the project.

• Risks This section will list any uncertain event or condition (risk) that, if it occurs, could have a negative impact on one or more project success criterion (schedule, budget, quality, and so on). For each risk, it is good to list the related causes, the perceived negative impacts, the likelihood it will occur, and the planned response strategy and action items. See Chapter 14, "Managing Project Risks," for more details.

• Stakeholders This section lists all of the individuals, business units and organizations involved in the project, the role(s) each is expected to play, and an indication of how they relate to one another. A Project Organization chart and a Stakeholder-Role Description Table is highly recommended here.

• Recommended Project Approach To better describe the intent of the initiative, this section highlights the recommended approach to getting the work of the project done and why it was selected over any other options. This section should note any key strategies, methodologies, and technologies to be used.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment