A Project Scope Management

Scope is the description of the boundaries of the project. It defines what the project will deliver and what it will not deliver. Scope is the view all stakeholders have from the project; it is a definition of the limits of the project. 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. Project scope management’s primary concern is with defining and controlling what is and is not included in the project. One of the leading causes for project failures is poor management of the project scope, either because the project manager did not spend enough time defining the work, there was not an agreement on the scope by stakeholders, or there was a lack of scope management which leads to adding work not authorized or budgeted to the project, this is known as scope creep. Scope creep, or the uncontrolled changes in a project’s scope, is the tendency of a project to include more tasks than originally specified, which often leads to higher than planned project costs and an extension of the project end date (Cook-Davies, T. 2002)

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!

Essay Writing Service

The purpose of scope change management is to protect the viability of the approved Project Contract (or agreement) and the approved Project Logical Framework (Logframe). In other words, the Project Contract defines the overall scope of the project, and the Logframe which establish a causal link between inputs, processes, outputs, outcomes and objectives of the project. It is not possible to assume there will be no changes during the life of the project. For example, changes may come from the beneficiaries who want additional deliverables, then the initial estimates for budget, and schedule may no longer be valid. If the donor agrees to include the new work into the project scope, the project manager has the right to expect that the current budget and deadline will be modified (usually increased) to reflect this additional work. This new estimated cost, effort and duration now become the approved target (Cook-Davies, T. 2002)

All changes to the project scope must be approved by management and the donor; this is one of the principal requirements for scope management.

This is not to say the objective of scope management is to avoid any changes to the initial agreement; development projects, due to their nature are initiated mostly on general assumptions. It is expected that as the project makes progress, additional information will lead to new insights that require the project to change its approach and its plans. The purpose of scope management is to establish a process that will allow the incorporation of changes by ensuring the changes contribute to the ultimate goal of the project, changes are agreed by stakeholders and approved by management and the donor. Scope management consists of a series of tasks and steps designed to help the project manager manage the project deliverables, the steps are: (Cook-Davies, T. 2002)

• Defining the Scope
• Assigning Scope Work
• Verifying the Scope
• Adapting the Scope

DEFINING PROJECT SCOPE

Defining the project scope is identifying all the work that the project will accomplish in order to achieve its final goal. The work includes the activities identified in the Logframe and the activities the project team has identified that will be necessarily to support the project, these includes activities such as team capacity building, stakeholder management, meetings and project presentations and all significant activities that will consume project resources (Gardiner, P. D. 2005)

Project Scope Statement

The Project Scope Statement is used to develop and confirm a common understanding of the project scope among key project stakeholders. The scope statement should include the project justification, a brief description of the project outputs and its intended benefits, a brief summary of the project major constraints, assumptions and dependencies with other projects or external initiatives and a statement of what constitutes project success. This document is used as a communications tool with all project stakeholders to ensure all have a common perception of what the projects is and what it is not, it is also used to communicate any approved changes made to the project (Gardiner, P. D. 2005)

• The project justification describes the need that the project will satisfy or the problem it will address. For example, the increase of economic income of a target population. It also describes the communities or groups of beneficiaries that will benefit from the project outcomes and the locations were the project will work.
• The brief description also summarizes the tangible outputs of the project such as the number of beneficiaries that received a loan.
• Project constrains include any significant limitations either imposed by the donor, the beneficiaries or local conditions. For example the beneficiaries may impose the project doesn’t include work during harvesting season, or that the donor requires the project to be completed by a certain date.
• Project assumptions include a list of the conditions that are expected to exist for the project to be a success; conditions that are accepted as true without proof or demonstration, such as the labor contribution of the beneficiaries to complete an activity in the project.
• Project dependencies are either internal or external factors on which the project is dependent, such as another partner organization that will deliver services or goods that will be used by the project, for example the road reparation work a local municipality needs to complete for the project to have good access to the community.
• Project success is defined by the stakeholders, specially the donor and the beneficiaries. Success is not only meeting and completing the project activities on time, under budget and in the expected quality that is acceptable to the donor and stakeholders, but how the project outputs produced the desired outcomes that contribute to the well being of the beneficiaries. Success is ultimately defined by the beneficiary so it is good practice to ask and document what the beneficiary expects the project.

The project scope statement is the most important tool the project has to frame the project, it is used to evaluate every change request and helps communicate the limits of the project to a wider audience. It is also used as a project information document that puts in concise terms what the project will do (Gardiner, P. D. 2005).

Work Breakdown Structure

Once the Scope Statement has been completed, the next step to further define the scope is to break it down to its most manageable pieces. The purpose is to develop a complete list of all the tasks that are needed by the project, this list will be used to determine the resources requirements such as the time, skills and cost estimates. It is also used as a baseline for performance measurement and project monitoring, and supports the clear communication of work responsibilities. The output is the Work Breakdown Structure or WBS (Leach,L.P. 1999)

The Project Work Breakdown Structure is an outcome oriented analysis of the work involved in the project and defines the total scope of the project. It is a foundation document in project management because it provides the basis for planning and managing the project schedule, budget and requests for any changes or deviations from plans. The WBS is developed in the form of an inverted tree structure, organized by objectives; it looks like an organizational chart which helps visualize the whole project and all its main components. A Work Breakdown Structure (WBS) is a project management technique for defining and organizing the total scope of a project, using a hierarchical tree structure.

The first two levels of the WBS define a set of planned outcomes that collectively and exclusively represent 100% of the project scope. At each subsequent level, the children of a parent node collectively and exclusively represent 100% of the scope of their parent node. A well designed Work Break Down Structure describes planned results rather than planned actions. Outcomes are the desired ends of the project, and can be predicted accurately; actions comprise the project plan and may be difficult to predict accurately. A well-designed WBS makes it easy to assign any project activity to one and only one terminal element of the WBS (Leach,L.P. 1999).

ASSIGNING SCOPE WORK

Once all the work needed to accomplish the project has been identified the next step in the scope management process is to assign the work to the people responsible for it. Inputs to this step include the WBS, the project schedule that identifies when each activity or task should occur, and the Resource Requirements Matrix (RRM), which identifies the skills required to accomplish the activities, this matrix us used to select the project team.

Elements of this step include the actions to assign scope work to the project team via the Work Assignment Sheet, and assign work to consultants via the Scope of Work document; part of this process includes collect information on the work completed, get and acceptance of the work by the beneficiaries. (Leach,L.P. 1999)

Work Assignment Sheet:

The assignment sheet should include the date of the assignment, the expected completion date, the beneficiaries involved and the locations of the activities and any other resources needed to accomplish the activity or task. Depending of the skills and authority of the team member the assignment could be at the objective level or at the task level, but should include a brief description of the instructions or approaches selected to carry out the activity. For example a technical professional may be assigned to accomplish an objective using gender based approaches, while a field worker may be assigned a task to collect baseline data on a specific community using detailed instructions and forms.

Scope of Work (SOW)

Scope if work is a similar process, but in this case the work is assigned to a contractor or consultant hired to deliver a specific work for the project, The Scope of Work or SOW usually follows a Terms of Reference (TOR) that helped define the objectives and select a consultant to do a specific work that required skills not present in the team or organization.

At the completion of the work the consultant should present a document that informs on the progress made and the results and outputs generated by the SOW (Leach,L.P. 1999)

VERIFYING THE WORK

This step refers to the actions required to ensure that the work delivered meets the specifications of the project and it is used as a guarantee that the project is delivering the promised quality in its work. At the end of the assignment the team members or consultants, report the activities accomplished, any deviations from the plan, changes or modifications to the activity and any information that will help update the project plan.

Scope Verification

Scope verification deals with obtaining the stakeholders’ formal acceptance of the completed project work scope and the goods or services delivered. Now, the verification of the project scope includes re-viewing the deliverables to make sure that each is completed satisfactorily. If the project was discontinued earlier, the project scope checking process shall establish and document the level and extent of completion (Turner,J.R.2000).

Work Acceptance

• Once the scope verification confirms that the work meets the requirements of the project, the next step is to obtain acceptance of the work; work acceptance is needed in cases when the beneficiary needs to give testament that the work or activities delivered by the project were achieved as agreed, and that they met the needs of the beneficiaries within the scope of the project.

• Change Requests

  Out from the delivery of work and the verification of work, requests to change the scope may occur based on new insights gained on the project, changes in the original conditions or assumptions of the project or discovery of new opportunities. Changes are not necessarily made to correct a situation but could also include changes in approaches or strategies that will impact the project scope. Changes can originate from the project team, beneficiaries, organization’s management, or the donor. In any case the project manager should use the Project Scope Change Control Plan defined to manage the process or change request, obtain approval and incorporate and communicate the changes (Turner,J.R.2000).

  ADAPTING THE SCOPE

  Once changes to the project scope have been approved, the project needs to update all project plans and communicate these changes to the stakeholders and inform the way the changes will impact the project. Adapting the scope is a step whose sole function is to incorporate changes that will provide improvements to the project and increase the chances for its success (Turner,J.R.2000).

  Example of the Project Scope Management:

  Tsunami hits the costal line of India, thousands of people suffered. Government decided to have technology with them using which they can detect the possibility of such natural disaster in advance. Considering this as the project:

  Define the scope of the project

  In clear terms, the project here is to develop a new technology with which we can detect the possibilities & probability of the occurrences of the natural disasters before they occur so as to save lives of many people.

  • Scope of the project:

  The scope of the project is defined as the sum total of the projects products & their requirements or features. Thus according to this definition of ours, the scope of the current project is:

  • Finding is a similar technology (Less advanced & useful) available so that it’s easy to modify the same to create a new & better one.
  • Decide whether the new technology should be feasible enough as to accommodate almost all types of disasters (Like tsunami, earthquakes, cyclones, etc)
  • Finding the availability of the technical & other staff so that the project is not delayed.
  • Whether this is to be a portable hardware machine (as a technology), one for each type of disaster OR a heavy one, dealing with (almost) all types of disasters.
  • In case this technology fails at any point of time, what are the backups. (Turner,J.R.2000).

  Conclusion:

  At the end of each project phase or at the completion of a significant milestone the project needs to capture the lessons learned in managing the project scope. This include the causes or reason why something did not went according to plans, the causes that contributed to success, and the actions the project took to deal with an issue or challenge. The idea behind is to capture the lessons right after an action and not wait until the end of the project; the project should incorporate a practice that builds a discipline and a routine to capture lessons continuously and creates spaces for the project team to reflect on the lessons and incorporate them in the next phases or cycles of the project.

  References:

  Pinto, J. K. and Slevin, D. P. (1988) Critical Success factors across the project, Project Management Journal, 19(3): 67-75

  Cook-Davies, T. (2002) The “real” success factors on projects, International Journal of Project Management, 20(3): 185-90.

  Gardiner, P. D. (2005) Project Management – A strategic planning approach, Palgrave -Macmillan, New York, USA.

  Leach,L.P.(1999)Critical chain project management improves project performance. Project Management Jour-nal 30(2),39-51.

  Wheelwright,S.C. and Clark,K.B.(1992)Creating project plans to focus product development Harvard Business Review Mar-Apr,70-82.

  Turner,J.R.(2000)Editorial: the global body of knowledge…. International Journal of Project Management 18(1),1-5.

  Barber,P., Tomkins, C. and Graves, A.(1999) Decentralised site management-acasestudy. International Journal of Project Management 17(2),113-120.

  Atkinson,R.(1999)Project management: cost, time and quality, two best guesses and aphenomenon, its [sic] time to accept other success criteria. International Journal of Project Management 17(6), 337-342.