Our experience within IT projects and particularly within ITSM projects revolves around the time critical nature of projects and the need to have everything immediately (whether this is true or not is up for discussion).

The rush to jump through process gates can lead to different behaviours, both circular in nature. ‘The Business’ believes that project workstreams overestimate and those within projects almost invariably believe that whether a realistic estimation is provided or a pessimistic one, the estimated time will be cut.

The circular nature of this particular issues hits those of us in testing two-fold. Firstly, with testing seen almost as a ‘nice to have’ or a bureaucratic exercise, insufficient time and resources are planned and budgeted for, whatever the approach taken.

Secondly, as testing is often solely towards the end of a project, already sparse timelines are further truncated and as we all know, on the project pyramid, something must give – namely cost or quality.

Perhaps we should start working differently. You’ll find other blog posts written by us about the ideal point to engage testing (hint:at the beginning not the end). But what if we started to change the way projects and workstreams approach estimation. If we were a bit more realistic about estimation and applied both experience and a little mathematics could that help? I think so.

One of the things I took from my PMP training that has stuck with me (and that was now some years ago) was the following formula


x is the best case scenario a task can/has taken
y is the typical time a task takes or has taken
z is the worst case a task has taken

this allows us to account for both optimism bias, pessimism bias and normal operation. It should give us a reasonable estimation rather than the scenarios above. Obviously, it is not perfect, but if we could use this approach might it give us a better shot at estimating? We think so.

Related Posts


Is ITSM really ready ‘Out of the Box’?

As ITSM has evolved in recent years, there has been an appetite and ability to move towards ‘Out of the Box’ implementations where not a stitch of code is changed in the ITSM solution during Read more…


Preparation is key

So, you’ve identified the need for a new ITSM system.  You might be starting from scratch (although that’s never really the case).  You might be upgrading between versions or procuring a system from a new Read more…


Don’t Disrespect the Data

There are many moving parts that ITSM Implementation teams need to consider in the scope of a project. Commonly the main focus is on code and configuration and second to this is data. This is Read more…