On Being Engineers

November 10th, 2014ClearPath


The many and various IT systems which we encounter every day in our work and elsewhere allow us to do things we could not do even a few years ago. Although in many cases the systems work well, rather too often they don’t. We come up against inadequate performance, unreliability and lack of security. But because we are pressured into using IT systems for many services, we don’t have a lot of choice.

In some cases, system failure doesn’t really matter. It’s of no real consequence if we can’t post something on a social media site, for instance. In other cases it really does matter. The consequences may be serious if a bank standing order cannot be processed. In emergency services for instance, life may be at risk. And security breaches really matter a lot; they are high on the list of management concerns.

The production of software systems is frequently described as a branch of engineering. To raise standards, engineering discipline is required not just in application and other software development, but also in commissioning IT systems, including procurement, and their subsequent deployment. I’d like to look at commissioning and procurement in a bit more detail. I’ll save deployment for another time.

IT systems in both public and private sectors may be commissioned explicitly as IT projects. However, IT is now so pervasive that almost any major business or government policy initiative has a significant IT component. It will not work unless the IT works. It is therefore essential that those launching an initiative either understand the IT involved or have advisors who do.

However, it is not just enough to have competent advisors; you have to listen to them. Launching new initiatives sometimes appears to be a matter of political vanity, with or without a capital P, with a liberal sprinkling of unjustified optimism. Often, the requirements are unclear and consequently no realistic cost/benefit analysis is possible. The public sector, at least in the UK, seems particularly prone to these problems. The private sector is not guilt free but may be better at hiding problems.

Lack of clarity about what you are trying to achieve of course makes procurement – selecting products and services and letting contracts – very difficult. Even where every effort has been made to be as clear as possible, some projects inevitably have a degree of uncertainty, especially if new technologies are involved. It is therefore important to have a lot of discussion at the start with all of the parties involved, including the potential users. Proof-of-concept projects may be necessary to find out what can be done. Such discussions are very difficult or even impossible in many procurement régimes, where communication is restricted to vendor conferences and sealed bids.

Other branches of engineering have faced similar problems; we can learn from them. Civil engineering is an interesting example in its response. It has faced problems with project delays and budget overruns. A response in the UK was to look at procurement contracts. The result was NEC: a family of contracts which facilitates the implementation of sound project management principles and practices as well as defining legal relationships. The major features of NEC are outlined below; see the NEC Contract web site for more information.

Those creating NEC understood that adversarial relationships are counter-productive; the best results come from partnership. They also realised that pre-contract activity – defining requirements – is critical and should be done as far as possible before contracts are signed. The design of NEC aims to incentivise the participants to focus on this early activity and minimise the number of changes after contracts are signed.

There is also a strong emphasis on clarity and simplicity. The contracts are worded as clearly as possible, avoiding jargon and using plain language. An additional benefit is to make life easier for participants who do not have English as a first language. I’ve discussed this subject before in a post I wrote in January, “Say It Clearly!“.

IT projects are not the same as civil engineering, but emphasising collaborative rather than adversarial relationships, upfront requirements definition and clarity of intent are the key to success in any complex project implementation. Structures analogous to NEC could be built for IT.


Tags-   ClearPath Engineering