Software development project failures can prove very expensive and operationally detrimental for any organisation, often leaving the finance director at a loss as to why the project has failed to deliver its key business objectives. How often do finance directors invest heavily in a software development project, believing they will have the business solution they need, only to be disappointed with the end result?
You only have to look at how HMRC reached a £71.25million settlement with EDS over problems with tax credit IT systems, to realise the damaging affect of ploughing money into an IT project which fails to deliver the required business value. Of course, most software projects don’t result in expensive lawsuits like this, but many can end up causing huge headaches for both IT managers and finance directors which could be prevented by building a greater level of collaboration, the ability to react to business change, and continual demonstrations of “real” progress, to develop a layer of trust between the IT supplier and the business.
This is most typically achieved by contracting with suppliers in a way that both encourages and supports them to deliver using incremental, iterative and agile software development practices.
Failing to build trust with the IT supplier
Building trust between the business and their supplier is vital for any software development project. FDs aren’t expected to have knowledge, expertise or experience in delivering IT projects, and rely on their IT department to manage the relationship to their IT suppliers. However, more often than not the supplier is forced into a fixed-price contract for a project that promises to deliver everything, if not more than, the business needs.
Suppliers also know they only have one shot at obtaining a contract to deliver, and the IT department typically has one opportunity to secure a budget for a system. This typically results in the IT department defining everything that they think a system might ever need to do, asking the supplier for the fixed-price quotation, resulting in a large budget allocated, a contract being secured with one of the cheapest bidders, to deliver a system at some point in the distant future.
As a simple approach it seems to provide a level of control and financial certainty to the business. Unfortunately it typically results in dissatisfaction for the business, a breakdown of trust with the supplier, and a solution that does not reflect the business’s future needs, or worse still, no solution at all.
So how can this happen? This failure tends to stem from a lack of trust, a flawed governance model, a false measure of progress, and a misunderstanding of risk. It’s fair to say that the IT industry does not have the best reputation for successfully delivering projects, whether success is defined as on-time, within budget, or delivering the business value expected of the system. This poor history has led to much of the distrust that exists today.
So with such a lack of trust the business adopts a governance approach to oversee the project and keep the supplier honest, typically introducing “gateways” that want to see a measure of progress against governance objectives. Whilst sound in principle, these gateways are often misinterpreted and misused by those performing the governance, leading to measures that adversely encourage poor supplier behaviour, such as a focus on endless documentation, as opposed to demonstrating working solutions. This also results in some very poor risk identification and management, from a mistaken belief that the defined governance approach will ensure success.
Whilst a one-shot procurement model can seem like an attractive option for the FD, providing a defined budget request need with no expected increases, the risks that this can bring to successful delivery are extremely high.
Little consideration is made for how the project will manage the inevitable change of business priorities that the organisation will have during the lifetime of the project. Most likely the strategy of a business and its plans will have moved on and changed during this time, making some parts of any project obsolete.
Plus, by using a fixed price, scope and delivery method, it is impossible for an FD to envisage a return on investment before the end of the project. FDs are often led to think that the project is progressing well from measures of effort against plan. This lack of visible real progress would be highlighted very quickly by asking just one important question – what level of business value return on investment would I get on a project if I had to trim the budget and stop it half-way through?
Relieve pressure on cash flow during project lifecycle
FDs can stop this vicious circle of project failure by encouraging a more progressive funding style relationship with their IT suppliers. Before the project is contractually agreed, FDs should expect to see an agreement from suppliers where they plan to demonstrate a return on investment on a regular basis, or at least for certain stages during the project delivery. If a supplier can show the financial controller of the project some tangible benefits throughout the project, layers of trust gradually build between the two parties and the FD’s confidence in the supplier’s ability will grow as the project develops.
This method also puts FDs in control of the project’s budget and relieves the pressure on cash flow as their finance department shouldn’t need to commit to a large investment, before any of the results have been delivered. Even though there are strong signs that we are coming out of recession, FDs need to remain cautious and ensure that they receive a real value on any investment they make. Taking an agile, iterative approach to their software projects will help them maintain control on their budgets and deliver the objectives set out at the start of the project.