.png?width=200&name=Untitled%20design%20(4).png)
In this blog series, we’ve been exploring three key ideas that allow organisations to make the most of their Enterprise Resource Planning (ERP) transformation: customer-centricity, building from firm foundations, and iterative delivery. In this blog we focus on how all three of these ideas can be put into practice using an agile approach; one that avoids vanity projects, maximises Return on Investment (RoI), and adapts to a world in flux.
Since its genesis in the agile manifesto of 2001, the use of agile development has expanded into many areas of change, including some ERP transformations. However, in this context, its scope is often limited to the downstream activities (e.g. configuration, UAT and release). 50 years after their inception, traditional waterfall techniques still dominate the management of ERP transformations. Waterfall has incrementally improved over those 50 years; but, as an approach, it does not address key delivery risks emerging from an increasingly complex and unpredictable world.
Whether or not an organisation acts on the global stage, it remains subject to global trends which affect both customer and employee behaviour. Exponential rises in new technologies, greater global mobility of people and products, resource scarcity, and shifting global economic power are all accelerating the rate of change of customer desires and behaviours. The future isn’t what it used to be; and that’s never been so true as in the recent past. In the face of this acceleration, waterfall’s rigid approach creates its own key delivery risk. Its stage gates create the potential for change request stagnation which prevents adaptation and the realisation of the investment case.
In contrast, agile applies the same planning rigour as waterfall at a more frequent cadence, so that value is delivered adaptively, earlier and more frequently. An increased cadence creates two sources of value that act as a virtuous cycle. Firstly, benefits are worth more because they are delivered earlier; and secondly those benefits can be validated, so that they form a firm foundation for future delivery (making it easier to deliver value first time thereafter). When combined with customer-centricity, an agile approach also validates benefits to the customer – a key stakeholder whose contribution to the original investment case will be significant.
Finally, broader use of agile in ERP transformations creates opportunities for more granular investment governance. ERP transformations are large, strategic investments that require months, if not years, to deliver. Moreover, they are prone to the inclusion of vanity projects (e.g. due to the perverse incentive for system integrators to generate fees from complexity). Such unjustifiable expenditure is easier to prevent when the ERP is being delivered in an agile way. The end of each agile ‘sprint’ is an opportunity to consider progress against RoI and course-correct as necessary. Additionally, where benefits are validated through primary research (e.g. focus groups), then such course corrections are decided by reliable primary research, not the decibels of whoever is advocating them.
However, an agile approach would be new for many organisations; and such newness creates its own risks. While many agile ways of working can be used for ERP transformation without modification, some are not so readily applied in this new environment. Extra care must be taken to co-ordinate the efforts of multi-disciplinary teams who focus on products, services and functionality with those teams who must deliver nonfunctional requirements (e.g. the data migration team).
Scoping and design activities have heightened importance when compared to common agile use cases. For example, the architectural design requires progressively greater definition of its constituent parts to allow incremental delivery; and, as discussed in the previous blog, an agile approach requires rigour and adequate depth in the discovery phase. Equally, the success of an agile approach depends on the team setup. Those staff who are used to waterfall ways of working will require time and support to learn how to work in multi-disciplinary teams; and the creation of such teams will be difficult if talent is spread out across more traditional, functional silos within the organisation’s structure.
In contrast to waterfall, these key delivery risks are not baked into the approach. They can be mitigated; and they bring with them opportunities whose benefits are disproportionately large – both for this transformation and future improvements to the ERP. So on balance, it’s time for waterfall to collect its gold watch and pen, and gracefully retire after 50 years at work.
Other blogs in this series
Don’t overlook the importance of ERP discovery
How not to overspend and under-deliver your ERP
The value of focussing your ERP transformation on your customers
ERP transformation: it’s all about the customers
This post was originally written by Philip Richardson.
