Rules of Engagement for a successful business and IT relationship
Rule 1. Build nothing that can be bought.
Rule 2. If you are presented with overwhelming proof that there will be a major competitive advantage to building something in-house that is already available outside, fire the person who brings you the proof.
Rule 3. If you buy something from outside, build around the core functionality things that you can't buy outside - look and feel, interfaces with other systems.
Rule 4. Never, ever, base purchasing decisions solely on the precept that this or that piece of software is so obscure the hackers will leave it alone. If they do, it will likely be obsolete in months. No developer will continue to invest in something that no-one (except you) is interested in. If the hackers don't ignore it, you are back where you started. By all means buy something that in your judgement will be hard to crack.
Rule 5. If you must build it, don't do it in-house. Out-source it. Your staff are on salaries that get paid even if things are delayed and work poorly. They fear only a critical appraisal, and not even that very much. No, out-source it, as you would a construction project. You don't employ bricklayers if you want a new wing for the office. You outsource to a builder.
Building IT is like Building Buildings.
The construction project analogy is valid. Appoint a project manager from the business to lead and take responsibility for the project on a full-time basis. Give the project manager business support as required. No committees except at a project steering level.
Appoint an architect – an external party - to design the system from top to bottom, working closely with the business project manager. The first deliverable is a fully-detailed brief and budget. Appoint a cost-consultant to verify the budget. Then appoint the IT equivalent of a structural engineer – who detail-designs the hardware infrastructure. Then the equivalent of mechanical and electrical engineers to detail-design the data structures and data flows.
Now you go out to tender for the construction, the programming work. This should now be very cheap, as the most expensive elements are the designers whose costs you have already fixed.
The architect, the overall designer, is responsible for coordinating all the other consultants and the programming phase, and will authorise, within budget, progress payments after the cost-consultant has approved the quality of the deliverables.
The business project managers are really responsible for keeping the project from growing and changing – and pressure to do both will come from both the design team and from the business. All should be resisted. If the brief was adequate, change will not be required. If circumstances have changed, and they will if the project is a large one, then change should still be resisted. Better to start a parallel project to deliver the change with its own budget and its own parameters of success or failure.
The key to all this is the active involvement of the business in the project’s management and the almost total absence of IT involvement in decisions involving the scope of the project once the brief and budget have been approved.
It shouldn’t be too hard to get these basic project disciplines right, but, incredibly, a study of IT professionals world-wide has revealed that very few IT projects are delivered on time. The study, conducted by HP and The Economist Intelligence Unit, and reported by the BBC, revealed that in Europe the chances of a project being delivered on time varied widely from country to country. The best, Best, mark you, was Sweden, where 44% of projects were delivered on time. The UK could only manage 11% of projects delivered on time, while Spain and Russia, at opposite ends of the continent delivered only 4% of their projects on time.
The instigators of the study make no bones about it: the responses from the 1,125 IT professionals polled about the effect on careers of late projects show that IT departments are not being held responsible. David Quantrell, VP of HP Software EMEA, was reported as saying “This shows the lack of accountability of IT departments in delivering business results”.
There you have it: for some reason the business wants IT to deliver a “business result”. No-one asks a builder to deliver a business result. The business itself makes sure the builder delivers, because experience shows that unless you sit on top of things you won’t get a business result. Why doesn’t the same experience drive the attitude of business towards IT projects? Because far too few IT projects are run by resources who can be contractually obliged to perform.
The solution is to out-source IT to an external firm that can be held to account.