4

In a software development firm, we often make release plans to fit a particular need: be it a focus on feature development, or carving out a market niche, or just overall quality improvements to stay ahead of the competitors.

When faced with the need to plan a year or more in advance, what sort of techniques can be applied to maximize alignment with the overall strategic goals while still remaining responsive to environment or market changes?

  • are you looking for something like "use the balanced scorecard approach"? It seems the question might be ill-formed(?maybe?) Typically projects are spawned from the strategic goals. The strategic goals contain the info needed to structure/define the project. – Al Biglan May 11 '11 at 5:53
  • @Al Yeah, something like that. The question might definitely be badly written. What I'm trying to get at is whether there are any methods for planning that leave room for change if the strategic goals change or something else happens like a competitor releasing a strong competitive product into the market. Does that help clarify the question? – Adam Lear May 11 '11 at 13:41
2

We have adopted a roadmap approach with a specific 'bandwith' percentage for each type of work. The overal capacity bandwith is known (fixed number of FTE) and is divided into three parts:

  • 60% of available capacity is used for roadmap development: the wishlist of new modules and features, rewrites of older modules, etc. for the coming two years. High-level roadmap-items have a breakdown into work packages, which are estimated (most likely - worst case). So we can calculate more or less what we can accomplish each year with the 60% bandwith.
  • 20% is used for maintenance work, consultant support and technical 3rd line support.
  • The remaining 20% is 'flexible' in the sense that this is used for small enhancements based upon customer requests or responding to market demands.

All development and support is managed with scrum in 2 week sprints. The 'flexible' part is determined during sprint planning by the product manager depending upon the priority of items in this particular backlog. Percentages are monitored each sprint, so if the situation arrises that there was more support or more 'flexible' stuff done, that we can correct this in the next sprint(s), so that we do not loose track of our yearly goals (we got off track a few times in the past when we didn't monitor the 'bandwith' very well). While still being able to respond quickly to customer or market demands.

Naturally, when the situation arises, we can still adapt our roadmap plans to respond to changing market conditions. But we try at least not to change the yearly plan. This gives stability and focus to the dev team and sales teams and allows us to develop against strategic objectives and at the same time the 'flexible' bandwith allows us to service our customers better.

1

Take a look at rolling-wave planning, from both a project perspective and a portfolio perspective.

This post on rolling-wave for development might be helpful.

0

I think the simplest answer to your question is to keep delivery iterations as short as possible and keep as little work as possible "in progress" If you start a 6 week release (six, 1-week iterations) then the chance of a big change derailing the project is smaller than a 6 month release with 4 week iterations. (I'm assuming Agile development based on the RallyOn11 tag...)

Also, you might consider making the risks you are concerned about more visible. I like a 2-D risk chart with Impact and Probability as the axes. Brainstorm a few of the risks in these areas using the format {cause}, {effect}; {impact}. (A customer might release Feature A before Feb, this will cause a re-prioritization of the backlog with the impact that we might sacrifice other features for the release) This won't solve the problem but will help form the thinking and discussion around planning for the events. If a risk scores high enough it might not be wise to accept the risk. In the example, you might want to plan the project as if the competitor were releasing in Feb. Or, maybe other features are sacrificed or "cut down" to help mitigate the risk.

On the other side of your question, maximizing alignment with strategic goals might be achieved by "coding/labeling/coloring" your requirements/User Stories according to a taxonomy (like: Bug fixes, Feature Enhancements, Competitive Response, Strategic Direction) This will help show the balance of your project and help communicate when/how these get delivered (and also show impact if Bug Fixes keep taking a back seat to Strategic Direction).

Your team can also help by restructuring implementation based on the above info. Never underestimate a team of engineers' ability to find a solution to optimize the parameters of the project!

Hope this helps! Feel free to ask follow up questions, I'm still not 100% I answered your question.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.