How to define work breakdown structure (WBS) with alternative paths?

Question

I'm a beginner with Project Management, but I am trying to apply my knowledge to one endeavour in my job.

I have a deliverable that can be satisfied by two solutions: one more desirable and one less efficient. However, the choice is out of my control.

I will ask for approval for the more desirable option, but if it is denied I will have to implement the alternative. How do I model this in a WBS?

We use a PM solution developed by a local company (PM3 from Result), that looks like MS Project, but is not exactly the same. So I'm looking for an answer that is not too software dependent.

Answer 1

TL;DR

You currently have an X/Y problem because your work packages have dependencies on a currently-undefined business strategy. This drives your need to develop branches for "alternate paths" in your project plan. If you capture the strategic business goal correctly in the first place, then you won't have to address branching paths in your software or in your project plan.

Make senior management earn their pay by making a strategic decision about which deliverable they actually want. That will simplify your planning immensely, and is really the "correct" way to plan any project: by planning the right plan in the first place.

If you ignore this sage advice, then you still have options. Rather than trying to present multiple plans that represent different chains on the critical path, you should refactor your WBS packages so that you have a single schedule with adjustable scope.

Pick a Business Strategy First

Part of your challenge is that you're not engaging in active communication with the business. A choice between a "better" (however you choose to define that) solution and one that takes longer to build or that will cost more is a strategic decision that belongs to senior management. It's not your job or your responsibility. However, if you communicate effectively and charter the right project, then you won't have to waste time trying to plan for features or milestones that may be completely irrelevant once a business decision has been made.

So, go do that first. Explain the options to the executives, including the potential impacts on schedule, budget, scope, and quality, and then let them pick a strategy. Once they've done that, then you can build the correct project plan to meet the needs of the business.

Decompose WBS Packages per INVEST

Whether or not you've followed the advice to communicate with the business, let's look at what a work breakdown structure really is. Wikipedia defines a WBS as follows:

A work breakdown structure (WBS), in project management and systems engineering, is a deliverable-oriented decomposition of a project into smaller components.

Your problem isn't really how to generate a WBS; your issue is how to create work packages that follow key elements of the INVEST criteria so that executive leadership can choose which packages belong on the critical path.

In other words, if your work packages are decomposed well and are largely self-contained (in order to reduce dependencies between packages), then you can treat the inclusion or exclusion of specific packages as a scope issue.

While few project plans can contain completely idempotent work packages, if your work packages are small enough to be easily estimated and tested, and independent enough to be added or removed from the scope without creating a huge cascade effect on dependent packages, then even a non-agile project can benefit from making scope the adjustable constraint.

A Silly But Useful Example

Let's say that your project is codenamed WonderWidget™. You have several options for building the widget:

1. Hand-craft cogs for the widget in loving detail, starting from expensive bars of the purest unobtainium. This will create a wonderful product, but will require a big budget and a longer schedule.
2. Use mass-produced cogs from the Cogs 'R Us® corporation. Buying in bulk and focusing on assembly will reduce costs and time-to-market, but will also reduce the quality of the finished goods.

We assume a priori that one method has more manual steps and higher labor/material costs while the other method has potential quality issues. Which one is "better" is a business decision, and is largely irrelevant to project planning.

A WonderWidget™ that requires 53 cogs to be assembled probably has exactly the same work packages on either path except for the cog production or purchasing steps. If there are 47 manual steps to hand-craft each cog, contained in 12 tightly-coupled work packages, but only two work packages are involved in ordering cogs from your vendor—well, that's certainly a set of considerations for schedule, budget, or quality. However, from the standpoint of chaining project activities together, the two options are essentially interchangeable because how the cogs are produced may have very little to do with the work packages related to widget assembly.

Even the most complex project plans can benefit from INVEST-driven work packages. Does one strategy require that you embiggen a thingamabob while the other requires you to ensmallen a whatsit? Fine! Swap out the packages, or represent both as an either/or choice.

Evaluate Your Process

A project plan with a modest number of branches, optional packages/milestones, or decision points is perfectly reasonable. However, if you find that your plan is starting to become complex enough to look like a bowl of spaghetti, then you need to stop and revisit your underlying assumptions about what the project is supposed to deliver.

In the example above, whether or not to outsource your cog production is probably a reasonable branching of the project plan. However, deciding whether you're building a Widget of Awesomeness™ or a Widget of Mediocrity™ is something you need to define at the outset of the project, rather than discovering it like an emergent design at some indeterminate point during the project lifecycle.

Whether your process is agile or traditional, you need to build the right thing. If you don't have enough information about what the "right thing" is, go back to the business and ask them.

Answer 2

I do not think this is a difficult problem to solve. The way this is written, I am assuming the decision between alternative A or B is made some time after the project has started, thus the need for two different WBS. Simply create a second control account structure. For example, WBS 1.0 contains the packages that are shared and, I assume, would be underway before the decision is made. WBS 2.0 contains alternative A. WBS 3.0 contains alternative B. Both 2.0 and 3.0 would be planned with appropriate dollar, duration, and time values, both would be baselined, both could be modeled with its own critical path, i.e., show two of them. At the time when the decision is made, execute a change and reduce whichever alternative that was not chosen and remove it from the baseline.

I don't think this has to be any harder than this. A bit more work so make sure you get paid for this.