Statistical Forecasting | Monte Carlo Simulation

# Statistical Forecasting

Monte Carlo Simulation## Mathematically predict your project end dates

Stakeholders and project managers seek what might be considered the ‘Holy Grail’ of metrics – the ability to predict a range of project delivery dates. or at least more accurately than any existing methods.

The SenseAdapt approach to mathematically modeling the project and then using Monte Carlo simulation to predict end dates has proven to be more accurate than manual approaches – we have evidence to show this.

## The key elements of the Monte Carlo forecasting approach

Lean Coffee Table helps distributed teams to run effective 'agenda-less' 'Lean Coffee'™ meetings.

Lean Coffee Table helps distributed teams to run effective 'agenda-less' 'Lean Coffee'™ meetings.

## Validate the approach with real project data

The most reassuring aspect of this approach is that we can prove that it is better at forecasting project end-dates than other traditional approaches.

We do this by taking data from a project that has recently finished. It is then possible to run the predictions as if we were still back in April (1), giving a range of likely end dates (2). The model is then run again for June, July etc. each time getting a narrow range of dates. Note that all of the projected dates cover the actual project end date (3).

This is data is from a client of ours and shows quite a common reality. Namely that the scope of projects continues to grow more rapidly than most organisations acknowledge

## But…what is the Potentially Deliverable Scope?

In addition to the question of project end dates, stakeholders often ask a different, but just as important and difficult to answer question…

### “What can we deliver in the next x weeks?”

This too requires an objective mathematically-based approach.

SenseAdapt uses the same Monte Carlo model to show the ‘Potentially Deliverable Scope’ – aka: how far down the backlog can we get in x weeks.

The output shows the Probable and Possible distances down the backlog. It is clear from this that stakeholders should not spend too much time worrying about functionality they will almost certainly get **(1)** or that they will almost certainly NOT get **(2)** – instead everyone should focus on the marginal functionality **(3)**.

Users can move requirements up and down the priority and then re-run the model as often as they want. They will also be able write this new priority back to the tool – either TFS or Jira.