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:
- 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.
- 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.
