Adopting an engineering-based approach to IT

David Bicknell

3 months ago 0 Comments

I was recently chatting with a software testing company in the UK all about the challenges involved in delivering IT projects.

We came to the conclusion that establishing and maintaining control of an outsourced project is the single, most important part of IT development; it is imperative for the purchaser to remain in full control at all times, because when that control disappears, often so does the project.

The nature of the procurement process and inevitable time pressures means that the requirements of a new software system aren’t always well-defined at project inception. Typically, specifications are incomplete or ambiguous and put together from a range of disparate sources, with non-existent internal process and control. The “silo” attitude that is often encountered across departmental organisations is usually a key factor. Requirements that are not made clear at the start of the project inevitably lead to confusion, delays, additional cost and even to dispute.

If a contract is awarded on the basis of a flawed specification, the chosen vendor is in a strong position to justify delays and ramp up the costs. When planned schedules are missed and costs spiral out of control, well intended remedial actions can then create new, unforeseen problems, leading to even more rework.

The culture of care and diligence found in many traditional engineering environments is sometimes lacking in the IT industry and engineering discipline is usually the first casualty when pressure is applied. Very quickly, the focus shifts to fire-fighting and a project loses sight of its objectives. It’s like building a bridge – but when halfway across, only fitting every other bolt.

The concept of Agile Development has been round for many years. However, it is still to be seen whether this approach can really work on a large, complex project. A properly managed set of sprints – with precise objectives, proper controls and diligent, independent validation at appropriate times may indeed lead to a more rapid and successful conclusion. However, it should be noted that as development continues, the needs of the business will necessarily change. If controls are not adequately maintained, no process – not even “Agile” ones – can keep up. What is delivered is what the vendor believes is required, rather than what is actually required by the business. And no matter what methodology is used for developing software, at the end of the development cycle it is essential to verify, independently and thoroughly, that the product meets the needs of the business.

Where there is success, there is usually an acknowledgement right from the start that requirements were bound to change and controls must be put in place to manage this. There are efficient, timely tests – not at the project end, but continuous tests, right from project inception. There is an approach that asks:  “What can we do given the available time and budget?”, rather than the popular “one-shot, whistle and bells” approach. And there is pro-active searching for and identifying issues early on – when the supplier is still on site – that means that remedial actions are fixed by the supplier, at no additional cost to the project.

It isn’t rocket science. But for IT projects, the discipline driven by an engineering-based approach is generally more likely to lead to success. That’s why bridges get built – and IT projects often don’t. 

Comments