Scoping the project.

The main purpose of scope planning to create the scope management plan.  Scope, describes what work is included in the project, and what work is not included in the project.

The sources of input for scope planning are:

• Enterprise environmental factors
• organisational process assets
• project charter
• preliminary project Scope statement
• project management plan

These inputs will serve as source data to help determine the scope of the project.

There are two tools and techniques which are in scope planning:

Expert judgement.  These people can clarify questions you may have both on the project objectives and the product descriptions

Templates, forms, and standards.  Your project management of this may already have some of these which will help in the scoping of the project.

The result of scope planning is the project Scope management plan, and it should contain these aspects:

• A detailed description of what the project deliverables are as well as the requirements of the project
• processes and techniques for creating the work breakdown structure (WBS).
• definition, this can be found in the product descriptions, of how the products will have their quality checked, and what measurements will be used
• how change requests, including scope changes, will be implemented and communicated to all stakeholders.

Defining the scope definition

The information needed here are items such as historical information, product descriptions, and the project objectives including assumptions and constraints.

The inputs for scope definition are:

• Organisational process assets
• project charter
• preliminary Scope management plan
• approved change requests

The tools and techniques used in this process are:

• product analysis
• alternatives identification
• expert judgement
• stakeholder analysis

Dealing with each in turn...

Product analysis. 

This is the method for taking the product description and project objectives and converting them into deliverables and requirements.

PMBOK suggests you may need to perform Value analysis, functional analysis, systems engineering techniques, systems analysis, or value engineering techniques to define the product or service.

Alternatives identification.

This technique can be used to discover alternative ways of delivering the project and meeting the objectives.  Brainstorming or" thought showering", is a well-known technique that can be used.  It is best used in a team environment where many ideas can be generated.

Lateral thinking created by Edward De Bono, can be used by the team to" think outside the box".  This encourages everyone to come up with different ways of solving problems inherent in the project.

Stakeholder analysis.

This technique is often used as a prerequisite to creating the communication plan.  It can be useful to capture this information on a Stakeholder Map.

Identifying Stakeholders.

All stakeholders should be considered, both internal and external to the organisation.  Stakeholders are not born equal -- some may be more important than others, and some may have more authority than others.

Understanding stakeholder roles.

This starts by determining what each stakeholders interest areas are in the context of the project objectives and eventual benefits to the organisation.

Some stakeholders may be very supportive of the project, others may have little interest in the project -- but have the authority to support the project or not, and some stakeholders for their own reasons, may be actively against the project.

This problem is compounded by the fact that their true intent may be hidden.

Stakeholders with a high influence and authority, need to be encouraged to support the project. 

If the stakeholders feel positive about the project then they can become the project" champions", if they feel negative about the project, then they may become" blockers".

Communicating with stakeholders.

The key to successful communication is to meet with each stakeholder and document then needs, wants, and expectations.  Possibly changing a small part of the project may bring them to your side and small compromises could be helpful in delivering projects successfully.

The project Scope statement.

This needs to be agreed between the customers and users, and the suppliers of this project.  One creating and agreeing this key document, a common understanding of what the project is to achieve will help with the commitment of all stakeholders.

Agreeing the exact scope of the project will be vital in change control, because any changes will be clearly identified as a change from the original scope.

This Scope statement should include the following information:

• Project objectives
• product/description
• project deliverables
• project requirements
• project boundaries
• product acceptance criteria
• product constraints
• project assumptions
• initial project organisation
• initial defined risks
• schedule milestones
• fund limitations
• cost estimates
• project configuration management requirements
• project specifications
• approval requirements

I will now go through each of these in turn:

Project objectives.

There is an old Army story between the season veteran and the new rookie.  When asked what the objectives are, the rookie replies" to take that it hill".  The veteran replies" no son, the objectives are" to take that hill without loss of life, secure position, and returned safely".

To help us, there is a well-known management acronym, called"SMART".  It stands for:

S. -- specific.  Objectives should be specific and written in clear, concise and understandable terms.

M -- measurable.  Measurements should be applied to each objectives

A -- accurate.  Objectives should describe precisely what is required.

R -- realistic and tangible.  Objectives must be possible to accomplish, and centred in reality.

T -- time bound.  Objectives must have a timeframe and an agreed end date

It is worth discussing measurements.  Try to include numbers or metrics whenever possible.  If the objective is tangible, then this will be fairly easy, but if it is intangible, then methods need to be found to measure this. 

For example, if one objective of a project is to improve organisational morale, then this will need to be measured by methods such as questionnaires with carefully chosen measurement criteria. 

Another way to measure intangible objectives would be to measure a" knock-on" effect, such as a reduction of employee absenteeism and or sickness.

Product scope description.

As already mentioned, the scope description is included in the project charter.  As a result of further discussion, if the Scope has not changed then the original statement can be cut and pasted here.

Project deliverables

These deliverables are also known as project products.  It is vitally important that each product is described in terms of what it must be, and what quality criteria it must needs in order to be acceptable to the customer or users.

For all key or major products, it will be helpful to create a Product Description for each.  These product descriptions must include the quality metrics that the product must meet, the method of checking these metrics, and who should do it.

Is a good idea to get customers and users involved in drafting these metrics as they will have a good understanding of the environment in which the product is to be used.  These product descriptions should be created during planning so that the method, skills, and timing of these quality checks are built into the plan.

Project requirements

According to the body of knowledge, requirements are conditions that must be met, or criteria that the product must possess.  These requirements describe the characteristics of the deliverable.  Requirements, quantify and prioritise the wants, needs, and expectations of the project sponsor and stakeholders.

It is the project managers responsibility that requirements are document is an agreed early in the project.  The project manager should use the project charter and preliminary Scope statement as a starting point for identifying and agreeing project products or deliverables.  Product based planning techniques will be helpful in identifying all the projects products.

Project boundaries

These define what is and what is not excluded in the work of the project.  The project boundaries should be reviewed by all stakeholders to ensure a common agreement, as this will reduce any problems of acceptance at the end of the project.

Product acceptance criteria

These criteria will be used to determine if the deliverables are acceptable and satisfactory.  All acceptance criteria must have measurable elements.  The rule is, in acceptance criteria cannot be measured, then it should not been claimed.

Product constraints

As a project manager, your biggest challenge is to balance the project constraints while at the same time, meeting the expectations of all stakeholders.  Any elements that impedes the work of the project or prescribes a way that the project should be performed, is a constraint.  The constraints of a project may be elements which must be in-place before the project can start, and/or elements that must be in-place throughout the project.

The most common types of constraints in a project may include the following, but it is not a complete list:

• Time constraint
• budget constraint
• quality constraint
• schedule constraint
• technology constraint
• directive constraint
• resource constraint
• facility constraint
• equipment constraint
• tools constraint
• process constraint
• techniques constraint
• procedure constraint
  etc

Project Assumptions

Within a project, assumptions are things that you believe to be true at this point in time.  Projects can often find because an important assumption was forgotten at the beginning.  Assumptions may fall over a number of headings such as dates, people, staff availability, etc.

Assumptions should be checked to make sure they are valid.  Assumptions that the beginning of a project may turn out to be project risks.

Initial project organization

The project organisation should be designed and appointed.  Careful thought is needed to ensure that each person filling a project role has the right level of authority, knowledge, skills, experience, and availability.  Each role should have their responsibilities documented -- formally in a joint description.

Initial defined risks

All known at risks at this time, should be evaluated.  This includes their identification, their probability and impact, actions that should be taken, and who should take these actions.  This information will have management make an informed choice about whether to proceed or not.

Schedule milestones

These are time points in the project where a significant and important achievement will happen.  Often, they will be points where a major deliverable or product is completed.  These milestones are initial ones, and may be refined later.

Fund limitations

These will often be the same as cost constraints, but it is important that these are stated here along with any timeframe that applies to these funding limitations.

Cost estimates

These estimates should include the total project cost and the level of confidence for each estimate.

Project configuration management requirements

Configuration management may be thought of as change control to protect the projects assets.  Configuration management should be closely linked with change control so that at any point in time, every product has a unique record of its status. 

Configuration management is detailed in another article.

Project specifications

This includes any known specifications that the project must comply with.

Approval requirements

The approval requirements refers to how the objectives, deliverables, and project management documents will be approved.

This is not the same as how products will be approved. This refers to how the project  products will be approved before the project can proceed any further.

Approving the project scope statement.

The project scope statement should be improved, agreed, and distributed to all the stakeholders. This can be done with a formal sign-off procedure documented, as part of the “ approval requirements” of the scope statement.

Updating the project scope management plan.

Changes to the original objectives and requirements will often occur, and these requested changes once approved, mainly due to changes of scope.  Once or twice, these changes will need to be notified to other stakeholders.