Shot at Visualizing an “SBS”


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

Strategy-Deliverable Alignment
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

Deliverables 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! 🙂
Comments (2)
  1. My goal with this was to have it be a tool to better lay out what i was thinking, even if it meant taking it to an extreme like linking strategy to specific deliverables.

    With regard to your comment about there being something wrong if you CAN do this mapping i would say that this kind of thing might be useful for looking at scope. If you have something in your project that cannot be aligned to how it helps the project fulfill a specific strategy then why are you doing it? That is what Im going for with this whole idea is a better understanding of how projects (and perhaps some sub-project level item like a deliverable or a phase) move toward fulfilling specific strategic goals of the organization.

    So for sure the deliverable level might be too low or maybe it isn’t. Im not 100% sure yet.

    What Im looking for is an examination of if it is possible or even preferable to look deeper than the project level to see how strategy plays out in the organization. My thought is that as more organizations start to do the strategy-project linking and as they get more sophisticated with how they do this we might need to have a more detailed way of looking at this kind of mapping.

  2. Jack Dahlgren says:

    Brian,

    I think you are simplifying the relationship between deliverable and strategy too much.

    The link between a deliverable within a project and a strategy is just too tenuous for this to be workable.

    A company I used to work at had a strategy of reducing risk by pairing less risky designs with new process technnologies and riskier designs with stable process technologies. How does that translate into the deliverables on any of those projects?

    The deliverables are just a part of the project and the project is sometimes more than the sum of the deliverables. Further, there may be strategy elements which can not be modeled in your plan.

    I’d go so far as to say, if you CAN map your strategy completely and exclusively in terms of project deliverables, something is wrong.

    I’d also say that perhaps you need some weighting. Certainly some deliverables are more equal than others or support different strategies at a different rate.

    You also point out the deliverable which doesn’t map to a strategy. I think this would just lead to increasingly elaborate justifications instead of intelligent discussions. It is bad enough when these things happen at a high level (mapping project to strategy) but getting down to the deliverable or task level is really asking for too much extrapolation. Suppose you don’t deliver deliverable A – does your strategy fail? The linkages are just too tenuous to model. Or so I think.

    -Jack

Comments are closed.

Skip to main content