Showing posts with label Project Scope Management. Show all posts
Showing posts with label Project Scope Management. Show all posts

Friday, April 21, 2017

Work Breakdown Structure (WBS) in Project Management

By With 1 comment:
The Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of the project. While creating WBS, we sub-divide the project scope into smaller, more manageable components. Each descending level of WBS represents an increasing level of details of the project.

The lowest level of WBS are known as work packages. The decomposition in WBS happens to the level for which cost and duration can be estimated and managed. Adequate care should be taken as excessive decomposition might lead to non-productive management effort, inefficient use of resources, decreased efficiency in performing the work and difficulty in schedule and cost estimates.

A sample, simplified version of work breakdown structure (WBS) is shown below for a construction project. You can create similar work breakdown structure in software project management or any other project you are working on.


Characteristics or Benefits of Work Breakdown Structure (WBS) in Software Project Management

The following are some of the characteristics of benefits of using Work Breakdown Structure (WBS) in Software Project Management:
  • The WBS serves as an effective communication tool among various stakeholders involved in the project
  • The WBS components represent verifiable products, services or results.
  • The WBS include all product and project scope, including the project management work.
  • The WBS should ensure that all necessary work is performed, but no extra work is performed. This is known as the 100 percent rule.
  • The WBS allows team buy-in of all the work to be performed in the project. It allows team members to understand how their individual contribution fits in the overall project scenario
  • The WBS is the foundation for all project management planning. It provides the framework for the schedule and cost management plans, allowing for consistency with the estimates, schedules, budgets and control. One of the key reasons for excessive changes in a project
  • The WBS provides the relationships among all the components of the project and the project deliverables.
  • The WBS provides a structured depiction of what has to be delivered by the project.

5 steps to creating Work Breakdown Structure (WBS)

The typical steps required to create a work breakdown structure is as follows:
  • Identifying and analyzing the project deliverables
  • Organizing the WBS structure
  • Decomposing the project deliverables to the level of work packages
  • Developing and assigning identification codes to the WBS components (Code of Accounts is a numbering system used to uniquely identify each component of the work breakdown structure)
  • Verification of the created WBS

What is Scope Baseline?

Scope Baseline includes the following components:
  • Project scope statement
  • WBS and
  • WBS dictionary
The WBS dictionary provides detailed information about the deliverables and a description of the work for each work package in the WBS. It might include details like unique identifier, description of the work to be done, assumptions, constraints, acceptance criteria, person or unit responsible for delivering the work, milestones, etc. The development of WBS dictionary helps in identifying any missing information or errors in WBS.

Saturday, September 12, 2015

Flow of deliverables: Step by Step

By With 2 comments:
We will understand, in this article, the flow of project deliverables. The entire flow of deliverables are explained step-by-step, outlining how the deliverables are produced, verified and accepted.

PMBOK® Guide Fifth Edition defines deliverable as
any unique and verifiable product, result or capability to perform a service that is required to be produced to complete a process, phase or project.


Direct and Manage Project Work

We create Project Deliverables in Direct and Manage Project Work process to meet the project work as planned and scheduled in the project management plan.

Control Quality

The deliverables, created in the Direct and Manage Project Work process, are verified in the Control Quality process to determine the correctness of deliverables. In this process, we are concerned with the correctness of the deliverables and meeting the quality requirements specified for the deliverables. Such verified deliverables from the Control Quality process becomes an input to Validate Scope process for formalized acceptance.

Validate Scope

In the Validate Scope process, we are interested in the acceptance of the verified deliverables. Deliverables that meet the acceptance criteria are formally approved and signed by customer or sponsor. Formal documentation acknowledging the acceptance of the project deliverables is forwarded to the Close Project or Phase.

The completed deliverables that have not been formally accepted are documented along with the reasons for non-acceptance. These deliverables may require a change request (defect repair) that will be reviewed in the Perform Integrated Change Control process. Once the change requests are approved, the approved change requests become an input to the Direct and Manage Project Work process and the above cycle continues.

Please note that Control Quality is generally performed ahead of the Validate Scope, but you may also perform the two processes in parallel.

Monday, December 3, 2012

Deliverables to Final Product: The Transition

By With 2 comments:
I wanted to create this picture to show you clearly the transition of deliverable to final product, service or result within the project management context.

  1. Deliverables are created as part of the "Direct and Manage Project Execution" process. As you would expect, the deliverables are outputs of the Execution process group.

  2. The deliverable, thus created during project execution, is fed as input to the "Perform Quality Control" process in Monitoring & Controlling process group. Necessary quality control checks are carried out to ensure that the deliverable meet the requirements. At the end of the process, we get the Validated deliverable as an output.

  3. The validated deliverable is sent as an input to the "Verify Scope" process. Here, the client/ customer inspects the deliverable and accepts them. As such, the output of this process is the accepted deliverable. The major difference between "Perform Quality Control" and "Verify Scope" is that generally quality control is performed internally within the performing organization while verify scope is performed with the client/ customer. They may be done sequentially or sometimes concurrently.

  4. Finally, the accepted deliverable is sent as an input to the "Close project or phase" process in the Closing process group; and the output is Final product, service or result transition. This refers to the acceptance of the final product, service, or result and the turnover of the product to the organization. This usually requires a formal sign-off to indicate that the product is accepted by the customer.
Hope the above picture helps you to remember the flow of deliverables better. What do you think? Please leave your comments.