Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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?
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:
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.
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.
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.
