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
Right. Of course it is clear and and singular entity but it is not an entity that cannot be broken down further into smaller parts. It takes whole projects to make it come true so by definition it can be broken down.
concerning frameworks Im using the basic concepts of connecting projects to strategy(ies). Im not sure that it needs to be any more complex than that. I dont think that for what Im talking about we need to break into the nature of BSC or any other framework. Im talking about the connection between a strategy and a project and how that connection is made. I dont think it matters which method or framework you are using.
Posted by: Brian Kennemer | Sunday, March 26, 2006 at 08:30 PM
Brian,
I now see how I have trouble here. It's difficult for me to think about strategy in a generic way without some frame of reference as a practice.
Posted by: Glen B. Alleman | Sunday, March 26, 2006 at 06:39 PM
Brian,
Re: Strategies Broken Down - I'm suggesting a Stratgey is a singular entity, with a clear and concise statement. For example
"Reduce non-closure application foot print in ERP to reduce funding burden during closeout" An actual BSC stratgey for Rocky Flats.
With single stratgey (and we had around 14 strategies) a portfolio of projects with their initiatives could be connected to the strategy. This One-to-Many relationship made traceability simple and precise.
Regarding BSC - what strategy framework are you using? Thinking about stratgey - from my experience - is a sporty business in the absence of some type of framework.
Posted by: Glen B. Alleman | Sunday, March 26, 2006 at 05:21 PM
For sure they do not have to be big. Im just saying that the ones I have seen tend to be big in comparision to the projects that support them. The strategies I have seen tend to require more than 1 project to make them happen and generally more than 10 or 15.
You say strategies should not be able to be broken down but then you say that 'under' a stgrategy there are things such as initiatives, portfolios and projects. If they cannot be broken down then there should be NOTHING 'under' them, right?
As far as your comments about tracing projects to strategy: that is they whole point of this discussion. I take it as a given that projects need to align to strategies. Im discussing the idea of a 'SBS' as a means to that end.
Im slso not trying to put this in the context of balanced scorecard. Im no expert in it to say the least. Im trying to discuss how something like an "SBS" might be useful for aligning projects to strategy. Im hoping to leave out references to any specific methodologies until we get a little more meat on the bone of the SBS idea.
Posted by: Brian Kennemer | Sunday, March 26, 2006 at 02:54 PM
Brian,
The one primary learning I've taken away from 5 years or so of Balanced Scorecard stratgey is not to speculate too much about how things work, what they shoudl be called before having tested the ideas in practice.
1. Strategies do not have to be BIG, they can be small ass well. Projects can be big in support of a small strategy. Size doesn't matter in this case.
2. Stratgeies themselves shoudl be self contained and not subject to being "broken down." By this I mean the Strategy itself. The elements "below" the stratgey codl be - as you suggest - initiatives, portoflios, projects, etc...
3. In the end if the project is not directly traceable to an stratgey then it has a problem or the strategy has a problem. Either way there needs to be a fix. The process is easy alignment turns out to be very diffcult in practice.
This has been my experince - through the training of BSCol and two Scorecard process in two different IT organizations, as well as coaching and mentoring from two other CIO's. It's a narrow set of experiences, biased by Gold and Duran.
Posted by: Glen B. Alleman | Sunday, March 26, 2006 at 01:16 PM