The following advice is based on our experience of delivering successful business and government projects.

(1) A successful project needs:

a) A team that’s fully integrated with business users and stakeholders.
b) A Project Manager who can deliver.
c) A team that understands the technology and business process to be supported.
d) A team that can think ‘outside the box’, while working in harmony.
e) Proper communications – upwards, downwards and sideways.
f) An effective project support office – not one that merely trots out the PRINCE methodology paperwork.
g) A small, independent ‘Red Team’, that is supportive, objective and non-adversarial.
h) A rigorous – and fully documented – engineering approach.
i) A fully representative Test and Reference Rig.

(2) Only 50% of projects succeed. What happens to the other half?

Some corporate assurance mechanisms are so focussed on business and user benefits that they forget what makes it all tick.
You must ask the key questions:

a) Is the system properly specified?
b) Does it meet a clearly expressed business requirement?
c) If it’s using innovative technology, has this been proved to your satisfaction?
d) Is the system properly designed and documented?
e) Have the system and software interfaces been thoroughly examined?
f) The salesman says that the product works ‘out of the box’. No bespoke work needed. Do you believe him?
g) Has the system’s test programme included:

• End-to-end network testing?
• Security testing for patching and system upgrades?

h) Did the system function correctly, after the system security was applied?

Perhaps the business had simply moved on, by the time the project was delivered.

(3) Systems fail because people fail.

Let’s face it: they’re only human.

a) In our experience, nearly 60% of all system failures are caused by People.
b) 30% are caused by Process failures.
c) Only 10% are caused by the Technology itself.
d) Most problems are inbuilt, or self-inflicted.
e) They often originate in the original design or because of shortcuts taken during implementation.

(4) Get the Specification right in the first place.

a) Subsequent add-ons will simply cause problems
b) Instead of trying to impose automation on a manual system, start again from scratch.
c) Beware over-ambition. Don’t be the first to use leading edge technology.

(5) Don’t rush to ‘go live’.

It’s good to meet – or beat – targets. But:

a) Don’t cut corners.
b) And if you’re forced to, make good at the first maintenance upgrade or downtime.

(6) Don’t implement security/system patches/upgrades without testing.

a) Don’t try to save time by updating live systems, without regression testing.

(7) Configuration and Change Management (CCM)

The more complex the system and the more business critical it is, the more important the role of CCM in operational delivery.

a) Too often, CCM is applied ‘post live’ – which is too late.
b) It should be applied from the design process onwards – and particularly during build out, testing and commissioning.
c) It is especially important as the software engineers are doing the final tweaking of the system.
d) Every change needs to be considered, tested, regression tested and signed off with full documentation.

(8) Do your backups work?

Not necessarily, according to one Blue Chip International that does £1m worth of electronic business every day. Their tests showed that:

a) Only 56% of backup tapes could be read back successfully.
b) Of that 56%, only 20% were actually restorable, with usable business data!

(9) Never ignore the basic security measures.

a) Security isn’t just insurance. Properly delivered, it is a business enabler.

To discuss the ways in which we could enhance the Resilience and Security of your organisation,
simply ring +44 (0) 118 976 7544
Meanwhile, have a look at What Went Wrong?