Agile has been gaining momentum among software development methodologies for past decade or so. Various researches and surveys consistently show that software developed under an agile approach is generally better than the software developed under waterfall approaches.
At the core of any agile approach is an assumption that whatever the requirements might be at the beginning of a project, they won’t be the same at the end of the project. The longer the project, the more truth there is in this assumption. To mitigate this situation, agile methodologies start with smaller sets of requirements, they start small and deliver functionality incrementally in a series of releases. No single release covers all requirements, but every release delivers more than the previous one.
With ERP implementations, we generally don’t subscribe to this idea. And at that, we might be wrong.
We say that ERP implementations are not software development. It’s true, but it might be irrelevant.
We say that with ERP we don’t start from scratch. We must know all the requirements up front because anything we do impacts tens or hundreds of functions. If we just add things incrementally, we might need a lot of rework. So we need a “big picture” up front, we need to design everything in such a way that this huge ERP structure doesn’t collapse.
But no matter what we do, the requirements will change. ERP implementations take 20 months to complete (on average). Do you think your business is going to be exactly the same in 20 months as it is today? Me neither.
ERP implementations start with a fit/gap analysis which detects the gaps between your requirements, and system standard functionality, and then specify how these gaps will be closed. If the specifications are cast in stone, and if you stick to it, after 20 months you’ll might get a system which is not fit anymore.
Recent Panorama’s survey shows that only one out of five companies have realized more than half of expected benefits of the ERP implementation. More than half companies who have implemented ERP have experienced operational disruptions after go live. This is devastating.
From my experience, this has a lot to do with requirements lifecycle.
On the other hand, Standish group’s research over past fifteen years has shown a steady trend towards more predictable and successful software development projects. In 1994, average software project cost overrun was 180%; in 2004 it was 56%. In 1994, average time overrun was 164%; in 2004 it was 84%. In 1994, only 16% of projects came in time on budget; in 2004 it was 29%. Standish group attributes this improvement largely to increased adoption of agile methodologies. Yes, sure, ERP is not software development. But yet…
Where are we with ERP? Still rowing up the waterfall. With today’s turbulent economy, it’s more like rowing up the Niagara Falls. Today, you can’t tell for sure what you are going to do or need in 2 months, let alone 20. Plus, with liquidity issues everywhere, you must make sure that your investment is sound, and that it delivers the expected return; you can’t gamble with 20% chance of achieving 50% of expected benefits.
Adopting an agile approach in implementing ERP might be a solution. In my next post I am going to share some thoughts and ideas about a possible agile approach with ERP that have been haunting me for a while.