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


One criticism of Windows was folks being encouraged (by websites) to download custom .exe file to Desktop and double click.

In response to this, a wave a security products and some access control changes, put a stop to that.

Some users missed the convenience.

Could this ever happen on Linux / Unix?


Here is an extract from the install instructions for a Google publicised project:

curl -L | bash

Seems the nix community is in too great a hurry to put convenience before security.

I point out some of the reasons why not in the next section.

Internet pipe to Bash – why not?

To suggest such an install procedure, is to ignore many of the security lessons from the past decade.

Possible risks 1: Fat fingered redirect

By advising the user invoke curl with -L flag, the developer is encouraging users to trust any locally coded redirection.

The reason curl advises of redirection is to allow the end user to verify any redirection themselves rather than trusting what redirection is entered at the remote site.

What would happen if a bogus redirect was inserted by mistake, or by a malicious insider? If it only happened for an hour would the company think it important enough to inform the developer population?

Possible risks 2: Shifting sands

Exactly how do you personally know that the code that was there yesterday is the same code as today?

Does it come in a package with checksums and a well understood inbuilt verification of checksum feature?

Can you manually download a verification checksum from a different mirror server, than the actual code download?

Possible risks 3: Compromised server

Compromised servers are always a risk for any internet hosted software.

Hosting code through acceptance in a distribution like Debian or Red Hat, allows a small company to leverage the infrastructure provided.

It also elevates untrusted software somewhat, due to the integration build process, qa review, and hosting infrastructure which such distributions provide.

Bitbucket, Gitorious, Google code and Github offer some minor improvement from self hosting a project yourself.

Then there is Pypi, CPAN, and other convenience collections, which whilst not offering massive assurance, at least mitigate the next problem described.

Possible risks 4: Dns hijack / redirection

Dns cache poisoning is all too common unfortunately.

Whilst this project is getting some backing from Google, it would be unwise to assume that it (and any mirrors?) employ DNSSEC to mitigate Cache poisoning. If they did employ DNSSEC effectively, would that be on the original http endpoint or the redirected http endpoint?

Commentary and other examples:

In fairness to the developers, there are some additional install notes, and in particular there is some hints for Debian / Ubuntu folks that include this line:

sudo npm install -g yeoman

However, those install instructions also suggest at the start, that you should still do an initial pipe bash, in case you had a previous install present.

Doing that initial pipe bash, then switching to more traditional package management techniques, does not mitigate any of the risks described earlier.

It may be that developers are being encouraged to do this sort of hacky curl stuff by seeing this entry from the npm site:

curl | sh

The observant amongst you will notice that there is no -L flag here, so strike off one of those risks listed earlier.

What comes after the pipe symbol ( | )? Does that make any difference from the other example?

That answer is left as an exercise for the reader.

Further examples (added after article first written):

Next Page »