Tag: Earned Value Management

The effects of activity time variance on critical path planning

A Critique of

Lanny A. Karns and Lloyd A. Swanson

Article

“The effects of activity time variance on critical path planning”


Table of Contents

Abstract

Introduction

Network Analysis: CPM & PERT

Conclusion

Abstract

Critical Path Method (CPM) and Program Evaluation and Review Technique (PERT) are the two most commonly used networking techniques for defining the duration of project tasks. While they have much in common, they’re based on different concepts and both were independently developed. PERT defines a probabilistic distribution of activity time defined using three time estimates which emphasizes minimum project duration while downgrading cost restraints. CPM uses one deterministic time estimate emphasizes cost over time restraints. CPM is the most popular of the two methods as it is deemed easier. Lanny Karnes and Lloyd Swanson in their article “The effects of activity time variance on critical path planning“ advocate combining the two methods asserting they cannot be totally independent due to an obvious relationship between time and cost ( Karnes, 2007).

Introduction

It is well known that there are many techniques Project Managers can use to support better project planning. Critical Path Methodology (CPM) and Program Evaluation and Review Technique (PERT) are two such tools that ae used by many Project Managers. These two techniques, while derived independently of one another, cannot be totally independent due to an obvious relationship between time and cost. While CPM emphasizes cost over time restraints and PERT emphasizes time over costs restraints, perhaps there is a way to bring the two together. Karnes believes the best way to combine these two would be to put CPM’s crashing strategy together with PERT’s probability distribution of activity times come out with the best possible duration and cost for the project (Karnes, 2007).

The three estimates of PERT; optimistic, most likely, pessimistic, are combined to determine an expected duration and variance for each activity. These expected times are used to create the critical path and the variances are added to determine the project duration variance. From these numbers we can develop a probability distribution showing project completion times. The problem here is that if the activity variances lie outside the critical path then they’re not considered when determining the project variance. The fact that they’re not considered can lead to errors in determining total project duration. A similar issue can happen when using CPM’s crashing strategy where multiple paths through the network have similar or close lengths. If we drop the assumption of deterministic activity times and the duration is allowed to vary, a decrease in the length of the critical path may not result in a similar decrease in project duration because of variances inherent in parallel paths. Simply allowing activity times to vary; which inevitably they will do in real life, can result in serious problems with CPM’s crashing strategy leading to wasted time and money (Karnes, 2007).

Network Analysis: CPM & PERT

Using CPM and PERT for network analysis can provide invaluable information for planning, scheduling and executing projects. The main purpose of network planning is to avoid crisis management by using picture representations (graphs) showing the total project activities in a logical order. This aids in determining sequencing and duration of activities and the project. The following information can obtained from such a graphical picture (Kerzner, 2009):

  • Interdependencies of activities
  • Project completion time
  • Impact of late starts
  • Impact of early starts
  • Trade-offs between resources and time
  • Supposing exercises
  • Cost of a crashing
  • Performance Slippages
  • Performance Evaluation

CPM was mainly worried with creating activity prerequisites and determining simple network solutions. It was primarily useful for keeping track of activities and identifying activity conflicts or sequencing flexibilities which could affect project completion. Later on, cost slope analysis was developed as a way to calculate the shortest project time within the constraints of costs and time constraints. This technique was used to determine effective savings in time when it is possible to “crash” or shorten the individual activity times. The time actually saved is divided into the cost increase from compressing the activity to define the net cost slope. The slopes are compared to the costs to determine if reducing project duration will result in cost savings.

PERT was designed to overcome inherent problems in assuming activity time estimates deterministically. By coming up with three activity time estimates it allows the user to develop a probability distribution for the length of each activity. Once this is accomplished the user can calculate sequencing and network solutions in a manner similar to CPM. PERT is a management planning tool that can be used as road map where the activities have been identified along with interdependencies. A PERT chart is usually designed from back to front with the end date in mind (PMBOK, 2013).

Using both CPM and PERT, a Project Manager (PM) is able to determine, with some degree of accuracy, the overall length of the project by determining the duration of each activity. From this analysis the PM can also determine the interdependencies of each activity and thus is able to sequence these activities in a logical order. From this information the PM can determine the Critical Path of the project seeing those activities that have no slack in comparison to those that do have slack (lags and leads). Through network analysis the PM can determine how to better utilize resources more effectively and to track how the project progresses thus keeping effective control on time and costs.

Conclusion:

Combining the best of CPM and PERT can make it so that the PM can accurately estimate the amount of time and cost for each activity in the project. But, we have to keep in mind that these are still estimates. One can reasonably assume, through probabilistic analysis, how accurate these estimates are; it still needs to be taken with a grain of salt by keeping a watchful eye on the projects progress. PM’s have to keep in mind how difficult it is to get PERT’s three activity estimates from the subject matter experts or those who will perform the work. Probably part of the reason why many PM’s choose to use CPM over PERT is due to it being easier to determine duration from past history then to wrangle it out of software programmer.

References:

Karns, L. A., & Swanson, L. A. (2007). The effects of activity time variance on critical path planning. PMI. Retrieved from http://www.pmi.org/learning/time-variance-critical-path-planning-1959

Kerzner, H. (2009). Project management: A systems approach to planning, scheduling, and controlling. Hoboken, NJ: John Wiley & Sons.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.

Project Planning: Improved approach incorporating uncertainty

A Critique of

Vahid Khodakarami, Norman E. Fenton, and Martin Neil

Article

“Project Planning: Improved approach incorporating uncertainty”


Table of Contents

Abstract

Introduction

CPM and Uncertainty

Bayesian Network

Conclusion

Abstract

Because of the unique nature of projects, there may be uncertainties or differences in the products, services, or results that the project creates. By its very definition a project and its activities can be new to members of a project team, generally necessitates more out-and-out planning than other routine work. It inevitably involves uncertainty. The basic inputs of time, cost, resources for planning are not deterministic and can be affected by uncertainty. Vahid Khodakarami, Norman E. Fenton, and Martin Neil feel there is a causal relationship between these uncertainty sources and project parameters and this causality isn’t considered in current project planning methodologies. In their paper they present an approach, using Bayesian network modelling that they feel addresses both uncertainty and causality in project management. And they show this using the Critical Path Method (CPM) to handle uncertainty and how you can manage different sources and parameters of uncertainty in project planning.

Introduction

It is well known that there are many techniques Project Managers can use to support better project planning. Critical Path Methodology (CPM) is one such tool that is used by many Project Managers. There are many ways to consider uncertainty in project planning. Group Creativity Techniques such as brainstorming, nominal group technique, idea/mind mapping, and affinity diagram, and multicriteria decision analysis all help to take uncertainty into consideration when planning a project. Khodakarami feels that these techniques rarely quantify uncertainty effectively. Their paper focuses on project scheduling and in risk management.

Risk management, while it includes identifying, analyzing and responding to potential risks by using mediation planning, it was felt that it pays too much attention to the positive events while minimizing the adverse events since the term risk is associated with events instead of uncertainty(Khodakarami, 2007).  In their article the authors point out that using Bayesian Networks in conjunction with CPM helps to address uncertainty in scheduling because it allows you to take into consideration many different knowns rather than speculating on unknowns.

CPM and Uncertainty

Risk management is highly important to project planning. If the PM doesn’t consider and plan for risks they’re only planning to fail. The current view of risk is restrictive when it comes to uncertainty because it looks at events rather than sources of uncertainty. One source of uncertainty is activity duration. Normally duration is determined by looking at past history and by talking with subject matter experts (SME). Much uncertainty comes from not knowing exactly how long it could take to actually complete a task. This uncertainty arises from not knowing resource availability, possible occurrence of identified risks, lack of prior experience and the subject nature of the data such as expert judgement.

Critical Path Methodology is a deterministic technique for determining scheduling. It calculates the critical path (CP) by outlining the network of dependencies between tasks and determines duration for each arriving at what the earliest time is the project could be completed. It has a starting task and determines the order of the tasks using dependency between the tasks drawing out a network diagram that shows the tasks and their dependencies. Using the estimated durations for each task the PM can determine the earliest and latest start times and finish times for each task. From this calculation the PM would be able to draw out the critical path because he would be able to see which set of tasks have no slack time between them. This is the critical path of all tasks that have to be completed with their given timeframe, all other tasks have flexible amount of time between them that should they start earlier or later it will have no effect on the overall project schedule.

The critical path can be calculated using the following formulas:

D – Duration

ES – earliest start time

EF – earliest finish time

LF – latest finish time

LS – latest start time

The earliest start and finish times are determined by working forward through the network diagram, determining the earliest time a task can start and finish using the start and finish time of its predecessors. The first task always starts with zero. The latest start and finish times can be determined by working backwards through the diagram.

Bayesian Network

Bayesian Networks provide decision-support for a wide range of problems involving uncertainty and probabilistic reasoning. It is a probabilistic graphical model that represents a set of random variables and their conditional dependencies. For example, it could represent the probabilistic relationships between diseases and symptoms. If symptoms are known, the network can be used to determine the probabilities of other various diseases (Wikipedia, 2015).

An example of a Bayesian Network could be:

Sprinkler        < – >         Rain

Wet grass

The main use of Bayesian Networks (BNs) would be for statistical probability outcomes. The idea is that the PM has a set of known events and they want to determine potential outcomes. BNs can explicitly quantify uncertainty, reason from effect to cause as well as vice-versa, make predictions from incomplete data, and combine objective and subjective data arriving at decisions based on visible auditable reasoning. resources’.

As the project advances duration of an activity becomes a known and by equating actual with predicted durations, the BNs can update the probable estimations for risks and resource usage and as such, this distribution can be used for later for estimating more accurately other activities with similar dependencies.

Conclusion:

Using BNs to help improve the planning process makes sense. It is better able to determine the probability of events occurring. Many current methods are too deterministic in their evaluations; CPM for example. But by combining CPM and BNs the PM can bring the power of BNs so that their plans schedules are more realistic and they’re better able to make an informed decision based on better information. But one has keep in mind from decision making under uncertainty is the risk that the project manager wishes to incur (Kerzner, 2009). Even with BNs being a better tool to use to narrow down uncertainty, it is still uncertainty.

References:

Bayesian network – Wikipedia, the free encyclopedia. (n.d.). Retrieved October 8, 2015, from https://en.wikipedia.org/wiki/Bayesian_network

Kerzner, H. (2009). Project management: A systems approach to planning, scheduling, and controlling. Hoboken, NJ: John Wiley & Sons.

Khodakarami, V., & Fenton, N. (2007). Title: “Project Scheduling: Improved approach to incorporate uncertainty using Bayesian Networks. Project Management Journal, 38(2), 39-49.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.

Effective Management of Project Change Orders

A Critique of

Edward E. Douglas’s

Article

“Effective Management of Project Change Orders”


Table of Contents

Abstract

Introduction

Planning for Change

Planning and Design

Change during Application Build

Closeout

Conclusion

Abstract

Scope is the total sums of all the products/services that are required to complete a project (PMBOK, 2013). But even when the scope has been completed and a freeze is agreed upon, change occurs. Edward Douglas’s article “Effective management of project change orders” discusses how to effectively manage any requested changes that may come up during the life of the project. And while he concentrates considerably on the construction industry, much of what he suggests is applicable to any project. Could these concepts be used in another industry such as IT applications development projects? This paper will explore that possibility.

Introduction

Scope is the total sums all the products/services that are required to complete a project (PMBOK, 2013). But even when the scope has been completed and a freeze is agreed upon, change occurs. Edward Douglas’s article “Effective management of project change orders” discusses how to effectively manage any requested changes that may come up during the life of the project. And while he concentrates considerably on the construction industry, much of what he suggests is applicable to any project.

In this paper I will apply what Mr. Douglas suggests to Information Technology (IT) projects as there are a lot of similarities in the methodology Edwards advocates. For instance, we can all agree that the earlier we can identify a change the easier it would be to implement that change and the less costly it would be to implement. Further into the life of the project, the harder it will be to implement and the cost goes up. For example, it is much easier to change the foundation of a house before you pour it then it is to do so after the roof has been installed. In the programming world, it is much easier to make changes to the user interface while it is still in design then it is when you’re ready to push it out to production. There are many different methods and processes that can be put into place to help ensure that changes are identified and considered early in the process rather than later. Are these 100% effective? No, but it does help to eliminate many a costly error or change.

Planning for Change

Before any planning of what the project is actually to do begin, the project leadership needs to develop a project change management plan. The object is to put into place an agreed upon process for managing change should it occur.

The change management plan needs to plan who has the authority to approve changes. One has to take into consideration the threshold in which a change, such as a simple one, can be made by the project team, or if it is of such impact to the project that it needs to be approved by a higher authority. The plan has to outline the process for approval and everything that is needed for approving changes.

This plan needs to consider the process for submitting the requested change. Questions to be answered are who can make the change request? Who does a change request need to be submitted to? These are not easy to answer questions. Usually it’s the Project Manager who should initially receive the initial request for change. But sometimes one of the lead managers can receive a change request and then submit it to the Project manager. But, a change request should always go through the Project Manager since they oversee the entire project and can see impact where others are not aware (PMBOK, 2013).

The change management plan needs to consider how a change will be analyzed for impact to the project. What will be the impact to the schedule? Will it require overtime or extra resources or specialized help (availability)? Once the change request goes through impact analysis it will need to go through the approval process. The analysis process needs to outline what information is required and in what format should it be delivered and to whom it should be delivered in order to get approval. Should all change requests go through a steering committee for consideration, or can the PM decide that a requested change is too far outside the scope of the project for it to proceed (Verzuh, 2012)? Perhaps consideration of the change will take away resources from work underway and will have an adverse effect on the project timeline and budget; should the project budget money towards considering change requests?

Planning and Design

The most appropriate phase in which to take on change would have to be during the planning and design phase. It is best to consider and implement change as early as possible in the project as it is easier to and more cost efficient than it would be in later phases (Douglas, 2003). It is recommended that the PM and the sponsors freeze the scope of the project as early as possible in the planning or design phase. This holds true in construction as well as in IT projects; IT projects will find it a little easier to make changes to the scope even while in the execution phase. The master schedule should also be completed and approved during this period so that any requested changes can take into consideration impacts to it. Early completion of the design of the application will allow for build reviews and to catch any possible changes before construction of the application even begins.

By determining the scope, the work required, like through a Work Breakdown Structure (WBS) and completing the design of the application before even beginning to execution a build the project team can identify any changes that may be needed and to determine if implementation is needed. If the change identified is needed then the steering committee can determine if it wants to approve the impact the change will have to the project.

Change during Application Build

Since the project leadership team created a change management plan early in the project it would seem reasonable to say that any changes to the scope would go through this process before any change occurs.

The team would have to be thoroughly knowledgeable on the project plan and scope and understand the impact any change could have on its outcome. When a change is requested the team would have to put together an analysis of the impact that change may have. The PM would have to determine if he even wants to commit resources to doing the analysis of a requested change. The first questions to be answered are whether there is time and money in the project to consider changes. Another concern would be the impact of cumulative changes to the project. The danger here would be scope creep and budget overruns leading to financial failure of the project (Douglas, 2003).

Closeout

The concern here is that if the project is not properly closed; have all changes been completed; have all changes been properly documented, even those not approved? Subcontractor and vendor claims have to be closed before usage of the projects product and/or service is used. Potential problems include changes that were not completed properly or just simply not done. If the project is not properly closed problems could crop up. Too often closing the project is given little notice. The project team and leadership have often moved on to other projects leaving the PM to try to clean up the pieces.

Conclusion:

Douglas points out that it is best to develop and to put into place a proper change management plan. PMI points out that it is best to develop a number of management plans that help to guide the different processes of the project; a plan for each phase, so to speak. Many of the suggestions and guidance given by Douglas can be used in projects in other industries, too.

References:

Douglas, E. E. (2003). Effective management of project change orders. AACE International Transactions; ABI/INFORM Global, PM111.

Kerzner, H. (2009). Project management: A systems approach to planning, scheduling, and controlling. Hoboken, NJ: John Wiley & Sons.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.

Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.

Applying the work breakdown structure to the project management lifecycle

A Critique of

Shelly A. Brotherton, PMP

Robert T. Fried, PMP

Eric S. Norman, PMP, PgMP

Article

“Applying the work breakdown structure to the project management lifecycle”

Table of Contents

Abstract

Introduction

WBS Structure

Work Packages

Aligning with Scope

Going from WBS to Scheduling

Conclusion

Abstract

To some the Work Breakdown Structure (WBS) can be a burdensome chore. To others it is a necessary tool in which to define the tasks, and only the tasks needed, to complete a project successfully. Today, project managers are discovering the high value associated with creating work breakdown structures (WBS) early in the course of project management and a projects success may be attributed specifically to use of a WBS.

Project Managers know that many things can and do go wrong with projects. Much of the failures can be attributed directly to poor planning, and especially with poor development of a WBS. Ms. Brotherton, Mr. Fried, and Mr. Berman article discusses in detail the concepts and usage of a deliverable-oriented WBS in project management. This paper discusses their views on using a WBS in a project, its development and usage throughout the project, and compares their analysis with the goals of the class syllabus.

Introduction

The Work Breakdown Structure (WBS) is used in project management to identify and organize the tasks needed in which to complete a project successfully. It only calls for those tasks needed, and only those tasks needed, in which to reach a successful outcome (PMBOK, 2013).

The WBS can be very basic or it can be very sophisticated. WBS’s can be simple, perhaps too simple. The Project Manager (PM) has to be careful not to create a WBS that is too simple that it fails to adequately identify and describe the tasks needed to complete the project. This poorly developed WBS causes misunderstanding, rework, and leads to costly delays. It can also make it difficult to identify when problems arise due to an inability to identify what needs to be done and in what order.

The WBS can also be over-complicated, from decomposing work packages too much so that it over defines how the work is to be done, to having so many work packages with short durations it makes it difficult, if not impossible, to manage.

Ms. Brotherton, Mr. Fried, and Mr. Berman article, “Applying the work breakdown structure to the project management lifecycle” discuss in detail how a deliverable-oriented WBS is applied to a project and focuses on why the WBS is needed while also pointing out some of the pitfalls to be aware of. They point out that project success can be directly attributed to creating a well thought out WBS (Brotherton, 2008). Poorly developed or planned WBS can result in detrimental project outcomes including re-planning, rework, unclear work assignments, scope creep, increasing budget costs, missed target dates, unusable products and/or delivery features. Even worse, you have a very unhappy project sponsor.

WBS Structure

When planning a project the project manager needs to determine the work that needs to be done to complete the project successfully. He does this by creating a Work Breakdown Structure (WBS). A WBS is the process of subdividing the project deliverables and project work into smaller and smaller elements commonly referred to as work packages (PMBOK, 2013).

The WBS provides a common framework from which to organize all the work needed to complete the project. A WBS can be made up of different levels with the number of levels determined by the project needs. The first three levels will usually reflect the integrated efforts of the project. Level one, sometimes called the “home” level, concerns the authorization and release of work. Another rule to keep in mind is the 100% rule (Kerzner, 2009). The 100% rule represents 100% of the total work of the project. Each level below the previous level has to add up to 100% of the level above it. Level two is reserved for budgetary information; level three usually involves scheduling. Levels four and lower make up the work packages of the project. The sum of the work of the child level must equal 100% of the work at the parent level. Each level is planned in sequential order identifying dependencies and order of completion keeping in mind that some tasks can be done in parallel to others.

Work Packages

Each of these work packages need to be manageable, independent or have minimal interface with other ongoing elements, be Integratable and measureable. It has to have clearly defined start and end dates. All objectives must be linked to company goals. Responsibilities for each element is determined and assigned using a responsibilities assignment matrix (RAM). The focus should be on deliverables deriving tasks and organizing those tasks into work packages (Brotherton, 2008).

A work package represents a decomposition of the upper level deliverables into fundamental elements where the components are verifiable and measurable. Verifying the level of decomposition only requires doing the amount of work that is necessary and sufficient to complete the deliverable required by the project. Ideal packages are usually 80 hours or two to four weeks in length (PMBOK, 2013).

Aligning with Scope

One important aspect of a WBS is to ensure that each of the deliverables and associated tasks align with the goals of the project and the company. The PM can do this using a scope sequencing process to show dependencies between different elements identified in the WBS. Like in building a house, you need to show the sequence of the different parts of the deliverables identified in the scope of the project; first you need the foundation, then the walls, than the roof. The PM can show this relationship by using a dependency diagram (Brotherton, 2008):

Going from WBS to Scheduling

One issue bothersome to PM’s has always been taking the various levels of the WBS from definition to actual scheduling. Brotherton points out the PMBOK guide shows the PM specifically how to go from a deliverable-oriented WBS to scheduling in five easy steps (Brotherton, 2008).

First: The PM defines the activities. The tools used here are decomposition, rolling wave planning, and expert judgment (PMBOK, 2013)

Second: Sequencing the activities. As just stated, you need to set the order in which the activities are to be done. You do this by identifying the relationships and the dependencies between elements.

Third: Estimating the resources needed. How many people are needed for which task. This part of the process will help with determining the budget for the project.

Fourth: Estimating project durations. Here the PM, using tools like past history and expert judgment, determines how long each task should take. Combined with number three above a total budget can be estimated.

Fifth: Develop the project schedule. With all of the above information, a project schedule can be determined thus documenting the total time it should take to complete the execution portion of the project. Add in a start date and a completion date can be determined.

Conclusion:

The WBS is a very important piece of a project. It further defines the scope of the project so that by its completion the sponsor, the steering committee and the project team will have a fully approved understanding of what their project entails. It will provide a detailed description of all the tasks needed to complete the required deliverables within the scope of the project. It will show the sequence in which the work needs to be done. It will be a useful tool in determining the scheduling of the project and for being able to track those activities to ensure the project is on schedule and within the scope and cost of the project since everything within the WBS is trackable (Fleming, 2010).

References:

Brotherton, S. A., Fried, R. T., & Norman, E. S. (2008). Applying the work breakdown structure to the project management lifecycle. PMI. Retrieved from http://www.pmi.org/learning/applying-work-breakdown-structure-project-lifecycle-6979

Fleming, Q. W., & Koppelman, J. M. (2010). Earned value project management. Newtown Square, PA: Project Management Institute.

Kerzner, H. (2009). Project management: A systems approach to planning, scheduling, and controlling. Hoboken, NJ: John Wiley & Sons.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.

WBS Explained

WBS stands for “Work Breakdown Structure”. Simply put, it delineates the work required to complete the project. A WBS makes a Project Managers life easier, and it ensures a complete understanding of the work required to complete the task at hand. A WBS is the delineation of the scope into work packages and activities required to complete successfully. It represents total project scope as well as product scope.

I have witnessed during my time as a Project Manager many a practicing project manager not using the WBS correctly or at all. Many find it burdensome; others think it’s useless, and others just do not understand how it. What’s worse is when management sees no value in the exercise of putting a WBS together.

A WBS is easy to understand and quite easy to create. It has immense effectiveness serving as an anchor for many a successful completed project. There are numerous publications that can guide you in developing a WBS. I will focus on the importance of a WBS to the project and some detail on writing one.

A WBS takes time, thought, and collaboration. It should have a method for identifying the hierarchy in either a hierarchical chart or as an outline. It should include a WBS Dictionary that explains in detail how to complete each package/activity. The dictionary spells out the expectation of the deliverable.

  • A WBS can receive information from:
    • The scope management plan
    • The scope statement
    • The requirements document
  • The WBS is related to:
    • WBS dictionary
    • Scope baseline
  • It provides information to
    • Activity list
    • Activity cost estimates
    • Project budget
    • Risk register
    • Accepted deliverables

What is the difference between a deliverable and activity?
A deliverable is the result or outcome of series of activities. The activity represents a small portion of the total work package and deliverable.

Why is WBS important?

  1. WBS is a hierarchical representation of the scope of a project; it represents the total scope of work required.
    • A WBS represents the total scope and hence it can act as a checklist for the project.
  2. A Project Manager can easily see the completed work and what is work remains in the project.
    • The deliverable represented by the WBS is easily monitored and tracked.
    • Each successive level of WBS provides a basis for more precise estimation of remaining effort, duration, resources and cost in which to complete the project.
  3. A WBS can serve as a template for future similar projects – specifically for repetitive processes thus making future projects easier and faster to plan.
  4. Activities are easily assigned to team members making accountability easier.

A WBS can reduce project risk.

Remember:

  1. A WBS uses nouns and adjectives to define work.
  2. The key is that we are talking about the nouns, the (mostly) tangible objects created through project work.
  3. Always put deliverables in the first couple of levels
  4. Only move from deliverables to tasks when you’ve pushed down several levels, and have gotten to packages that are reasonably small and estimable.
  5. The tasks to be performed are always in support of a deliverable.