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 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


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

Talking yesterday with some folks about cloud computing, I mentioned as an early pioneer.

Formed in 1999, “is best known for its Customer Relationship Management (CRM) products”

Above Quote: Wikipedia (2011)

Phrases like the following, are how I sometimes talk about cloud computing:

Rather than buy software with a large up front cost, install it locally, then go back to the vendor and pay for a new version 18 months later…

What I am doing here is marketing cloud computing on the basis of ‘continuous upgrades’

With that new model comes some caveats and some new thinking.

Funding cloud computing development:

Making up a company name, let us call the vendor “Cloudgang” (No relation to any real company intended)

How will Cloudgang developers be paid?

  1. Software rental (Monthly / Quarterly “Pay as you go”)
  2. One time fee
  3. Advertising sponsored
  4. Other model

(1) Above is easy to explain as there is an analogy in Mobile Phones

(3) Above is easier to explain, now that lots of folks, have experience of the personal (free) editions of GMail and Hotmail

Service level agreements (SLA) and cloud computing:

This is a huge area and I will not cover it in detail, however I cover Google offering briefly.

The SLA for “Google Apps for Business” is here.

Government cloud contracts might well be covered under an enhanced SLA, depending on the contract negotiations involved.

Some Extracts:

  • “99.9% uptime guarantee SLA and 24×7 support”
  • “Phone support for critical issues”

Certification and cloud computing:

This is a huge area and I will not cover it in detail, however recent events have raised an important question.

Traditionally government is used to going through a certification process, buying the software product, end of story.

Cloud computing may require an adaptation of the certification process, that may depend some on, whether the funding model is (1) or (2) above.

Re-certification, and how often that occurs, is going to have to form a part of the contractual negotiations.

Here is what David McClure from US Government (GSA) had to say recently:

FISMA recognize that products evolve and that recertification is part of the process

To provide an example I will use Healthcare (Critical Care) and stretch a standard (CCMDS), to be a certification.

So in this fictional procurement process, CCMDS is a certification process with an external certification body.

Your local hospital signs a 5 year cloud computing contract with Cloudgang for their new Critical Care product ICGang.

Part of that process might require a CCMDS re-certification every 2 years.

Vendor enhancements, continuous development:

As a purchaser of service, you need to consider whether this sort of enhancements model, is one which you favour.

Going back to my fictional Healthcare procurement:

  • If you and 5 other hospitals contract for ICGang, would you want the benefits of enhancements the other 4 hospitals suggest, as they happen?
  • Do you instead wish the product to remain static, and ‘conform to specification’ for the entire contract term?

If you choose the first option benefits of enhancements, then:

  • Would you require an ‘opt out of further changes‘ process?
  • Do you see the system functioning as a sort of ‘optional updates’ setup, where you are prompted for each major ‘enhancement’?
  • Should you avoid a “One time fee” sort of contract, and instead prefer a Monthly / Quarterly payment setup

In the last point in that list, I have returned to the subject of funding.

Developers need paying. Fact.

If you choose the benefits of enhancements option then, that ongoing development work, will need to be funded.

If the contract is a one time fee, then the vendor will have to ‘factor in’ an estimate, of the number of hours of development, to deliver under that benefits of enhancements setup.

An alternative arrangement conforming to specification might seem attractive, however your planning is then really about a series of ‘one time fee’ contract negotiations, accepting that your software is unenhanced for the term of the contract.

Choosing the right sort of arrangement, might well depend on the organisation doing the purchasing, and the business area:

  • Is the organisation dynamic and capable of managing a more interactive relationship with the vendor?
  • Is the business area rapidly developing, and seems a more natural fit with a “benefits of enhancement” style agreement?

Links and further reading: