BIOS: Technology Means Business

Like many people, I am a prolific reader of the newspapers and keep up with news and current affairs by reading at least one a day.

Yet, for a while now, and I must say with growing frustration, I’ve noticed an increase in stories about IT project failure - especially in the public sector.

Almost every day there seems to be a new report of a collapsing technology project. For example, recently we heard that the overall cost of the Metronet-led refurbishment of London Underground is significantly behind schedule and over budget by an estimated £750m.

IT failings, including poor IT integration, lack of supply chain software and rising IT costs are reportedly to blame for this. And this is not Metronet’s only technology failure: The uploading of new software in late November caused a total breakdown of the Central line - one of the busiest - in the Monday morning rush hour. Such failings are unacceptable and have a lot to do with the way the projects have been handled.

There is a general climate of failure in public - and private - sector IT projects. This means that there is a worrying and real danger that we have become so accustomed to such reports that we have at the same time become indifferent to them, essentially regarding such projects as ‘Just another government IT project failure’ - which is of course unacceptable. We need to wake up to the fact that IT disasters are preventable and not a ‘necessary evil’ we have to put up with.

Public and private sector organisations now need to move away from the idea that software development is an ‘art form’ and start recognising it as a managed business process which can and must be successfully regulated and managed like any other project within a business. One approach which can help with this is Application Lifecycle Management (ALM). ALM - which connects the various phases, activities and assets involved in delivering software - attempts to turn today’s chaotic software delivery process into a more controlled and predictable procedure. An important aspect of ALM is the ability to manage software quality throughout the entire lifecycle - whether it’s validating whether the requirements are accurately defined, to whether the application has been tested properly. Ironically, quality is the linchpin of the software delivery process, but it is one which is often overlooked.

Quality within software delivery is frequently an afterthought, meaning that quality testing begins late, so that problems are difficult and expensive to fix; and often it is done manually and only by one organisation involved. Some companies put quality consciously to the bottom of the list when making the trade-off of delivering something on time or on budget - a route which can only lead to software disaster, while many software delivery teams merely react to defects and requirements. A more mature approach is clearly needed in order to deliver higher software quality while, at the same time, lowering development costs and improving time-to-market. With this in mind, quality simply should become part of every stage in the lifecycle of a project. Of course, any concept of ‘quality’ can be subjective but in IT development it definitely needs to be measurable in terms of the union of requirements, correct code and minimised defects that align to meet business goals.

Software delivery should take a proactive, preventative approach rather than the reactive, waterfall approach that many in the industry are still in favour of, even today. Prevention is better than cure - anyone can relate to that. Companies need to focus on improving their ability to confidently and consistently deliver higher quality software which in turn will prevent the IT waste from project failures we’re so often seeing such as the London Underground project in the UK and others across the globe including Toyota, Trend Micro and QuadraMed to name but a few. Defects caused by insufficient quality testing may have several reasons, e.g. licensing violations, poor design, code readability, ambiguous requirements or security vulnerabilities - and yet all these can and should be prevented, simply by ensuring quality is a priority throughout the whole development process.

All too often, quality checks don’t begin until the testing phase, at which point much time and many lines of code have passed. However, a preventative approach to quality starts much earlier, even before code has been written. Quality checks should be added at the point of project definition, tested earlier and more often, and traced throughout every phase of the software delivery lifecycle. In short, we need to bring quality control to software development from inception, rather than waiting until it is already in the testing stages. This ‘Test before you Leap’ approach guards against the root cause of many IT project failures today.

Companies involved in software projects can take two steps to ensure a more mature approach to quality. Step one is to focus on pre-deployment and preventing issues early in the lifecycle, not finding and fixing them later on. Testing early, consistently and often is imperative. That way, defects can be isolated before they impact other parts of the projects and the system - or even lead to the complete collapse of it. Step two is to ensure that quality is no longer an addendum in the software delivery process. Rather, it needs to be captured in project definition and be one of the main priorities, from the very beginning of the project. It should encompass complete requirements, correct code, and minimised defects, and be aligned to the overall business needs of the organisation.

The woeful record of IT projects in the public sector is a case in point that poor software quality can lead to enormous consequences - yet quality is still not taken as seriously as it should be. Although it was always clear that the London Underground project was going to be complex and difficult worldwide, quality assurance and proper testing were seemingly not on the agenda. Now more than ever, it’s time to break down the barriers between business development and quality assessment need and solve quality issues earlier in the lifecycle of the project. If we ‘test before we leap’, we are likely to read fewer articles about IT project failures in the newspapers.