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! :-)
Tags: strategy breakdown structure, strategy, portfolio management
1. Unless I am missing something about the way that IMP\IMS thinks about tasks this may not actually address the issue I was thinking about. I also might not have done a good job of describing my thoughts on this one. My fear for this one is that in lots of planning methodologies any one deliverable in the grand scheme ofa project might not be easily separable from the whole. it might be a specific module of code or even a specific set of features that is the deliverable but unless it is delivered as part ofthe completed whole project then that deliverable does not address the strategy. As much as I like breakdown structures for decomposing larger things into small things I do still tend to focus on the whole system rather than any one specific part.
3. I agree but I highlighted this as an issue mostly to think about how most companies do the linkage process for strategy-project alignment. It is often done once up front. I actually, thinking about it more, see this process as being one that may force the hands of companies that align once and make them go through the alignment exercise more often.
4. I will add this to the now staggering reading list that this little side project has created for me!
Thanks
Posted by: Brian Kennemer | Wednesday, March 29, 2006 at 07:02 PM
Brian,
Good stuff. Here's some approaches to the issues:
1. An Integrated Master Plan / Integrated Master Schedule (IMP/IMS) number can be used to "code" each task and deliverable. By assigning the IMP/IMS number the paln can be "picked up" by a variety of ways (pivot table paradigm).
2. Anyone disagreeing has made it into the "performance based" contracting world. Even the US Government has figured this out. You're absolutley on the right track.
3. Rolling waves avoid the BDUF problem. Keep the rolling waves at some graularity sufficient for the project. We typically run 1 1/2 to 2 waves per year on a multi-year (generational) program.
4. I sent the DoD IMP/IMS prepration and use guide (8/15/05). This is the current thinking on how to do what you are describing in the defense and civil space business.
Posted by: Glen B. Alleman | Wednesday, March 29, 2006 at 06:11 PM