Week 5: Project Scope Management

In this week of the course we will look at project scope management, examining the reasons that projects often exceed their scope and the processes from the PMBOK that are intended to minimise this. The following video is a humorous illustration of the expansion of scope in a project:

The PMBOK describes project scope management as follows:

“Project scope management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Managing project scope is primarily concerned with defining and controlling what is and is not included in the project.”

Within the PMBOK there are six major processes involved:

1. Plan scope management

2. Collect requirements

3. Define scope

4. Create the work breakdown structure

5. Validate scope

6. Control scope

We will examine each of these areas in turn. First, it is important to understand the distinction between product and project scope:

Project Scope Management in PMBOK

Project scope management begins with the creation of a Project Scope Management Plan. The project manager examines the project management plan and the project charter which provide information on what the project will do and how it intends to do that. Experts may be consulted and meetings held with project team members and clients to create the scope management plan. At the same time a Requirements Management Plan will be created that will describe how the project requirements will be identified and managed.

The second major process in project scope management in PMBOK is to Collect Requirements. The project manager will examine the scope management plan, the requirements management plan, the stakeholder management plan, the project charter and the stakeholder register and consult with project stakeholders on what the project should do. They will use interviews, focus groups, workshops, questionnaires etc. to understand stakeholder requirements from the project, They will then produce documentation that will detail the project requirements. Often they will create a Requirements Traceability Matrix. This work may be undertaken by a business analyst:

The third major process is to define the project scope. The scope management plan,project charter and the requirements documentation are analysed and a project scope statement is produced. This may result in revisions to other project documentation. It is critical that this definition is accurate as it will be used as a basis for the design of project activity.

The third major process is the creation of the Work Breakdown Structure. The project scope statement and the requirements documentation are analysed “decomposition” is undertaken. Decomposition is the breaking down of the project into individual tasks that can then be compiled into the WBS. The following video provides detailed guidance on WBS creation:

The fourth major process is project scope validation. In this process the deliverables for the project are inspected to verify whether or not they are completed according to the project scope requirements. As a result of this process either the deliverables will be accepted as complete or further work will be required.

The fifth major process is to control the project scope as the project proceeds. Project performance reports will be examined and compared with the project requirements documentation. Variance analysis will be undertaken here to understand where gaps may exist and this may result in changes to the project management plan to address these.

The Amoebic Growth of Projects

The five major processes in project scope management have been described above. In spite of following these processes, many projects still exceed their scope. The article for this week of the course: The Amoebic Growth of Projects, details research on why. It highlights a number of areas that influence scope creep. It examines the project estimating process, the planned or control estimate, the impact of external changes, “naughty customers”, customer behaviour issues, systems dymanics impacts and the impact of project acceleration.

The article argues that project problems often start with the estimating process. At this point there is a high degree of uncertainty about what the project scope will be. Typically there are maximum and minimum estimates that are created and the risks that are associated with the estimates made are rarely made explicit. At the same time, estimates are usually part of a competitive process and there is a desire to make as low an estimate as possible in order to win the contract. As a result of these factors, the estimate that is produced is often lower than it should be, underestimating the project cost and the scope of the work that will be involved in the project. The following video shows a discussion on estimates and the role of the project manager, Here is some useful advice on project estimation:

The next issue which occurs in project scope management is once the project contract has been won. Now a planning estimate is often done which is higher than the bid estimate. This becoms the project baseline or “control” estimate and adherence to it is strongly emphasised by PMBOK. However, it is important that project managers focus on a realistic budget – it is rare for a project to face no problems:

As the project proceeds, external changes can occur such as new or unforeseen safety requirements. New estimates can be difficult to prepare – often the team that did the original estimates will have moved on to other things and will not be available to assist. Project managers need to plan for this happening and ensure that data is available and expertise accessible to do the new estimates. Usually in these circumstances, costs are passed on to contractors who shoulder the burden of the additional cost.

Customers and contractors can also influence the scope of the project. Often contractors will volunteer “giveaways” – new ways of doing thimgs that they argue will be cheaper that in practice often are not. Changes like this are often not recorded and impact the rest of the project. Contract interpretation is often an issue here too. Preferential engineering can occur where contract interpretation is at a level that exceeeds customer requirements. All of this contributes to increasing the project scope.

The behaviour of customers or clients can also impact project scope. For example, small frequent changes to the project that seem small by themselves can cumulatively have a significant impact, increasing project meeting requirements can also be a problem. The project manager needs to understand the client’s management style and build that in to their project planning. Where problems do emerge in the relationship between the project manager and project clients it is important that these are resolved in a timely manner and not ignored.

The following video discusses dealing with difficult clients:

The cumulative impact of small project changes has been mentioned above and is expanded here. The concept of systemicity is that small changes can have a larger impact in other areas of the project. Often these wider impacts are not recognised and the project timelines are affected. It is difficult to assess the cost of cumulative project overruns. This highlights the need for the project manager to manage the risk in the project as systemic relationships – being aware that wider impacts might occur. Improved project communications will increase the visibility of project changes.

When a project falls behind on its schedule, project managers will often seek to accelereate the project to compensate. This can be done by completing tasks out of the order in which they were planned, increasing the labour devoted to the project (often beyond an efficient level) and increasing the parallel completion of tasks. This acceleration can often lead to problems. If too many people are allocated to a task then mistakes can occur and exacerbate the problems further. Underestimation of the original project timeline can magnify the problem and it is often difficult to know who caused it.

This week we have looked at project scope management looking at the major processes from PMBOK and discussing why projects often exceed their scope, to better understand how project managers can more effectively keep projects on track.

This entry was posted in Week 5: Project Scope Management and tagged , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s