Prior to the onset of modern project management, the success criteria of a project lay solely on the technical success, or scope of the resulting product or service. Today, adherence to budget and schedule form a triangle of success factors alongside scope, with client satisfaction also developing as a key determinant of project success (Kerzner, 2004). However, the delivery of project scope will always take precedence over all other project factors, because if a project fails to deliver on its original intention, need or functionality, the project will always be considered as a failure.
This essay will analyse the adequacy of the Guide to the Project Management Body of Knowledge’s (PMBOK) definition of Project Scope Management in relation to other literature, and explore the relevancy of the processes outlined in the PMBOK to all projects – both big and small. When defining scope in the context of projects, it is important to contrast between product scope and project scope.
Product scope refers to the features and functions that characterize a product, service or result, while project scope refers to the work that is needed to be accomplished to deliver the product, service or result with specified features and functions (Project Management Institute, 2008). Although the product scope is the desired end result of the project, or the what”, project scope considers the “how” and the wide range of processes, technologies and methods that can be used to reach the objective.
Project scope management is a further extension to this and refers to the managerial processes or methodologies required to plan and execute the project scope There are a significant number of definitions for project scope manegement with the same basic message. UTS (2006) describes project scope most concisely as “what the project contains or delivers” (UTS: Project Management, 2006). The PMBOK builds on this common understanding of project scope and adds three important features.
Firstly, PMBOK explicitly defines project scope as “all the work required, and only the work required to complete the project successfully”, which highlights the importance of clarity surrounding exclusions from the project. The intention of this reference is to highlight the importance of accurately defining scope during the initial planning phase of the project, and ensuring that the client is clear on what is and is not included in the project. By doing this, all parties are clear on the scope on which the project plans are based.
Because a project manager must balance project scope, time, cost and quality to ensure project success, exceeding the agreed scope will negatively impact other project factors, such as cost overrun and project delays. ((Jordan, 2010) Quote) Secondly, the PMBOK includes a process of “defining” the project scope in its definition. Unfortunately, in most projects, particularly complex ones, at the outset, there is a lack of clear understanding of what the project is trying to achieve (Turbit, 2007). The PMBOK includes scope or requirements discovery as a key process in project scope management.
Here, business needs are converted into project objectives and project deliverables, which become the foundation for the entire project plan. Ideally, a project manager would receive a well thought out and well defined scope through the initial project brief, but in reality, this scarcely occurs, and a project manager must seek information to understand the true scope of the project. Finally, the PMBOK includes the process of “controlling” in its definition. The PMI, through this inclusion, has accepted that the scope of a project is fluid and scope change is inievitable (Lijoi, 2008).
In the project plan, the project manager has delicately balanced project scope, time and costs, and any additional changes to scope are likely to upset this balance and affect the other project measures. Change control involves ensuring changes to the scope of work are captured and approved by the designated people before being incorporated into the baseline plan, with corresponding chnages to time and budget (Burke, 2007). Uncontrolled scope changes are known as scope creep, which mostly occurs during project execution, which often result in rework, cost overrun and failure to deliver projects on time (Jordan, 2010).
Other project management literature focus on additional components in their definition of Project Scope Management. The APM bok defines scope manegement as ‘… defining the scope of the project and breaking this into manageable pieces’ (Burke, 2007 pp83). This highlights and refers to the Work Breakdown Structure (WBS), a process which lies at the centre of the PMBOK’s intertwined planning proceses, whereby the scope is subdivided into work packets. The planning of the project budget, schedule and most knowledge areas are based on the WBS, which is why this process is so critical.
Wawruck defines project scope as “the bounded set of verifiable end products, deliverables, or output that the project team undertakes to provide to the client (the owner or sponsor) of the project” (Wawruck, 2006). The reference to the client is one feature that the PMBOK excludes. The PMBOK definition is mostly inwards looking for the project team, in that the processes defined focus on how to deliver the project successfully from the project team’s point of view.
Modern project management identifies client satisfaction as the sole success factor for projects and ensuring the client’s needs are met are as essential, if not more than delivering the defined scope on time and to budget (Kerzner, 2004). Overall, the PMBOK’s definition of project scope management is satisfactory, greater consideration to the client could be included in the definition. Whilst important to define Project Scope Management, it is the actions that are taken within this knowledge area that are key to a project’s success.
The PMBOK Scope Knowledge Area contains five processes that are required for successful Project Scope Management: 1. Collect Requirements 2. Define Scope 3. Create WBS 4. Verify Scope 5. Control Scope The PMBOK, by design, is a reference guide of generally accepted practises that are applicable to “most projects most of the time” (Project Management Institute, 2008 pp4). The purpose of the guide is for a project management team to select the required processes and included actions that are relevant to the specific project and customise them to meet the needs of their unique project.
This holds true for project scope management, and when implementing the PMBOK’s definition of project scope management, the overall effort required for a smaller project, such as the building of a $200,000 house is going to be far less than a larger, more complex project such as a $200 million multi-storied/multi-purpose complex. However, this does not imply that any of the Project Scope Management processes can be fully neglected. Of most PMBOK processes, scope is most important. Time and budget cannot be planned without first planning scope and all other processes are derived from it (Maylor, 1999).
Because it is so critical, all processes in the project scope management knowledge area and must be carried out in all projects regardless of the size. Actions within each process may be scaled, but it is unwise to neglect any scope related process completely. In less important knowledge areas in the PMBOK, this is not the case, and some processes may be completely overlooked, depending on the needs of the project. In defining the scalability of individual processes of the PMBOK for different projects, it is important to identify how projects can be classified. In most businesses, projects are defined by their budget (Knoll, 2007).
The larger the budget, the greater the effort is placed in designing a project methodology, and more strict use of the PMBOK processes. In reality, factors such as project complexity, project management maturity, innovation required, schedule flexibility and strategic importance are of equal importance when comparing projects from a business perspective (Maylor, 1999, Knoll, 2007). For the purpose of this essay, these additional complexity characteristics will be assumed to be equal when comparing the house and complex examples. The first process defined by the PMBOK for project scope management is Collect Requirements.
At the outset of a project, a project team is provided with a project brief by the client or sponsor. This brief typically outlines the needs of the business and objectives of the project, and may or may not be clear. It is essential for a project manager to interpret and translate the objectives into tangible and measurable requirements and deliverables. This process is time consuming initially, but will prevent rework and additional effort due to misinterpreted customer requirements, which can have implications for project time, cost and quality (Burke, 2007).
The efforts required to carry out this process will partially be dependent on the project size, but mostly on the clarity of the project objectives. If the customer or sponsor has a clear understanding of the requirements of the project then this process will be more straight forward. The second process is Define Scope, which is the development of a detailed description of the deliverables of project, summarised in the Project Scope Statement. This scope statement contains details of the project’s deliverables, as well as risks, assumptions, constraints and exclusions.
Failure to accurately document scope can lead to rework, project delays and additional efforts required during the execution phase of the project. Project risk begins to be considered here, and documented for all parties to view. The scope statement requires client/sponsor sign-off ensuring that there is an agreement of objectives from the key parties involved in the project (Langdon, 2000). For internal business projects, this process can help gain support and commitment from senior management, and addresses risk early in the project, which will make life easier for the project team later in the project.
The project scope statement may be less detailed for smaller projects, but it is essential that it be prepared for all projects. The third process is Create WBS. In this process, the project deliverables are broken down into smaller manageable units or activities, known as the WBS. This process is important for three reasons. Firstly, the scope is subdivided into components, which can be assigned to an individual team member or department, which promotes accountability (Langdon, 2000) pp24.
Secondly, individual work packets are easier to monitor and control by the project manager. Finally, individual time and budget estimates are assigned to work packets, which are aggregated up to enable time and cost planning (Lijoi, 2008). This process is critical in the planning process as time and cost estimates are derived from the scope, and should implemented in all projects. The forth process in PMBOK’s Project Scope management knowledge area is: Verify Scope. In this process the project deliverables are formally accepted by stakeholders.
This is necessary in all projects to ensure that the client or project sponsor is satisfied with the final product or service, which in the end is the primary indicator of any project’s success, no matter the size. The final process recommended by PMBOK is Control Scope. In almost all projects, scope change will occur. They can be the result of incorrect definition “original needs”, or can emerge during the course of the project due to the customer’s changing needs or perceptions “emergent needs” (Maylor, 1999) pp14.
A scope change control system is necessary to monitor, evaluate and approve changes by the designated expert before the changes are incorporated into the baseline plan (Burke, 2007). When scope changes are made, there are likely to be appropriate changes to time, budget and quality. The impacts to the project of these changes must be made clear to the customer and clearly documented for traceability purposes. Failure to do this, will lead to scope creep, whereby uncontrolled features and functionality are added to the project. Although each change may be small, added together they can endanger a project (Kerzner, 2004).
Projects of all sizes require careful controlling of scope, and this process must not be neglected. The importance of Project Scope Management to the successful planning and execution of a project cannot be underestimated, because all other project components are based on a clear understanding of what the does and does not project involve. PMBOK recommends five structured processes for Project Scope management, which are essential to avoid common pitfalls, such as inadequate requirements and scope creep which can quickly derail a project and lead to project failure.
Although each individual process can be scaled according to project size, failure to carry out any of the Project Scope management processes can lead to disastrous results and is not recommended. Whether the project is a $200,000 house or a $2,000,000 housing complex, the complete PMBOK Project scope management should be carried out for all projects to maxmise the chance of project success. Birkby, G. (2003). Brief Encounter. Project: management of the Association for Project Management , 22-23. Bruce, A. , & Langdon, K. (2000).
Project Management. New York: Dorling Kindersly. Burke, R. (2007). Project Management Technques – College Edition . London: Burke Publishing. Jordan, A. (2010, January 4). Back to Basics. Retrieved March 15, 2010, from Gantthead: http://www. gantthead. com/content/articles/253628. cfm Jucan, G. (2006, June). Complexity Matters. Retrieved March 15, 2010, from Gantt Head: http://www. gantthead. com/content/articles/231775. cfm Kerzner, H. (2004). Advanced Project Management – Best Practises on Implementation. New Jersey: John Wiley & Sons Inc.
Knoll, K. (2007). Small Projects, big Results. PM Network , 28-33. Lijoi, G. (2008). Managing Project Scope. Retrieved March 15, 2010, from Project Smart: http://www. projectsmart. co. uk/managing-project-scope. html Loughrey, B. (2007). In Search of the Holy Grail: Project Management Success. Project: Magazine of the Association for Project Management , 24-25. Maylor, H. (1999). Project Management. Pitman Publishing: London. Project Management Institute. (2008). A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition.
Newton Square: Project Management Institute Inc. Turbit, N. (2007, Mar). Scope Tips. Retrieved March 15, 2010, from Project Perfect: http://www. projectperfect. com. au/info_scope_tips. php UTS: Project Management. (2006, April 6th). Project Scope. Retrieved March 15, 2010, from University of Technology Sydney: http://www. projects. uts. edu. au/stepbystep/planning1. html Wawruck, W. (2006). Managing Project Scope – A Neglected Dimension of Effective Performance on Diverse Projects. Retrieved Maqrch 15, 2010, from http://www. maxwideman. com/guests/scope/note. htm