By Aidan Dunphy, Chief Product Officer, Esuasive
Most of us will be familiar with the situation where, in any business change project, focus shifts from delivering the benefits on which the business case was built to figuring out how to implement the selected software. This is a perilous moment. When emphasis switches from thinking about desired outcomes to the nuts and bolts of managing suppliers, budgets, tasks and timelines, project teams can easily lose sight of what they are trying to achieve, often with disappointing results.
This shift is to some extent an inevitable consequence of the way software solutions are selected, supplier contracts written, and projects delivered. These factors can surreptitiously combine to commit projects to a fixed path, even when it becomes apparent that the original destination will be difficult to reach without applying more resources or committing to higher spend; or perhaps when it becomes clear, in light of changing circumstances, that project objectives should be revised.
The challenge, then, is how to build sufficient flexibility into change programmes, supplier contracts and software delivery to ensure a successful outcome.
Making value the focus
Organisations generally have well-considered long-term plans with good instincts for how they will deliver value to stakeholders over time. In reality, however, strategy is realised though programmes and projects that are constrained by how much money the business is willing to commit, resource availability, competing priorities and risk appetite.
Whilst there are tools available to manage an organisation’s portfolio of business change programmes and software projects, in practice they tend to focus on the management of risk, by building a detailed picture of how solutions will be delivered, when they will be delivered, and who is accountable for delivery. Conversely, the benefits often remain high-level, with insufficient attention paid to understanding exactly how the solution will create the desired outcomes and how success will be measured.
To avoid disappointing results in software projects, it therefore makes good sense to balance the focus given to defining what will be built, when it will be built, how much it will cost and who will build it with equal focus on how the value of desired outcomes will be realised.
The key here is to spend time up front determining how success will be measured in business terms, who will be accountable for realising the benefits, defining appropriate KPIs and targets and understanding the relationship between deliverables and benefits. We consistently see improvements in satisfaction with project outcomes when significant effort goes into removing ambiguity and having clearly defined metrics and responsibilities in these areas.
The problem with software contracts
Software selection often still relies on a procurement process that compares candidate suppliers or solutions against predefined criteria, a process designed to weed out solutions not compliant with specified requirements or to evaluate competence against a set of core capabilities. Understandably, selection is weighted towards suppliers and solutions that perform best in these tests.
Although this is the way software procurement has worked for decades, such contracts subtly, and quite unintentionally, move businesses away from focusing on desirable outcomes and towards managing implementation; from the strategic to the tactical. In this process, desired outcomes tend to take a back seat while the parties focus on agreeing the what, when, who and how much. The primary concern becomes safeguarding commercial positions rather than how the customer’s desired outcomes will be achieved, and benefits realised.
Decoupling outcomes and benefits from delivery almost guarantees future tension between the customer (I thought we would be able to do X) and the supplier (Y is the way the software works). Regrettably, the customer often discovers that the contract described how Y will be delivered, not how capability X will be created.
This conventional approach makes it easy for packaged software suppliers to hide behind the limitations of the software in question. This is mainly down to the fact, prior demonstrations notwithstanding, that the first proper opportunity the customer has to truly understand how the software works is usually at the acceptance testing stage. By then, it is often too late to make changes.
Embracing agility and empowering project stakeholders
The answer lies in engaging with a supplier willing to embrace a more agile approach, to ensure that each project focuses on delivering desired business outcomes rather than just implementing software. This requires a different attitude to contracts on both sides, so that the project team can maintain a strong focus on desired outcomes and delivering anticipated benefits, whilst being flexible on the delivery side, reversing the subtle priority-shift inherent in traditional procurement processes.
A more flexible contract, in combination with agile project delivery methods, puts the customer in the driving seat and ensures they retain the ability to direct the supplier towards delivering benefits rather than just software.
This can be a transformative approach. In our experience, working with customers to understand how success will be measured and where accountability sits in the organisation is a very effective way of empowering and encouraging stakeholders to actively focus on prioritising desired outcomes rather than passively tracking the delivery of predefined (and not always well specified) software functionality.
This outcomes-driven approach centres on putting working software in the hands of the customer early on, typically within days of project initiation. This allows customers to engage with the solution from the outset, so they can gain experience of how the new system works and provide feedback. Provided the solution is built on an open platform, for example the Microsoft Dynamics 365 / Power Apps platform, working through customer feedback to optimise and align system functionality and business processes, data and KPIs, is a simple, quick, low-cost process.
In this scenario, working together to achieve desired outcomes becomes second nature to the project team and a powerful catalyst for successful business transformation.
Conclusion
In the real world, if the forecast says it is going to be fine but you step out into the rain, you go back inside for an umbrella.
In the world of software projects, that behaviour has in the past often been seen as an admission of failure, with the customer’s senior leadership team wanting to know what went wrong and why the plan is not being followed, despite the fact that the plan is obviously flawed.
Today, organisations need to be more flexible. An outcomes-focused engagement model that allows customers to avoid being constrained by contract terms, the limitations of packaged software and a rigid approach to delivery can create the flexibility that enables customer and partner, working together, to focus on accelerating delivery and shortening time to business value.