IT Success and Failure – NMIT Enterprise and Solution Architecture

Why do so many IT projects fail?

After years of working in the Information Technology industry – from development in IT Services, to product development, to Architecture consultancy provided in to an array of industries (Finance (Banking, Pensions, Investments/Asset Management), Public Sector (central and local authority), Utilities, etc. – it appears that despite over four/five decades of the I.T. industry, there is still a lot of failure.

Most will claim that it really has never been one single thing that has dictated the success or failure of a project. For a while, I agreed with this claim, but I believe this offers up a scapegoat to our own inadequacies and anything other than people issues should be relegated from an executive summary.

This question should stimulate lots of thoughts and memories of projects of the past. There’s a plethora of research out there that discusses this in detail from various viewpoints, such as The Standish Group’s CHAOS reports, which offer great insight in to the key elements of success in I.T. projects. Common themes revolve around Executive support, user involvement, skills, experience and emotional maturity and benefits management.

Does success or failure rely upon technology selection? Does it rely upon the processes adopted (the infamous agile vs traditional debate)? While these are factors, they are not the root cause. Prevention is always better than cure. People are ultimately responsible for the definition of the vision, the business case, the selection and implementation of technologies and processes.

Yes, technology choice will inevitably introduce challenges and constraints but this is generally a sliding scale of complexity vs value. Design and development methodologies/processes are not a silver bullet to “success” and some are a better fit than others depending on the “scope” of the project. We cannot critique the process itself in terms of success.

Academic and industry reference material on the Internet is well articulated but what they tend to miss is the ability to bring some of it together in terms of the patterns for their use, the pitfalls, the emotional intelligence needed, etc. .i.e. the material on TOGAF, Scrum, Kanban, Prince, ITIL Service Management, etc. – in no particular order and certainly not exhaustive – are all effectively articulated but their practical application and overlay are entirely reliant on the people involved, and their understanding.

Measuring Failure or Success through outcomes

What is success? There’s a general idea in the industry that project completion to time and budget is how we measure success. However, this is not a relevant measure and leads to an agile antithesis, or results in continuous failure scenarios in traditional SDLC approaches. We have all likely experienced the BUF scope reduction over time to meet pre-conceived milestone dates. It also doesn’t consider the corporate responsibility with regards to staff attrition. The following measures are commonly articulated as measures of IT success:

User satisfaction
Return on Investment (ROI): (Gain from Investment – Cost of Investment) / Cost of Investment
Adoption rate
Customer/Consumer retention
System availability a.k.a. up-time.
Reduction in defects, and/or the scale of technical debt.

It should be noted that an increased ROI may mask its success through PESTLE factors, so other measures have to be taken in to account.

While these need to be backed up with early definition of their metrics aligned with AGOs (See Vision vs Scope) they do not provide introspection of measures associated to the people delivering the software.

Measuring project success

Poor project management: Effective project management involves clear communication, risk management, and stakeholder engagement. It takes a really good PM to understand what architects are telling them and managing that in an effective manner.
Architectural fit: If the Architect(s) do not manage technical complexity properly, it can lead to delays, cost overruns, and quality issues. If they do not manage alignment to clear AGOs – along with the PM and Business Analysts – then
Inadequate resources: Not hitting a critical mass of skilled technical experts will ultimately result in failure of cost and/or quality. There has to be a minimum of 30-40% of the development community who are highly skilled to ensure estimation is not compromised due to acting as crutches and that quality is not compromised for the same reasons.

We don’t feel there is value/validity in discussing changing requirements and scope as this returns us to poor project management in terms of managing expectations. There is also a testability angle to consider to ensure errors are not prevalent, but this ultimately comes down to points 2 and 3 above.