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


The package in wheezy backports dates from January 2014



There are many choices for enterprise monitoring, you may already have server level monitoring in place.

Where an individual process requires inspection over time, a simple monitoring script is an option

One of the trade-offs that you must make when monitoring in detail is sample frequency.

Too frequent and you might cause more issues (large logs or other cruft).

Not frequent enough and you might miss the very thing you are trying to observe.

A basic Python script that logs every 2 minutes to sqlite can be found at the link shown next.

On a server with Python 2 available, and equipped with the process id you wish to monitor (from ps output), you might invoke the script as follows:

python ./ 1234

(where 1234 is the process id of you long running process)

The script will run for 3 months or so, and samples at two minute intervals.

Killing the process being monitored will see the monitoring script exit also.