Project Definition and Project Scope

Click here to view a video that explains what to include in a Project Scope Statement.

The information derived from the kick-off meeting should now be used to draw up a preliminary statement of the project objectives and associated specifications. This preliminary document is called a project scope.

Project scoping is a very important activity as it determines the cost, time, quality and resource requirements of the project. Adequate time should be spent on this activity because failure to derive all the relevant data for this foundation will lead to a poorly-defined project with a considerably reduced chance of achieving a successful outcome. An estimated seventy-five percent of projects seem to fail due to poor project definition. What should be included in the project scope? The following elements:

The project origins:  a need or opportunity statement

The project rationale:  why is it necessary now?

The benefits of the project:  to the customer as well as your organisation

The project budget (if known at this stage)

The current time scale and expected deadlines:  subject always to detailed planning later

A project organisation chart:  A list to show who (team members) is involved in the project, with names, positions, contact numbers, and any other information deemed important.

A stakeholder list:  A list of everybody with an interest in the project, containing names; positions; whether are they internal/external to the company; ranking of importance to the project, etc.

A statement of requirements:  A document recording needs and expectations identified, how these needs can be met in practice, which needs cannot be satisfied yet and why, assumptions made at this stage, and what the project is about and what is not included.

A project objectives statement:  The objectives should be defined in conjunction with the customer and should include a statement of background, the project purpose, the overall project objective, the primary project deliverables and expected delivery dates, the primary benefits, the cost of the project, and the skills required. This data may also be incorporated in the statement of work (SOW).

Describe the problem or project request briefly. By doing this, you restate the issues as described by your client, helping confirm your interpretation. Define the project’s goals and objectives. This section doesn’t have to be lengthy, but you need to include enough detail to ensure the client’s needs and objectives are clearly outlined.

Describe all deliverables that will establish the successful completion of the project. If your work includes programming changes, include an application design or a summary of the software development effort that provides enough detail for the client to see and agree on the deliverable. For a Web site design, this might include a short-written description as opposed to detailed Web page designs. Gauge the level of description you need based on your client’s need for detail and the complexity of the project.

Statement of work (SOW):  A Statement of Work (SOW) is a written confirmation of what your project will produce and the terms and conditions under which you will perform your work. Both the people who requested the project and the project team should agree to all terms in the SOW before actual project work begins. This document will include the purpose statement, scope statement, deliverables, goals, cost, schedule, list of stakeholders, the chain of command, agreements, assumptions and communication plan. Process specifications, customer specifications, standard operating procedures, quality standards, purchasing procedures, and other useful data can also be included.

Define the specifics of the work plan to a level of detail that helps the client understand what you plan to do in the project and how the process will work. Clarifying issues that will keep your client out of the dark makes it easier for your client to do business with you, reduces questions, and helps you achieve a positive experience with your client. The plan needs to include key milestones and estimated timeframes to the extent that you can define them.

The SOW should be considered a binding agreement.

The team must commit to producing certain results. The project’s requesters commit that they’ll consider the project 100 percent successful if these results have been produced.

The team must identify all restrictions regarding the approach to the work and what is needed to support the work. The project’s requesters agree that there are no restrictions other than the ones that have been identified and that they’ll provide the support that is declared to be needed.

The team must identify all assumptions made when agreeing to the terms of the SOW.

Of course, predicting the future is impossible. In fact, the farther into the future one tries to look, the less certain predictions can be. However, the SOW represents the project commitments based on what is known today and expected to be true in the future. If and when situations change, the effect of the changes on the SOW is assessed and the necessary corresponding changes to the project are proposed. The project’s requesters always have the option of accepting the proposed changes (allowing the project to continue) or cancelling the project.

A risk assessment:  Risks need to be identified and assessed and can be recorded in a project risk log. Risk management is a continuous process throughout the lifecycle of the project, and it is important that the team is focused on the risks.

Approval of Project Scope

Once the project manager has reviewed the project definition and ensured that all relevant information has been included, he can seek the approval of the project sponsor and customer. Approval of the project definition will lead to the detailed project planning stage.

Creating a definitive scope document helps eliminate confusion with any project and presents you in a more professional light. Consultants that provide professionally delivered services often get called back or recommended to other companies.

A comprehensive scope document should be signed off by all relevant stakeholders

Use the scope document as a means of managing your client’s expectations from the start. Too many client dissatisfaction issues occur because the client’s expectations aren’t managed upfront. Start every project venture out on the right foot by stating the project’s scope clearly and you’ll reward yourself with fewer problems down the road. Once you get into the habit of developing a scope document at the beginning of new projects, it will become a quick process and one that saves you valuable time later.

Changes to the Scope of the Project

The scope document should be adapted and updated continuously according to the changed needs of the stakeholder. Any changes to the scope should be thoroughly analysed in terms of their impact on project deliverables, project timelines and stakeholder needs and expectations. All amendments should be properly authorised through a process of “Request of change”. Changes should be logged and communicated to all relevant stakeholders and role-players. (Refer to Learning Unit 6 for project change templates).

Stakeholders should agree with management right at the start of the project on how progress will be reported and communicated to relevant stakeholders and role-players. (Refer to Learning Unit 6 for reporting template)