Forecasting: Asking Why and Discovering What's Behind the When (Part III)
Scenarios when forecasting is not the best solution and a description of those alternatives.
Forecasting: Blog Post 3 of 3
Here is blog post number three of John Yorke’s series on forecasting. In part one of John’s analysis, he looked at why forecasting is needed and some of the differences between forecasting and estimating. In part two, John laid out some of the different reasons why forecasting is needed.
In this final blog post, part three, John reviews some alternatives to forecasting.
When does it make sense to forecast?
Listing those questions above it seems like I am suggesting that a request for a forecast is always the wrong question and is never really needed. And it is true that I did struggle to come up with a good example of when it makes sense to do a detailed project level forecast that included dates or any type of scheduling expectations.
It may be necessary for a sales contract, to have a common set of expectations. Although I would very much hope that sales contract for agile projects are for time and materials and are flexible in scope and dates, if not cost too. So for the purposes of setting expectations and in negotiations I can see that there is value in an estimate, although I do still wonder if a detailed forecast adds anything here that a reasonable cost estimate doesn’t cover. If possible I would rather work to an agreed date or an agreed budget than suggest a forecast that may lead to false expectations.
But the reality is that sometimes your customer does want one and won’t tell you why, or doesn’t know why. Some customers (and managers) are willing to accept that a forecast will cost time and money and the more detailed it is the more it costs, and of course being more detailed may not make it any more accurate.
More detailed investigation for your forecasting is likely to build greater confidence but may not be more accurate and you should ask the question “will more detail have a material impact on your decisions?” and if the extra effort wouldn’t affect your decision then it is just waste.
I would caution that if there is no other alternative and a forecast is made, that it is revised regularly and transparently, the sooner the forecast is seen as variable the more useful it is. There is so much assumption tied to a forecast that it becomes a ball and chain if there is not an expectation of it changing and so it must be refreshed regularly to prevent the early assumptions being seen as certainty, or they will lead to disappointment later.
The real value in forecasts is when the forecast is for a short time frame. Over the short term, we can have much more confidence in our forecasts, especially if we have been working on this project for a while and have historic information we can base our forecast on. There are fewer assumptions and less variables.
- Can you forecast which features are likely to be included in the next release?
- If I add a new feature now can you estimate a lead time for this?
- Can you give me an estimate of how much this feature would cost?
By limiting the scope of the forecast to an area where we have more confidence in our expectations, the forecasts become more meaningful; however, there is still a danger they are seen as commitments, although the risk is mitigated by the shorter time frame.
Alternatives to forecasting
Many of the questions above could have been resolved with much less effort than a detailed project level forecast. In most cases we could achieve sufficient accuracy for decision making with a high level estimate. For example, “the product is similar to ‘X,’ therefore I estimate 4-8 months for a small team.” Given that, we could also deliver a rough estimate of 12-18 months for two teams and calculate costs accordingly.
These estimates are certainly broad, but if you have confidence in your teams, believe they will use Agile principles to get value early, and are able to communicate progress and transparency with issues, then I see no issue with broad estimates. It is sufficient to allocate staff and resources, prioritize, schedule and determine Return on Investment decisions.
For the other questions, you may achieve far better answers through the use of product/feature burndown charts, user story mapping, or even simple high level road maps. These tools provide useful information which can be used for managing expectations, identifying dependencies and visualizing the progress of a product. And crucially – they can aid in setting priorities and keeping the progress transparent.