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.
For starters, what is agile? Most of people who don’t know it think of it as some sort of laissez-faire approach to software development: there aren’t fixed requirements up front, so there is no order, there is anarchy.
If you thought about agile in the same way, take a look at Agile Manifesto. It doesn’t sound all that bad, does it?
You can put many of the agile principles to work on the ERP projects by following these simple steps:
- Deploy vanilla ERP first: it satisfies the very first agile principle. I am completely sure many of you don’t agree with me on this one, but this is one of the easiest and sure ways to deliver long-term value. It is almost guaranteed to bring value in many ways. Big customizations aren’t, and they usually don’t (even though the linked research is about SAP, from my experience, when it is about heavy customizations, most of it is true about NAV as well.)
- Deploy gradually: instead of big-banging your project, deliver it function-by-function. Even Sure Step, which is nominally a waterfall methodology, knows of this approach. It can add more value and add it more consistently through the time, than traditional big-bang ERP projects. And this will satisfy the third agile principle.
- Focus on value, and value alone: not all ERP requirements add value, but all of them consume it. Ask a why or two before you customize; you might find out that a standard feature suffices, or that a simpler design will do, or that it is not necessary at all. In any case, whatever doesn’t add value, must go into the scrap bin.
- Stay light with customizations: if you want your solution to sustain and survive any long-term or high-impact change, keep it as close to standard as you can. It doesn’t mean you shouldn’t do customizations at all. It just means you should try to keep them shallow, otherwise you won’t be able to sustain the change when it occurs, and maintaining the solution will cost a fortune.
- Integrate where ERP is not absolutely necessary: you and your customer must understand and define clear boundaries between ERP and everything else. Integrating ERP with external applications might be less costly, and bring more value, than customizing your ERP to the world’s end.
Obviously, most of these don’t have anything to do with a methodology itself, you can do these with Sure Step or without it. Contrary to popular belief (of those who don’t understand agile), agile isn’t about anarchy, or about laissez-faire. It’s a very structured approach which asks for much more discipline than waterfall. With waterfall, you just need to follow the pre-defined steps. With agile, you need to think of each your step before you make it. Agile is to waterfall what lean production is to mass production.
Over this week, I’ll elaborate on all the points above, a topic a day. Please drop by, and share your thoughts. This is most controversial topic that I ever touched, as for many people ERP and agile simply can’t go into the same sentence. Please, feel free to disagree, and do it loud – there is a comments form an inch further below, use it, it’s simple!
Share your thoughts, let’s discuss!