Continuity 1

“Failure is the opportunity to begin again more intelligently.” Henry Ford

We take great inspiration from this statement by the Auto and Manufacturing visionary. So much so that we have made this the central tenet of one of the pillars of our software development practice – Project Rescue. First the facts.

Less than 1 in 3 software technology projects over the last 12 months were completed on time and within budget according to research by the Standish Group.

Geneca reported that 75% of all business and IT executives believed their software projects would fail, even before these projects got off the ground.

HBR reported that 16% of projects overshot their budgets by 200% and their schedule by 70%

Failed projects cost money – Gallup reported that the US economy lost between $ 50 and $ 150 Billion annually due to It projects that failed

Presumably, there is no room for argument that technology projects within enterprises are falling short of expectations in large numbers. The definitions of just what constitutes failure are many but essentially this could either mean that the effort cost significantly more than was initially planned, or that it took much longer than anticipated to reach completion or, in many ways the most damaging, the entire initiative failed to deliver the expected business value. In the third scenario, the problem is compounded since money is lost, the opportunity may have moved on with time and essentially the entire effort is wasted. What does this mean for the enterprise facing this failure, though? Well, our contention is that there is still hope and even seemingly lost causes can be salvaged. We believe that almost all IT projects can be saved and revived to fulfill the need they were visualized to serve. That being said, we should also make the point that rescuing a project goes beyond mere survival. The rescue of the project is complete only when it does achieve the business value it was designed for.

Many causes have been put forward to explain why projects fail. These include reasons like undisciplined project management practices, poor governance, inadequate support, insufficient technical experience, functional issues or even a lack of focus on quality assurance. While these are all valid reasons, more often than not, in our experience most projects fail simply because very few people have seen a project done right. The good news is, we believe that, in most cases, rescuing a project is not like recovering from a nuclear holocaust where nothing can be salvaged. Instead, we believe, it’s a series of few steps done right.

Understanding the technology part of this equation is, no doubt, important. We believe though this is virtually a hygiene factor in that most technologies platforms, tools, and approaches are great in their own way and, when put to the task, have the ability to deliver to spec. Putting that differently – it is rare for the project to run aground solely because of the technology choice. That being the case our focus in Mission Project Rescue is usually elsewhere.

John Johnson said, “First, solve the problem. Then, write the code.” The first thing we look to do is reinforcing the integration of the business requirements into the architecture and the design. In the end, the project has to deliver business value and the process of ensuring that starts right from gathering the requirements and building these centrally into the vision of the software. A significant challenge we seek to address here is simplifying the business process and how it maps to the software. A Gartner study in 2015 of 50 large projects that were publically accepted as being “complete failures” cited an inability “to address complexity in the business process” as the most important reason for their failure.

Bjarne Stroustrup said, “The most important single aspect of software development is to be clear about what you are trying to build.” Once the business requirements have found appropriate representation in the architecture we look to bring strong software development practices to bear on the conversion of those specs into code. It is not always about which is the latest technology fad or software development approach dominating the blogosphere – our approach is to stay tuned to the technology world at all times but to choose conservatively and execute rigorously to revive the project.

A quote we saw somewhere went something like “Quality control is implemented to detect and correct problems when they occur, quality assurance is implemented to prevent problems from occurring.” That describes very well one of the key pillars of Mission Project Rescue. We seek to use stringent quality assurance processes across the entire development lifecycle to ensure that the code that we turn out not only meets the specs we worked to but also the eventual expectations of the internal and external customers of the enterprise when they get to touch and feel what has been created.

No one is making the claim that saving an IT project that is spiraling out of control is easy. That being said, though, we specialize in coming to the rescue when projects are in jeopardy and in them bringing them back to life. From that viewpoint, some of the insights we have gained may not play to traditional wisdom, but take it from us, they do work!