Why large software projects fail

In this article, we look at the failure of large software projects and outline the main reasons for failure and what we can do to reduce these issues.

Nobody wants to talk about the boring stuff

How many articles, news reports and stories have you read about how a large software project was supposed to cost X and take XX months only to find it needed double the amount of money and double the time to complete? When the project finally was complete the system did not function as expected and created more business issues than it was meant to solve.

There is a burning desire in all of us to implement a shiny new software system and set of user interfaces that look great and make us feel that we are doing a great job. If however you talk to any users of a large complex software system and they will provide you with a list of problems and inefficiencies and statements like “we weren’t involved at the start of this project” or “ I told them at the time that this was not going to work”.

The fact is that there is a lack of enthusiasm about discussing the mundane (but sometimes critical) elements of the business but this is where most large software projects begin to fail or begin to succeed. The time needs to be spent in discussing and mapping the ordinary mundane functions. The best time to do this is at the beginning of a project. A strong business analyst will carry the project team through a series of workshops to extract all these details.

The devil really is on the detail

When a company decides to embark on a large software project this is generally driven out of a strong influence such as digital transformation and or the need to remove paper records from the main business processing functions of a company.

This is more difficult than it sounds. Consider one Standard Operating Procedure (SOP) within an organization. This is used to describe how a section of the business process is performed. The SOP may refer to many paper forms that need to be completed as part of the process. The SOP may also refer to other SOPs – upstream and downstream,

So when we think of a single SOP we have to consider everything the SOP touches within the organization. The full extent of this scope of work can only be defined by detailed business process mapping. This is where every element of the business is mapped by all departments in the business.

The urge to get a solution built can often lead to this exercise being curtailed. The knock-on effects of this decision are often not felt until the solution testing phase. So, the process must be mapped to a granular level of detail, only then can the full extent of the work be understood.

Too much focus on the technical features of a new system can lead to a loss in focus on the function it serves and the reason why it needs to be implemented in the first instance.

Managing user and stakeholder expectations

It is a standing joke that many large software system users won’t know exactly what they need or want until they see it. There is an underlying element of truth in that statement.
The trick is to create a reasonable prototype as soon as you can. If you ask a good project manager and a software developer to define a prototype, you will get two completely different answers.

The software developer will insist on having a full set of server architecture, licenses, databases before they can create a prototype.

A project manager (or business analyst) will choose a quicker route to prototyping, i.e. use a selection of screenshots in a presentation to mimic functional software.

If we pitch one against the other, we are not comparing the same thing so we must ask what we are trying to achieve with the prototype?

– Too much focus on the technical features of a new system can lead to a loss in focus on the function it serves.

Answer to give the user a better idea of what the solution will look like to make it easier for them to visualize the end-product. The project manager’s solution will do the job for a fraction of the cost and time effort. At an appropriate time in the project, full working prototypes will be available but until then it is critical to keep moving and give the user something to make them think.

Is corporate culture causing projects to fail?

In many organizations, these large projects for business transformation are launched with the usual corporate spin and fanfare that one would expect when millions (or dollars or euros) are invested.

“Go live” dates sometimes driven by business goals or legislation are decided upon without understanding this detail. These dates are then set in stone and driven done to the various project managers and project team members from company leadership.
When the project teams dive into the detail and see that the scope of work is just not possible to deliver within the allocated timeframe. The project is then doomed to failure from the beginning and this has quite a negative effect on the individuals involved. The company leadership get frustrated at missing milestones and yet another large software project gets a bad reputation.

This is where the project team need to get organized and present the strategic case to the business leaders as to why the expectations for the project are not realistic.

This is where the project manager can influence the stakeholders and company leadership and save the project.

What can we do about this common scenario?

1. Rather than committing to a date that can’t be achieved, define what exactly can be achieved by that date.
2. Chart a roadmap (based on facts and solid input) on a roadmap to deliver the full original intended scope of work.
3. Keep the “go live” date albeit with limited functionality.
4. Sell the benefits of going live with limited functions as a better opportunity of the organization to transition to the new ways of working and to test the system in the live environment while minimizing the impact to the business (not exposing all business operations to the new system).
5. If the plan is realistic, based on fact, and risk assessed appropriately, it will be difficult for stakeholders to refuse the new approach.

I have yet to see even the most unreasonable autocratic organizations refuse a well thought out plan that is based on good metrics by an experienced team. The client stakeholders may not be entirely happy with the situation, but they cannot argue with the facts.

Start your revised plan off on the road to success
Once you have committed to the re-planned work, you need to deliver on it. It is very important to orchestrate the work so that one significant milestone is met very soon after the plan is launched.

This will serve 2 purposes.

1. Demonstrates to the stakeholders that you can deliver on a plan
2. Give the project team confidence that they can deliver on a plan.

Read more here

Communication

Communication is key when managing a re-planned project. There may be an enhanced level of scrutiny while the project team rescues their reputation. Embrace this as the only way to manage excessive scrutiny is to over-communicate. You will soon be told to reduce the frequency of communication. Ensure that each stakeholder has an update at least on a weekly basis with a more detailed update on a monthly basis.

Read more here.

In summary

1. Resist the urge and the pressure to dive straight into the software/technology fix before the requirements are fully understood.
2. Get smarter about producing prototype functions, you don’t need a full set of server architecture and licences to make a prototype – basic animation will do.
3. People, not jargon nor templates will get the project done – spend time choosing the best people
4. Communicate, communicate, communicate – keep everyone informed of everything as frequently as you can
5. Focus on the benefits of technology, not just technology.

Read more here.