projectified : Strategy

Shot at Visualizing an “SBS”

brianken — Tue, 15 Jul 2008 06:14:38 GMT

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

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.
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'.
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.
Any More? Email me PLEASE. I want to know what is wrong just as much as I want to know what is right! :-)

SBS Taxonomy

brianken — Tue, 15 Jul 2008 06:13:17 GMT

2nd old Strategy Breakdown Structure post…

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?

Reposting: Strategy Breakdown Structure

brianken — Tue, 15 Jul 2008 06:12:11 GMT

This is a repost of an old post from the original Projectified site. Hoping it can bring about some new discussion

Strategy Breakdown Structure?

I was reading Demian's blog over on the ITToolbox 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 brianken@microsoft.com with your ideas on this subject. I will compile them and share the findings here.