Project Scoping

Scope refers to the information required to start a project, and the features that the product must possess to meet its stakeholders requirements.

Scope Management is the process of listing the items to be produced or tasks to be done to the required quantity, quality and variety, with the resources available within the stipulated time agreed upon, and the modification of those variable constraints by dynamic flexible juggling in the event of changed circumstance called as Scope creep.

After defining the project charter, the project scope is finalized. The scope defines the resource requirement and listing the affected departments during the project execution. The tools applied for project scoping includes SIPOC, Pareto charts, brainstorming, etc to defining and documenting the project scope.

Project scope is primarily responsible for enlisting the tasks to be accomplished by the project. The process of project scoping helps to demarcate the work boundaries, and thereby detailing the required effort for successful completion of the project.

Under project management, the term scope has two distinct uses – Project Scope and Product Scope.

To arrive at a final approved project scope, is a very challenging task among all the activities in Project Management where defining and managing scope is the backbone for Project Management. Project scoping is not a single person’s activity as it involves a group of people mainly project stakeholders. Scoping is vital as it affects all other important factors in Project like schedule, cost, resources and risks. In general, high level of scope is available as part of Project Charter. Complete analysis is required to be done to prepare & review for project scope before approval. Project scope is progressively elaborated ad not completely done at the start of the project. Project scoping is more like the fences built on the construction site defining the boundaries of the project.

Scope management can be defined as the process of defining the tasks and then making sure all of those tasks are completed within the given time frame. Scope management plan should include the detailed process of scope determination, its management and its control.

Project scope must be planned in advance before the commencement of the project that is during mobilization phase. Project manager seeks for a formal approval on a well-defined and clearly articulated scope. In order to identify the scope, all the requirements must be gathered from all stakeholders. Large projects require more time, effort and resources to gather requirements and thus defining the scope is important.

Scope definition helps us to ensure that all the work done is included in the scope management plan. Any changes in the scope must take into account all the knowledge areas of project management such as time, cost, risk, quality, resources and customer satisfaction. An Integrated change management process is needed to approve changes to scope of a project.

Scope Statement

Scope statement primarily details the project deliverables and describes the major objectives of the project. These objectives of the project must include measurable success criteria for the project.

Scope statement should be specified before the statement of work and captures the product of the project for instance, “Developing a software based system to capture and track orders for software”. Scope statement includes the list of users using the product, as well as the attributes in the final product.

Baseline Scope Statements consists of,

1. Project charter
2. Project owner, sponsors, and stakeholders
3. Problem statement
4. Project goals and objectives
5. Project requirements
6. Project deliverables
7. Project non-goals (what is out of scope)
8. Milestones
9. Cost estimates

Statement of Work

Statement of work (SOW) is a document usually applied in the field of project management.

Features of Statement of Work

1. SOW defines all project-specific activities, deliverables and timelines for a specified vendor providing services to the clients.
2. SOW typically includes detailed requirements and pricing, with standard regulatory and governance terms and conditions.
3. SOW is often an important accompaniment to a master service agreement or request for proposal.
4. SOW has many specialized formats and styles of document templates for the hardware or software solutions described in the Request for Proposal (RFP).
5. SOW can be customized by organizations on their own that are specialized or generalized to accommodate typical requests and proposals they receive.

Statement of work (SOW)typically addresses the following subjects.

1. Purpose: Purpose defines the need for taking up the project i.e., why are we doing this project? Here a purpose statement attempts to answer this question.
2. Scope of Work: The scope of work describes the work to be done and specifies the hardware and software involved.
3. Location of Work: This location of work describes where the work is to be performed, including the location of hardware and software and where people will meet to do the work.
4. Period of Performance: This period of performance specifies the allowable time for projects, such as start and finish time, number of hours that can be billed per week or month, where work is to be performed and anything else that relates to scheduling.
5. Deliverables Schedule: Deliverables Schedules describes the lists and describes what is due and within what duration.
6. Applicable Standards: Applicable Standards describes any industry specific standards that need to be adhered to in fulfilling the contract.
7. Acceptance Criteria: Acceptance criteria specifies how the buyer or receiver of goods will determine if the product or service is acceptable, usually with objective criteria.
8. Special Requirements: Special requirements specifies any special hardware or software, specialized workforce requirements, such as degrees or certifications for personnel, travel requirements, and anything else not covered in the contract specifics.
9. Type of Contract/Payment Schedule: Project acceptance depends on the available budget needed to cover the work required. Therefore a breakdown of payments by whether they are up-front or phased will usually be negotiated in an early stage.
10. Miscellaneous: Many items that are not part of the main negotiations may be listed because they are important to the project, and overlooking or forgetting them could pose problems for the project.

Requirements Gathering Techniques

Requirements gathering refers to the process of data gathering techniques to document exact need of the customer.

Group elicitation techniques for Requirement Gathering

1. Facilitated workshops – It is technique that uses focused sessions which bring together key cross-functional stakeholders to define product requirements
2. Focus groups – It is technique that brings together pre-qualified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result.
3. Group creativity techniques – It involves techniques like Brainstorming, nominal group technique, mind-mapping, affinity diagram, multicriteria decision analysis that are used to gather the requirements and define the scope
4. Group decision-making techniques – In this technique decision on gathered information are arrived using analytic hierarchy process, voting/democratic methods. The final decision is arrived by one of the methods – unanimity, majority, plurality, dictatorship.

,Note inputs from subject matter experts(SME) plays a major role in the requirements gathering.  Some of the techniques that involves SME’s are,

1. Expert Judgment – In this case the judgment provided is based upon expertise in an application area, knowledge area, discipline, industry, etc., in accordance with the project scoping.
2. Interviews – Interviews are considered to be a formal or informal approach for getting information from stakeholders by talking to them directly. Different types of question whether open-ended/close-ended are used to gather the requirements
3. Questionnaires and surveys – Questionnaires and surveys are written sets of questions designed to quickly accumulate information from a large set of respondents

Some of the other methods to scope the project is to perform analysis with the given information are,

1. Document analysis – Technique used to analyze existing documentation and identifies information relevant to the requirements
2. Product analysis – Technique to define scope that generally means asking questions about a product and thereby forming answers to describe its utility, characteristics, and other aspects of what is going to be manufactured. This technique is applicable for projects that have a product as a deliverable.
3. Alternatives generation – Technique used to develop as many potential options as possible in order to identify different approaches available.
4. Context diagrams – Technique using a visual depiction of the product scope to depict a business system and also how different individuals and other systems interact.

Work Breakdown Structure (WBS)

Work break down structure can be defined as a hierarchical and incremental decomposition of the project into phases, deliverables and work packages. It is also referred to as a tree structure, which shows parts of effort required to achieve an objective, for instance a program, project, and contract.

In any project or contract, the WBS is formed by starting with the final objective and thereafter subdividing those objectives into manageable components in terms of size, duration, and responsibility like, systems, subsystems, components, tasks, subtasks, and work packages that include all the required steps to achieve the final objective.

Features of Work Break Down Structure

1. Development of the WBS normally occurs at the start of a project and precedes detailed project and task planning
2. Under work breakdown structure a common framework is developed to facilitate the process of natural development of the overall planning and control management system of a contract.
3. WBS is the basis for dividing work into definable increments from which the statement of work can be formed and also the technical, schedule, cost, and labor hour reporting can be established.
4. WBS allows adding up all the subordinate costs for tasks, materials, supply, into their successively higher level parent tasks, materials, etc.
5. For each element of WBS, a description of the task to be performed is generated.
6. WBS is a technique is used to define and organize the total scope of a project.
7. WBS is organized around the primary products of the project in place of the work needed to produce the products.
8. Well-designed WBS makes it easy to assign each project activity to one and only one terminal element of the WBS.
9. WBS helps map requirements from one level of system specification to another
10. WBS may be displayed horizontally in outline form, or vertically as a tree structure
11. WBS is a comprehensive classification of project scope and is not an exhaustive list of work.
12. WBS is neither a project plan, a schedule, nor a chronological listing.
13. WBS specifies what task will be done, and not how or when it will be done.
14. WBS is not an organizational hierarchy, but it can be used when transmitting

Design principles

One of the important design principle for work breakdown structures is referred as 100% rule. The principle of 100% rule states that the WBS includes 100% of the work defined by the project scope and takes into account all deliverables whether internal, external, interim – in terms of the work to be accomplished, including project management.

Features of 100% rule

1. 100% rule is one of the guidingprinciples for the development, decomposition and evaluation of the WBS.
2. This rule applies at all levels within the hierarchy.
3. Sum of the work at the “child” level must be equal to 100% of the work represented by the parent.
4. WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work.
5. 100% rule also applies to the activity level.
6. Work represented by the activities in each work package must add up to 100% of the work necessary to complete the work package.

Characteristics of work break down structure

Mutually exclusive elements

In addition to the 100% rule, it is very crucial to ensure that there is no overlap in scope definition between different elements of a work breakdown structure. Any kind of ambiguity could thereby result in duplicated work or miscommunications about responsibility and authority. Any overlap could also cause confusion regarding project cost accounting. So in case the WBS element names are ambiguous, then a WBS dictionary can help clarify the distinctions between WBS elements. In a WBS Dictionary the WBS elements are described as component of the WBS with milestones, deliverables, activities, scope, and also with reference to dates, resources, costs, quality.

Plan outcomes, not actions

As a rule it is important to ensure that the design of the work breakdown structure should not attempt to capture any action-oriented details in the WBS, as there is a possibility to include either too many actions or too few actions. In which case too many actions will exceed 100% of the parent’s scope and too few will fall short of 100% of the parent’s scope.

Therefore the best way to follow the 100% rule is to define WBS elements in terms of outcomes/results, and not actions. Thus ensuring that the WBS is not overly prescriptive of methods, allowing for greater skills and creative thinking on the part of the project participants.

1. For any new product development projects, one of the most common techniques that ensure an outcome-oriented WBS is to use a product breakdown structure.
2. For any feature-driven software projects may use a similar technique to employ a feature breakdown structure.
3. For a project that provides professional services, one of the common techniques used is to capture all planned deliverables to create a deliverable-oriented WBS.
4. For any work breakdown structures that subdivide work by project phases must ensure that phases are clearly separated by a deliverable also used in defining entry and exit criteria.

Level of Detail

One must ensure when to stop further sub division of work i.e., one must decide when to stop dividing work into smaller elements. Level of details helps to determine the duration of activities required to produce a deliverable defined by the WBS. Several heuristics or rules of thumb are  used to determine the appropriate duration of an activity /group of activities necessary to produce a specific deliverable defined by the WBS.

1. First rule of Thumb: First is the “80 hour rule” which means that no single activity or group of activities at the lowest level of detail of the WBS to produce a single deliverable should be more than 80 hours of effort.
2. Second rule of thumb: The second rule states that no activity or group of activities at the lowest level of detail of the WBS should be longer than a single reporting period. Thus if the project team is reporting progress monthly, then no single activity or series of activities should be longer than one month long.
3. If it makes sense rule – This rule of thumb, states one can apply common sense when creating the duration of a single activity or group of activities necessary to produce a deliverable defined by the WBS.

Work package at the activity level

1. It is a task that can be realistically and confidently estimated
2. It is a task that makes no sense practically to break down any further
3. It is a task that can be completed in accordance with one of the heuristics defined above
4. It is a task that produces a deliverable which is measurable
5. It is a task that forms a unique package of work which can be outsourced or contracted out

Coding scheme

Under the coding scheme the work breakdown structure elements are numbered sequentially to reveal the hierarchical structure. The sole objective for the numbering is to provide a constant  approach to identifying and managing the WBS across like systems regardless of vendor or service.

A coding scheme assists the WBS elements to be recognized in any written context and allows for mapping to the WBS Dictionary.

One of the practical example of the WBS coding scheme

1.0 Aircraft System

1.1 Air Vehicle

1.1.1 Airframe

1.1.1.1 Airframe Integration, Assembly, Test and Checkout

1.1.1.2 Fuselage

1.1.1.3 Wing

1.1.1.4 Empennage

1.1.1.5 Nacelle

1.1.1.6 Other Airframe Components 1..n (Specify)

1.1.2 Propulsion

1.1.3 Vehicle Subsystems

1.1.4 Avionics

1.2 System Engineering

1.3 Program Management

Terminal Element

Terminal element is the lowest element in a tree structure which cannot be further subdivided. In a Work Breakdown Structure such elements are also known as work packages, these are the work packages that are estimated in terms of resource requirements, budget and duration that is linked by dependencies and schedules.

At the start of the WBS element and organization unit, control accounts and work packages are established and performance is planned, measured, recorded and controlled. Note that WBS can be expressed down to any level of interest where three levels are the minimum recommended for any structure, where additional levels are assigned for only items of high cost or high risk. Only two levels of detail are required at cases such as systems engineering or program management.

Consistent to Norms

A superior WBS structure should abide by the norms or mandates that  exist within the organization or domain. For instance, a shipbuilding for the U.S. Navy must respect the nautical terms and its  hierarchy structure put into MIL-STD as embedded in Naval Architecture. The matching Navy offices and procedures have been built to match this naval architecture structure, so any significant change of WBS element numbering or naming in the hierarchy would not be suggested.

Illustration of Work Break Down Structure

Diagram below, illustrates a work breakdown structure for a construction technique which demonstrates the 100% rule and the progressive elaboration technique to build a custom bicycle.

Diagram Explanation

1. WBS Level 1 – The first level shows 100 units of work as the total scope of a project to design and build a custom bicycle.
2. WBS Level 2 – At the second level the 100 units are divided into seven elements where the units allocated to each element of work are based on effort or cost and not an estimate of task duration.
3. WBS Level 3 – At the third level the three largest elements (Frame set, wheel and integration) of WBS Level 2 are further subdivided at Level 3. In the given illustration the two largest elements at Level 3 each represent only 17% of the total scope of the project. Where, these larger elements could be further subdivided using the progressive elaboration technique described.

The WBS design is also supported by software to allow automatic rolling up of point values. Where the estimates of effort or cost can be developed through discussions among project team members. The collaborative technique helps in building greater insight into scope definitions, underlying assumptions, and consensus regarding the level of granularity needed to manage the projects.