There are many indicators of Project Failure or Crisis.

Some of those are a direct result of lack of control.

A non-exhaustive itemised list is given in the attachment/link below



It is tempting when faced with competing priorities and a hard deadline, to cut corners on process

Below is a list of priorities with a column showing ‘Risk of not doing’


What is not shown is the risk of cutting corners to fit all 13 into a time period that naturally fits 6 to 8 of them!

It sometimes comes as a shock to Project teams, to find that with 8 weeks or 6 weeks till ‘go live’, that there might not be time for all the advanced integrations they wanted.

For well run IT projects, the integration is documented first, and often before the core central system.

Usually the things you are INTEGRATING WITH are well established neighbouring systems or manual processes.

Where you have the implementation being provided by tender, the core implementation is probably the larger part of the project.

Next I will use supermarkets as a way of thinking about the integration planning.

The last 3 months of a large IT implementation are usually mostly devoted to testing, proving, and user acceptance. It is not a great idea to be trying to make changes or other demands on key project staff during that final run-in.

What this means is that there is usually compromise required, because there just isn’t the time to test complex hooks and integration, while also completing the vital run-in activities

Equating project time to supermarket money, I label ‘much project time’ as ‘Waitrose’ and ‘little project time’ as the fictional budget supermarket ‘poondbazaar’

Users who have left integration too late (not documented, late stage variance, etc) will have to accept that they have not the time budget for ‘Waitrose’, and have instead walked themselves into ‘Poondbazaar’

But, but, we cannot have a user experience that is not perfect!

Likelyhood is that without significant spend to boost the project team with folks experienced with driving ahead in very short timescales, then ‘Waitrose’ is going to have to be post implementation and in the first suite of enhancements.

Once the project gets to 6 weeks or 4 weeks to ‘go live’ it is nearly impossible to bring in an additional body and get much more production out of the team+1 setup. It is simply too late.

Plan your integration early in the project life-cycle or be forced into budget shopping (in time terms)


*Disclaimer: This is not an article about Waitrose IT systems, or even the supermarket itself. I neither shop at Waitrose nor work with their IT systems, but choose to use them as an example amongst several supermarkets to describe a project problem


Working with a centrally installed library of Scientific software creates a situation where the user is detached from the install process.

So you might have to press y/n or ‘I accept’ on the users behalf when install Zero Cost software.

But there is a subtlety in there that is caused by small ‘you must’ requests being added to the terms of download

Firstly I understand why people might want to say ‘you must cite my software’.

But it is the word ‘must’ here that creates the problem – it is an implied license term outside the clear definitions of ‘Free and Open Source’ and library of established licenses for FOSS.

A large number of Academics understand what ‘Free and Open Source’ software means and that it goes beyond ‘zero cost’. Unfortunately there are as many who do not understand the distinction.

The solution is training. Do take the time to discuss software licensing and point people to a Wikipedia page

In Enterprise IT the thing you buy probably already has a ‘load profile’ and recommendation regarding concurrency, however the integration and callouts will not get a real test until you put the thing live on site.

For a system that is large, distributed, or highly interactive even small numbers of users should be part of your planned load testing

Perhaps the following abbreviations might save you some typing when planning

3USR – 3 users (real)
3USS – 3 users (simulated)

5USR – 5 users (real)
5USS – 5 users (simulated)

25USR – 25 users (real)
25USS – 25 users (simulated)

…and so on…




This describes the situation where phases are merged or phase change assessments are not completed.

In particular I want to describe what happens if you mix ‘Acceptance’ with ‘Completion’

How can this happen?

  • Delivery pressures
  • Fixed deadlines for a complex solution that are too short

How to spot this?

  • Ad hoc requirements
  • Requirements defined in draft form and not signed off before handing over to the supplier
  • Supplementary documentation with slightly different titles

How to avoid this?

  • Have a phase change assessment, whereby documentation is reviewed and signatures are gathered regarding readiness to proceed to the next phase

Why ‘Snakes and Ladders’?

  • Because you have mixed phases you are actively working on an earlier phase while attempting to get to sign off on a later dependency
  • It is not uncommon to achieve small milestones but to drop back in another area
  • Working in this crossover can be quite disorientating

But Agile is just this surely?

  • Agile does not normally involve a buyer / supplier relationship involving million pound tenders

Escalation is one type of flow.

Sometimes it helps to think about it in people terms starting at the beginning of the story


Next Page »