projectified

Strategy(ies)-to-Project(s): Representing the Complexities

Clearly a single strategy can be served by many projects and a single project can serve many strategies. The discussions I have had both in the comments of my previous strategy breakdown structure posts and in the emails I have received have brought up some very interesting points. I have gone from liking the idea of linking strategy directly to "elements" within a single project to thinking it was unnecessary and cumbersome and now back to liking the idea again!

I think there could be some really cool outcomes not only for the Organizational Strategy side of the house or the Portfolio Alignment side of house but also for the "PM or team member that just wants to have a better picture of where their hard work fits into the big picture" side of the house as well.

Strategy "Down" to Project Visualization

Linkages from Strategy "Down"

This would provide the organization with a more detailed picture of how strategies are being made to come true via projects and the deliverables of those projects. Linking specific deliverables to the strategy instead of the traditional method of linking whole projects requires a more detailed thought process to be involved. Whole projects would not be just dropped in the "Strategy A" bucket. Instead finite parts of the project would need to be analyzed as to how they support a strategy.

Project "Up" to Strategy

Linkages from the Project "UP"

This way of looking at the relationships offers a different perspective. This diagram would be useful for PMs and team members to more easily visualize how their project and even their particular part of a project supports the overall organizational strategy.

The other thing it would do would be to provide an interesting 'scope check' early in the project. Notice that the deliverables are not only numbered but they are numbered within a set of 4. Where is Deliverable 2? The question would be..."If Deliverable 2 does not directly support a strategy why is it there?" Certainly there are valid answers to this question. This is not to say that just because it does not have a direct strategy link that it should be removed but there is value in the question and value in the process required to adequately answer the question. Answering these kinds of questions and making these kinds of links might force us and managers and planners to think about individual parts of our project in a different way. It might make us examine our scope and our deliverables and the usage of our teams in a different ways. On the 'other side' of this same coin it might make us think about our strategies in different ways as well.

I very much want your thoughts on this. Please email me with your thoughts. I will NEVER share your name or contact info with anyone without first getting your specific approval.No details about your company, your name or your clients will ever be posted here without your specific approval.

Possible problems with the approach that need to be addressed

Nothing is perfect. There are issues with this approach

1. Breaking deliverables up and linking them directly may hide the fact that a project is not generally a disconnected set of unrelated deliverables. Tracking any one deliverable as being 'the' part of the project that supports a given strategy may not be effective in communicating the importance of the other deliverables. It would be important to ensure that this approach (of linking deliverables to strategies) was used with the right caveats and within a context of understanding the importance of the whole.
2. It requires a project organization methodology that contains "deliverables". In my opinion this is the ONLY way to organize a project but there are those that disagree. This approach would only work if your project was organized into chunks that could be linked 'UP'.
3. It implies Big Up Front Planning (maybe). This approach could be seen as being supportive only of "traditional" PM methods, which is to say it could be seen as NOT supporting the more "Agile" methods.
4. Any More? Email me PLEASE. I want to know what is wrong just as much as I want to know what is right! :-)

Tags: strategy breakdown structure, strategy, portfolio management

More on Strategic Breakdown Structures

It has been mentioned by several people that a strict breakdown structure might not be appropriate since any one project might be aligned to several strategic 'statements'. The concept of 'tagging' was brought up as a method that would be better than a strict hierarchical structure. I certainly agree that tagging makes good sense for this reason. But my suggestion of using a breakdown structure is not about making the physical connection easier or more straightforward. I see it as a method of ensuring that the thought process for WHY a project aligns to a specific strategy (or strategies) is rigorous. I also see no reason why even in a hierarchical breakdown structure that a single project could not appear under more than one strategy.

I see the relative scope differentials between a Strategy (necessarily broad and general) and the project (necessarily small and narrow) as making it too easy to drop a project into a strategic bucket without any real thought about how, specifically that project is addressing the needs of the strategy. It generally requires no real thought. They get aligned very quickly and we are off to the next steps in the portfolio management process. I feel that the process of breaking down strategic "statements" into smaller and smaller sub statements and then figuring out which sub statement a project feeds will be a good exercise not only for the alignment process but also for the process of determining strategic statements.

I see the output of the SBS as being more about the analysis and thought process of creating the structure and of the thought process around the alignment of the project to the SBS than about the resulting alignment itself. The resulting alignment has obvious value to Project Portfolio Management but it always has. I'm just asking if it might be more valuable if we were more sure of the process by which we arrived at the alignment. Please email me with your thoughts or comment them below.

Tags: strategy breakdown structure, strategy, project portfolio management

Strategy, Strategic Initiative, Strategic Objective: What is the term?

Though my discussion of the idea of a Strategy Breakdown Structure I have used the term "Strategic Initiatives" to refer to the spelled out list of strategies that an organization has chosen to pursue. It has been pointed out to me that this is not the right term to use. So I am curious about how different organizations deal with the nomenclature of strategy and it's documentation.

In my work I have seen the following:

• Strategic Initiatives
• Strategic Goals
• Strategic Objectives
• (just plain old) Strategies

Any others? Email me

Tags: strategy, strategy breakdown structure

SBS Taxonomy

OK so I will take a first shot at what the levels of the SBS would look like.

Strategic Initiative
        Objective
                Program
                        Project
                                WBS

Just a shot into the thin air. How do you all (all 18 of you LOL) see this working? How would you like to see these levels broken down?

Do you see this kind of expansion of the strategic alignment idea as being useful? Is there value in breaking a strategic initiative down into chunks smaller than the initiative itself but yet still larger than the projects that support that initiative?

Email me with your thoughts.

Tags: project portfolio management, strategy, strategy breakdown structure

Strategy Breakdown Structure?

I was reading Demian's blog over on the ITToolbx family of blogs and he was talking about what he called WBS 2.0 and it's interplay with project portfolio management. It got me thinking last night about how strategy is (should be) connected to a new, broader idea of Work Breakdown Structure. Since the top level of a work breakdown structure (within it's currently held definition) is the project I was thinking about how the broader definition would necessarily change the W in WBS to something else. SBS came to mine initially for Strategy Breakdown Structure. If we start with organizational strategy as the driving force behind the management and alignment of the portfolio of projects then it makes sense that to get a decomposition of all the work that feeds up to those strategic goals that we would start with the strategy and work down.

So we start with the Strategy as "Level 0" in the SBS. What is the next level? Do we jump right to individual projects? Is there one or two intermediate levels between the strategy and the project level? What would those look like? What would we call them?

The more I think about this the more I like it as a way to help organizations do a better job of aligning projects to specific strategic initiatives particularly if there is one or two intermediate levels between the strategy itself and the project. I have found in many cases that the very broad nature of the strategy level being the buckets into which projects are placed that it is overly easy to put a project into a bucket without much analysis of why that project belongs in that bucket. It seems as if the strategy was broken down into smaller parts it would require some more thought about which one of the sub areas of that strategy the project supports.

So help me out with your thoughts on this. Email me at [email protected] with your ideas on this subject. I will compile them and share the findings here.

Technorati Tags: project portfolio management, strategy, strategy breakdown structure