Many project management authorities assert that from project management stance all projects are equal. I dare saying that some projects are more equal than others.
In my last post, I argued why I believe software (and ERP) projects are different. But something came to my mind today, and it’s really an important differentiator of ERP projects from other kinds of projects.
“Software projects are no different from other projects”.
This statement is being repeated over and over at project management courses and seminars, even endorsed in books.
It’s true that software (and ERP implementation, as a subset of software) projects have many traits in common with projects in other disciplines. But ignoring their specifics is almost as wrong as saying that software projects are completely different than other projects.
It’s hardly any news for the lucky 21 countries which have had them by default for about two years, but for other 18 which haven’t, there is an alarmingly low awareness about three interesting NAV functionalities: Liquidity, Cost Accounting and Kitting.
These three have been named Local Functionality, which means they are a part of a localized version in some of the countries. For other countries, this functionality is not available by default, but it doesn’t mean it can’t be licensed or implemented for customers in other countries as well.
One of the biggest absurdities about ERP systems springs from the very word we use so often when describing ERP: integrated.
ERP is an integrated system: it integrates all data and processes into a single application. Different modules look over different aspects of data and processes, but a change in one module automatically reflects in all others.
A fantastic concept. When it was invented, it streamlined processes, boosted productivity and eliminated overhead and error.
So, whenever a new functionality is needed by a company, it should be integrated into the ERP, to benefit from the integrated system. Right?
Wrong.
You can’t avoid customizations. Vanilla ERP is a great first step, and a valuable tool for establishing common language between the customer and the consultant. But in the long run? Probably not. Pristine uncustomized ERP won’t be sufficient, because of the gaps between your way and ERP’s way. Sooner or later, gaps will have to go.
Two most common ways of closing functionality gaps are customizing the software, and changing the processes. You can almost always touch general processes, optimize them, twist them, bend them, make them more efficient or even eliminate them. But when it is about industry specifics that add true value or contribute to company’s competitive edge, customization is the answer.
– “We need a report which groups our sales by product components.”
– “And we need it broken down by cost centers.”
– “And it must show comparison with last month, quarter and year, and with budget and forecast, with indexes and trends. In linear regression.”
– “And it must let you choose if it is by posting date or by document date. Or by shipment date. Maybe some other date as well.”
– “And it must exclude returns, and include only those re-shipments that were linked to original returns in the shown period.”
And it must be a disaster if you agree to half of these.
How do you eat an elephant? One bite at a time. Swallowing it all at once might be tempting as it has all the potential you need to get into the next edition of Guinness World Records. Likewise, trying it with an ERP implementation has all the potential you need to get into to the next edition of Chaos Report. One way or the other.
ERP software is huge. It contains thousands of features potentially touching every single tiniest aspect of your business. Implementing ERP is about introducing change into your company, and change can be evolutionary, or revolutionary. Your pick.
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” That’s the very first principle of the Agile Manifesto.
The problem with ERP is that the first deliveries are all but early: they typically occur only after about twenty months.
Twenty months is a heck of a long time. And value achieved after a twenty-month implementation is often far below expectations.
In my previous post I’ve (what, again?) shared some statistics about success and failure rates of software projects in general and ERP projects specifically. It seems that ERP projects fare somewhat worse than generic software projects, which I stated might have a lot to do with how requirements are handled.
Agile is an unpopular word in ERP world. We, the ERP people, love the glory and the thunder of The Waterfall. It has worked for us since forever, after all. Yes, we’ve all seen it fail every so often, but we’ve learned to learn from failure, and we know there is no better approach. Don’t we?
Frankly, I am not completely sure we do.
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.