Puricare Industrial Enterprises: DEFINING THE PROJECT SCOPE - The project scope statement should provide detail rather than an overview, rudimentary or fundamental functions rather than complex overall ones and typically should focus on individual components within the project and how they operate. The project scope should not be confused with the project charter which is intended to describe overall goals and project features and is typically concerned with the project as whole or sometimes larger components of it. The purpose of the project background is to provide a general idea or overview of the reasons for initiating the project planning process. It should explain the key prerequisites but should not mention the allocation of resources, methods to be used, objectives or any other detailed information. After reading the project background only an “initial impression” of the project and why it came about should be taken away by the reader. This area is not used to tell the stakeholders how to solve the problem but rather to detail the major deliverables, assumptions and constraints as well as a brief statement justifying the need for the project. In general the project scope statement details concisely what will be provided by the project. It may contain explicit scope exclusions and in a general sense provides a baseline for evaluating and determining whether requests for additional work or changes are outside what was initially intended or discussed.

Saturday, January 2, 2021

DEFINING THE PROJECT SCOPE - The project scope statement should provide detail rather than an overview, rudimentary or fundamental functions rather than complex overall ones and typically should focus on individual components within the project and how they operate. The project scope should not be confused with the project charter which is intended to describe overall goals and project features and is typically concerned with the project as whole or sometimes larger components of it. The purpose of the project background is to provide a general idea or overview of the reasons for initiating the project planning process. It should explain the key prerequisites but should not mention the allocation of resources, methods to be used, objectives or any other detailed information. After reading the project background only an “initial impression” of the project and why it came about should be taken away by the reader. This area is not used to tell the stakeholders how to solve the problem but rather to detail the major deliverables, assumptions and constraints as well as a brief statement justifying the need for the project. In general the project scope statement details concisely what will be provided by the project. It may contain explicit scope exclusions and in a general sense provides a baseline for evaluating and determining whether requests for additional work or changes are outside what was initially intended or discussed.

................................................................................................................................................................................................................................................................................................................................................................

Defining the project scope

StructX

The project scope statement should provide detail rather than an overview, rudimentary or fundamental functions rather than complex overall ones and typically should focus on individual components within the project and how they operate.

The project scope should not be confused with the project charter which is intended to describe overall goals and project features and is typically concerned with the project as whole or sometimes larger components of it.

The Project Background

In this section a brief description of the background and history that lead to the need for the project should be presented and the following key points should be addressed:

· What the projects primary focus will be (what the project will address)

· A list of prerequisites and key reasons for the project

· A very basic description of how the project will be performed

· A basic explanation of the desired outcome

The purpose of the project background is to provide a general idea or overview of the reasons for initiating the project planning process.

It should explain the key prerequisites but should not mention the allocation of resources, methods to be used, objectives or any other detailed information.

After reading the project background only an “initial impression” of the project and why it came about should be taken away by the reader.

The Project Scope Statement

This area is not used to tell the stakeholders how to solve the problem but rather to detail the major deliverables, assumptions and constraints as well as a brief statement justifying the need for the project.

In general the project scope statement details concisely what will be provided by the project.

It may contain explicit scope exclusions and in a general sense provides a baseline for evaluating and determining whether requests for additional work or changes are outside what was initially intended or discussed.

The project scope statement should include the following key areas or headings and in many cases should also be accompanied by tabulated information for clarity at each section:

· Product scope description: The characteristics of the outcomes, products and services the project will produce or provide.

· Project Stakeholders: The key people who the project will affect or who have an interest in the project, its outcome or its course of action should be considered if they have an influence on the project goals being met. Identifying stakeholders helps to ensure that everyone’s needs are met.

· Acceptance criteria: When a project is started it is done so with an end result in mind, in other words, whether a problem is to be solved, something is to be created or something is to be removed or altered, the final outcome of the project, process or phase and what defines it as being completed is outlined here. It must be remembered that there may be multiple conditions and outcomes that will need to be addressed. Acceptance criteria can be thought of as a set of conditions that must be satisfied before acceptance is given by the client or stakeholder. Acceptance criteria is important as it sets the clients expectation level, helps to avoid miscommunications and can be the difference between getting paid or not if a client is paying for deliverables.

· Project Inclusions & Deliverables: deliverables or any product, result or service that is given to the client or stakeholder may be described at a summary level or in great detail depending on the situation. A project deliverable will be subjected to the acceptance criteria mentioned above and is something that usually has a due date and is tangible, measurable and specific as well as satisfying a millstone in the project plan.

· Project exclusions: Explicitly stating what is out of the scope of the project is required to not only manage client or stakeholder expectations but to help define what areas are not required to be approached by the project team.

· Project constraints: Any limiting factor/s that could potentially affect the project, its execution or completion. Project constraints will need to be written concisely and in a way that is hard to misinterpret and will typically fall into the following areas or headings:

o Time Frame & Milestones: When the results must be provided, in other words someone expects the product or service to finish with in this time frame.

o Resources: The type, amount and availability of resources required to perform the project work. Recourses can include but are no way limited to people, funds, facilities, information and equipment.

o Quality: Different circumstances, industries and people may have dissimilar minimum requirements for quality which will need to be accounted for.

o Available Funds: One of the biggest constraints to be considered is the amount of money that has been allocated or is available to the project.

· Assumptions: Any information that lacks proof or cannot be demonstrated is considered to be an assumption. This section deals with assumptions and the potential impact if such assumptions are found to be not true or uncertain. It is important to list any such factors early on so that all parties are aware of them and the affects they could potentially have on the project.

Scope Change Control: This section outlines the procedure for changing the scope. A typical example has been given outlining the steps that take place to successfully change an existing scope.

o Step #1 - Change Originates:
Changes may originate from the project team, the client/sponsor or from external sources.

o Step #2 - Change Request Submitted:
The proposed change is documented by filling out an approved Change Request Form and is submitted to the project managers.

o Step #3 - Review Change Request:
Project managers prepare and submit a change request impact analysis to the change management team. All parties involved will receive updates as things progress.

o Step #4 - Approval:
If approved, the change management team will provide final recommendations and advise the project managers. All parties must be in agreement indicated by signing before final approval is given.
If not approved the initiating party may resubmit a Change Request Form as detailed in STEP #2.

o Step #5 - Update Plan of Record:
The project scope is updated along with any relevant documentation and will be sent out for final approval.

o Step #6 - Distribute for Action:
The new documentation is distributed to all concerning parties and the change may proceed.

· Sign Offs: Because all parties involved should be in agreement with the terms of the project a section is reserved to show the project manager and the project sponsor are aware of the high level requirements of project as known to this point.

StructX was created in an effort to provide a comprehensive and freely accessible resource for the structural engineering community - "Good engineers don't need to remember every formula; they just need to know where they can find them". Fundamentally, StructX is an ever adapting source of formulas, data, properties and techniques commonly adopted by structural engineers worldwide.

The information provided throughout this website has been created based on existing theories or adapted from well-established resources both online and offline. Most of the information provided by StructX is already available on the web free of charge with the only difference being that StructX brings all this information together into one handy resource. References have been provided wherever possible to allow the user to attain additional information or to confirm authenticity, originality and/or accuracy of the material provided.

Although invaluable to the university or college student, this website is not intended to be a textbook type learning aid and the information is not necessarily prescriptive. Instead, StructX should be thought of as a collection of refreshers shown in summary form to give anyone involved in design, evaluation, construction, investigation or repair a nudge in the right direction.

Despite our best endeavours, there may be some errors and omissions. StructX is interested in receiving any comments, corrections or suggestions on the content of this website via info@structx.com or alternatively through the contact form provided

https://structx.com/PM001-Scope.html

You might also like:

Dams and Reservoirs