1. Assemble in the war room: We're going to do brainstorming in the war room; we need a lot of wall space for cards and notes.
2. Begin work at the portfolio level: Get the narrative for each project on a colored card... different color for each project... Project Orange; Project Blue; Project Green, etc. Create a project area in the war room for each project.
3. Work on getting the scope right in the portfolio. Examine redundancy, coherence, and diversification among projects.
-- To reduce single point failures in the portfolio, we looked at ways to put redundancy into each project -- similar but independent capability. We used colored dots on (project) colored cards to indicate where the redundancy came from (example: Project Orange might have an orange card with a blue dot indicating that this was capability redundant with Project Blue but placed redundantly in Project Orange)
-- For coherence we looked at the ways that one project could support another (dependency, but also synergy) such that both together were of greater business value. This may lead to adding some scope to some projects to get the inter-project coherent support
-- To further look at risk, examine the big scope in each project and decide how to divide it up and spread it around so that a common threat does not take down a big chunk of scope. Thus, the big stuff is diversified by dividing it into littler stuff and spreading it around in different projects.
-- And, look at inter-project coupling: the degree to which a problem is blocked from propagating from one project to the other, or the efficiency with which dependencies are conveyed from one to the other
4. Decompose the scope of each project with some task statements, each at the same level of complexity/importance etc, and each colored according to project. Of course, you could do user stories at this point. (Though some might argue for a product decomposition at this point -- and they would not be wrong -- my experience is that in a brainstorm session, people are more creative and attentive to tasks than products: e.g: Create a chart of accounts, rather than 'chart of accounts' (product))
5. Look for dependencies, both intra- and inter-project.
-- Ask people to say what dependencies there are on each major scope statement, either intra- or inter-project.
-- For inter-project dependencies, duplicate the other project's card in the other project's color and put it with the project we were examining. Thus, if the Project Orange project had a dependency with something in Project Green, put a duplicate green card in the orange project area. Thus, a mosaic is formed. The more colorful the project with other color dots and cards, the more complex it is deemed to be.
-- For intra-project use card stacks and card-to-card strings or attachments to show the major dependencies
Then, we put it all in a PDM schedule (aka, MSProject or equivalent) and build the real WBS (matrix of products)
A few observations: The project complexity, as given by the degree of color mix of cards and dots, is a indicator to make some staffing decisions, putting your best managers on the most complex projects.
For more on portfolios, click here
For more on coherence, diversification, coupling, and redundancy, click here.
Check out these books I've written in the library at Square Peg Consulting
