Hercules Sprint Finish

When you face a Herculean challenge

Eurystheus and Hera dreamt up some tough challenges for Hercules. Challenges where failure was all but a certainty. I mean, taking on a huge and horrible boar, cleaning out the stables of a herd of hundreds of bulls, capturing a double-headed hound from hell; they must have been confident that he would fail. But he didn’t. He was up to the toughest challenges of the ancient world.

Now, what if this happened today? What challenges would they choose? Well, huge and horrible bores and bullshit are still plentiful but multi-headed dogs and some of the other monsters just aren’t around like they used to be. So they’d need a few new challenges. And my candidate for a tough challenge is to deliver an IT programme on schedule after it has missed early milestones.

Come on, even Hercules would be forgiven a moment of doubt on this one. But to be fair, it isn’t outrageously tough: after all, he’s not been asked to realise all the benefits in the original business case as well. (A McKinsey – Oxford University study identified that the average large IT programme realises only 56% of the benefits in the business case).

Its tempting to try and dodge it

So how do you get back on track? Lesser men than Hercules might think the answer lies in changing the track: reset the schedule to finish later. Now we know that Eurystheus and Hera wouldn’t have allowed a cheap stunt like this. So why do you think that the businesses dependent upon the success of the IT programme will? Well, undoubtedly some will. The rate at which large companies vanish is proof of that (For example, 73 companies on the original list in 1984 have gone from the FTSE 100. As W.E. Deming said "It is not necessary to change. Survival is not mandatory"). But let’s assume that this isn’t a programme for that type of company. No, moving the track is not an option.

Or put it off until tomorrow

One popular technique is to concertina down the time for testing activities, particularly those towards the end of the programme. The programme moves back onto schedule. Until, that is, testing takes place and the consequences of that approach surface. Problems are found: they were always there waiting to be found. They require time to fix and retest. And the later they are found the longer they take to fix. But there’s less time available because that’s already been squeezed. What chance the delivery date is hit?

But if you want to take it on, read on

So should we conclude is that you can’t squeeze the time spent testing to get the programme back on track? Actually, no. Now that may sound strange coming from us. After all, Acutest is a specialist testing consultancy and you’d expect us to say you can’t squeeze testing and still deliver. Incidentally, the majority of testers we've interviewed over the years believe you can’t do too much testing. It’s nonsense and a sure fire way to fail the interview. Of course you can test too much and of course lots of programmes do. One of the best ways to speed up delivery is to optimise testing. And, as all good things come in three, our top three tips are:

  1. Focus on what matters
    Risk assess the project to concentrate on those elements with the highest impact of failure and the highest likelihood of failure. This can be used to order the delivery of components and testing, determine the granularity of testing, prioritise remedial work and match the best resources to the most difficult challenges.
  2. Increase productivity
    Take a principle-centred approach to eliminate activities which are not contributing to getting across the finishing line and to initiate actions that increase the speed of delivery. One proven way to speed up delivery is to structure the project requirements so they form a single source that covers the functionality, the software documentation and the test documentation. In this format the tests can be fed directly into an automation framework to produce executable automated tests, saving execution costs and time. Expert users can script and run tests quickly themselves, rather than incur the delays of training up testers to understand the system and its contexts.
  3. Take informed decisions
    Rather than rely on out-of-date data and guesstimates, use the wealth of data generated by testing to provide clear management information. This should be tailored to the needs of the different stakeholders to help them take the all important go-live decisions. And it should cover not only the state of the system development but also accurately describe the programme's progress. Clarity breeds confidence.

There’s a host of other things you can also do to speed up testing. In fact, we have developed a service, Sprint Finish, to help projects get back on track. At its heart are the three points above, combined with elements of the Acutest accelerator designed specifically to speed up delivery. If you’d like to know more about this service we’d be delighted to expand on how we can use it to help you meet your challenging end date.


This blog post is an update of an article I wrote years ago for waterfall projects, which was subsequently published in Project Manager Today. Since then we have evolved our approach to deal with agile projects, as well as the many varieties of wagile out there, through the thousands of projects we have worked on. Yet when I looked back at the original article it was surprisingly close, in principle, to the approach we take today. Plus ça change, plus c'est la même chose

Contact acutest