Life and Spiritual Coaching

May 5, 2009

Scope Control

Filed under: PMP,Project Manager,Scope Management — by Donna Ritter @ 3:22 pm
Tags: ,

Who hasn’t been on a project where scope creep is an issue? One of my pet peeves is when people try to add functionality (or even a bug fix) and don’t realize they need to inform the Project Manager and all prior documentation has to be changed. An engineer may be able to code a fix very quickly, but if he does that has ramifications on documentation, schedule management and quality control (to name a few). When someone tries to pull this, I always draw the infamous triangle of scope, time/cost and resources. If one changes, the others will as well.

 

One way to formally control this is to implement a formal scope verification process where you require a change to be communicated to the stakeholders’ for formal acceptance of the completed project scope and associated deliverables. Verifying the project scope includes reviewing deliverables to ensure that each is completed satisfactorily. If the project is terminated early, the project scope verification process should establish and document the level and extent of completion.

 

Scope verification differs from quality control in that scope verification is primarily concerned with acceptance of the deliverables, while quality control is primarily concerned with meeting the quality requirements specified for the deliverables.

 

Quality control is generally performed before scope verification, but these two processes can be performed in parallel; and when a change occurs (that is accepted) all project team members need to re-examine their project documents and schedule. Any corrective changes go to the project manager and new plans and schedules are produced. Then a process of verifying the scope occurs. The following lists potential outputs from Scope verification:

 

·         Accepted Deliverables The Scope Verification process documents those completed deliverables that have been accepted. Those completed deliverables that have not been accepted are documented, along with the reasons for non-acceptance. Scope verification includes supporting documentation received from the customer or sponsor and acknowledging stakeholder acceptance of the project’s deliverables.

·         Requested Changes Requested changes may be generated from the Scope Verification process, and are processed for review and disposition through the Integrated Change Control process.

·         Recommended Corrective Actions

 

 

For a successful project, the Project Manager is in charge of scope control. Scope control is concerned with influencing the factors that create project scope changes and controlling the impact of those changes. Scope control assures all requested changes and recommended corrective actions are processed through the project Integrated Change Control process. Project scope control is also used to manage the actual changes when they occur and is integrated with the other control processes. Uncontrolled changes are often referred to as project scope creep. Change is inevitable, thereby mandating some type of change control process. The biggest thing to remember is to communicate to all team members and stake holders during this process. It is wise to institute a formal change control system.

 

A project scope change control system, documented in the project scope management plan, defines the procedures by which the project scope and product scope can be changed. The system includes the documentation, tracking systems, and approval levels necessary for authorizing changes. The scope change control system is integrated with any overall project management information system to control project scope. When the project is managed under a contract, the change control system also complies with all relevant contractual provisions.

 

Project performance measurements are used to assess the magnitude of variation. Important aspects of project scope control include determining the cause of variance relative to the scope baseline and deciding whether corrective action is required. Earned value management is very helpful here.

 

Approved change requests affecting the project scope can require modifications to the WBS and WBS dictionary, the project scope statement, and the project scope management plan. These approved change requests can cause updates to components of the project management plan.

 

A formal configuration management system provides procedures for the status of the deliverables, and assures that requested changes to the project scope and product scope are thoroughly considered and documented before being processed through the Integrated Change Control process.

 

 

Advertisements

January 10, 2009

Building a Work Breakdown Structure

Filed under: PMP,Project Manager,Scope Management — by Donna Ritter @ 11:27 pm
Tags: ,

Building a Work Breakdown Structure

The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project. The WBS subdivides the project work into smaller, more manageable pieces of work, with each descending level of the WBS representing an increasingly detailed definition of the project work. The planned work contained within the lowest-level WBS components, which are called work packages, can be scheduled, cost estimated, monitored, and controlled.

 

On projects I’ve worked on, the project team would go into a conference room and use post it notes for each piece of work until we reached something that was a week or less. NOTE: It’s easiest to bring a roll of paper to put the post it notes on so you can roll the whole thing up to input it into soft format.

 

The WBS represents the work specified in the current approved project scope statement. Components comprising the WBS assist the stakeholders in viewing the deliverables of the project.

 

Work Breakdown Structure Templates

 

Although each project is unique, a WBS from a previous project can often be used as a template for a new project, since some projects will resemble another prior project to some extent. For example, most projects within a given organization will have the same or similar project life cycles and, therefore, have the same or similar deliverables required from each phase. Many application areas or performing organizations have standard WBS templates.

 

The Project Management Institute Practice Standard for Work Breakdown Structures provides guidance for the generation, development, and application of work breakdown structures. This publication contains industry-specific examples of WBS templates that can be tailored to specific projects in a particular application area. A portion of a WBS example, with some branches of the WBS decomposed down through the work package level.

 

Decomposition

 

Decomposition is the subdivision of project deliverables into smaller, more manageable components until the work and deliverables are defined to the work package level. The work package level is the lowest level in the WBS, and is the point at which the cost and schedule for the work can be reliably estimated. The level of detail for work packages will vary with the size and complexity of the project.

 

Decomposition may not be possible for a deliverable or subproject that will be accomplished far into the future. The project management team usually waits until the deliverable or subproject is clarified so the details of the WBS can be developed. This technique is sometimes referred to as rolling wave planning.

 

Different deliverables can have different levels of decomposition. To arrive at a manageable work effort (i.e., a work package), the work for some deliverables needs to be decomposed only to the next level, while others need more levels of decomposition. As the work is decomposed to lower levels of detail, the ability to plan, manage, and control the work is enhanced. However, excessive decomposition can lead to non-productive management effort, inefficient use of resources, and decreased efficiency in performing the work. The project team needs to seek a balance between too little and too much in the level of WBS planning detail.

5

Decomposition of the total project work generally involves the following activities:

 

·         Identifying the deliverables and related work

·         Structuring and organizing the WBS

·         Decomposing the upper WBS levels into lower level detailed components

·         Developing and assigning identification codes to the WBS components

·         Verifying that the degree of decomposition of the work is necessary and sufficient.

 

This analysis requires a degree of expert judgment to identify all the work including project management deliverables and those deliverables required by contract. Structuring and organizing the deliverables and associated project work into a WBS that can meet the control and management requirements of the project management team is an analytical technique that may be done with the use of a WBS template. The resulting structure can take a number of forms, such as:

 

·         Using the major deliverables and subprojects as the first level of decomposition.

·         Using subprojects where the subprojects may be developed by organizations outside the project team. For example, in some application areas, the project WBS can be defined and developed in multiple parts, such as a project summary WBS with multiple subprojects within the WBS that can be contracted out. The seller then develops the supporting contract work breakdown structure as part of the contracted work.

·         Using the phases of the project life cycle as the first level of decomposition, with the project deliverables inserted at the second level.

·         Using different approaches within each branch of the WBS, where test and evaluation is a phase, the air vehicle is a product, and training is a supporting service.

 

Decomposition of the upper level WBS components requires subdividing the work for each of the deliverables or subprojects into its fundamental components, where the WBS components represent verifiable products, services, or results. Each component should be clearly and completely defined and assigned to a specific performing organizational unit that accepts responsibility for the WBS component’s completion. The components are defined in terms of how the work of the project will actually be executed and controlled. For example, the status reporting component of project management could include weekly status reports, while a product to be manufactured might include several individual physical components plus the final assembly.

 

Verifying the correctness of the decomposition requires determining that the lower-level WBS components are those that are necessary and sufficient for completion of the corresponding higher-level deliverables.

 

Outputs of Creating a WBS:

 

·         Project Scope Statement (Updates): If approved change requests result from the Create WBS process, then the project scope statement is updated to include those approved changes.

·         Work Breakdown Structure: The key document generated by the Create WBS process is the actual WBS. Each WBS component, including work package and control accounts within a WBS, is generally assigned a unique identifier from a code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information.

 

The WBS should not be confused with other kinds of breakdown structures used to present project information. Other structures used in some application areas or other Knowledge Areas include:

 

·         Organizational Breakdown Structure (OBS). Provides a hierarchically organized depiction of the project organization arranged so that the work packages can be related to the performing organizational units.

·         Bill of Materials (BOM). Presents a hierarchical tabulation of the physical assemblies, subassemblies, and components needed to fabricate a manufactured product.

·         Risk Breakdown Structure (RBS). A hierarchically organized depiction of the identified project risks arranged by risk category.

·         Resource Breakdown Structure (RBS). A hierarchically organized depiction of the resources by type to be used on the project.

 

The WBS Dictionary

 

The document generated by the Create WBS process that supports the WBS is called the WBS dictionary and is a companion document to the WBS. The detailed content of the components contained in a WBS, including work packages and control accounts, can be described in the WBS dictionary. For each WBS component, the WBS dictionary includes a code of account identifier, a statement of work, responsible organization, and a list of schedule milestones. Other information for a WBS component can include contract information, quality requirements, and technical references to facilitate performance of the work. Other information for a control account would be a charge number. Other information for a work package can include a list of associated schedule activities, resources required, and an estimate of cost. Each WBS component is cross-referenced, as appropriate, to other WBS components in the WBS dictionary.

 

The Scope Baseline

 

The approved detailed project scope statement and it’s associated

WBS and WBS dictionary are the scope baseline for the project. The next step is to estimate all of the work packages and create your baseline schedule.

 

July 3, 2008

Work Breakdown Structure

Filed under: PMP — by Donna Ritter @ 10:53 am
Tags: , ,

Have you ever mapped out a family tree? Our family has done this for years tracing us back to Charlemagne. Genealogy is favorite habit started my Grandfather.

A work breakdown structure (WBS) is very similar to a family tree. It maps out the deliverables of the project, with sub deliverables and activities stemming in a tree format. One of my favorite ways to do the WBS is with yellow post it’s so you can move them around to where they belong. Once I worked on a project where we had to tape together all of the papers that included the post it’s and it was at least 25 pages. This served us well when we showed management the magnitude of the scope of the project!

Doing this on large sheets of paper is useful so you can capture the finished product. A Guide to the PMBOK describes a WBS this way: “A WBS is a deliverable oriented grouping of project components that organizes and defines the total scope of the project; work not defined in the WBS is outside of the project”.

A Work Breakdown Structure is break down the work packages to enable you to roll them back up to a schedule that is complete. A work package is usually no more than 40 hours.

The WBS should detail the full scope of work needed to complete the project. Accuracy and completeness are required when composing your WBS.

Decomposition is one of the tools you will use when preparing your WBS. You should be able to break down the deliverables to a point where you can easily plan, execute, control and close out the project deliverables. Each work package should be able to be easily estimated in the Activity Definition Process.

You can think of this process in 4 major steps:

1.    Identify all of the major deliverables. The PMBOK is clear on noting that the deliverables should be defined according to the way the project is organized. One way is to organize a project in phases. The phases become the first level of decomposition, followed by the deliverables.

2.    Step2 involves estimating cost and duration. If that cannot be done, then you have to decompose further until the work package can be estimated. I usually use a work package of 20-40 hours at the most. Not all deliverables will have the same level of decomposition. In any case, a schedule cannot be made until the WBS is complete and has estimates that are as accurate as possible.

3.    Step 3 involves identifying components that make up the deliverables.

4.    Step 4 is the verification step. You need to determine that each component listed is clear, complete and necessary to fulfill the requirements of the deliverable. Also, you need to easily add up all the estimates, budget and assignments to create a solid schedule.

A WBS looks very much like a flow chart. The goal is to break down the work so that each work package can be assigned to a specific person for accountability and the Project Manager can easily manage the schedule knowing that all parts of the project have been broken down to their smallest part.

Each Work package is assigned a unique identifier and these are documented in the WBS dictionary. The dictionary includes a description of the work package, costs, budgets, schedule dates, resource assignments and activity descriptions.

This process sounds like a lot of work, but it is a known fact that the more you plan, the better you will be in the end.  I like to use SharePoint to keep this document and keep for the project records.

The WBS plays a major part of Project Management. For those taking the PMP certification course, I was told that if you didn’t know the answer to a question WBS probably was it!

Create a free website or blog at WordPress.com.