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!
Pingback: Navigate Into Success
For large projects: more than 500 hours, agile implementation is the only way to succeeded.
On most projects, customer do not know the requirement, or don’t know what they want, so by showing them a glimpse of what the final product will look like, (mostly basic tables and forms where they enter/view data), they quickly understand what they do, or don’t want.
Rashed: I’m glad to see that I’m not the only one believing in agile ERP 🙂 However, merely showing the application to the users does not mean you are doing an agile implementation. Key-user training was a part of Analysis phase in first version of Sure Step, now it is part of Design phase (too late for an agile approach, IMHO), but still this is merely installing the vanilla solution for them to play, it doesn’t put the vanilla solution into production. I understand that I might be advocating pure heresy by calling for vanilla NAV implementation (because we advertise it as a highly customizable solution after all), but the closer to standard you go live with, the more chances of success you get. I elaborate on this in my next post, scheduled for tomorrow morning.
Thanks for commenting, Rashed, and nice to see you here again!
I like the idea of implementing a vanilla NAV before gradually implementing extra features in an agile manner. However, from my experience, a number of the modifications are critical for the system to work – we are not talking about user preference things where the users want a simpler way of doing things, but instead things like interfaces which will mean that without the modifications, we need to continue to run the old system in parallel. Maybe we should say that our first round of requirements gathering gives us the Must Have requirements and we implement Vanilla+Must Have features. Then we can gradually introduce value add features. I realise this is an older post but I’ve just come back from my holidays. 😀
@Dave: A lot of customers fear the idea of running the old system in paralle, but intentionally or not, this happens often at least for a little while. If for nothing, then just to make sure everything works okay, or to be able to fall back should something go seriously wrong in the new one. But in any case, what is the strongest reason why the new and the old system shouldn’t run in parallel? It might be the infrastructure costs, if the old and the new softwares don’t use the same infrastructure (old one being on Banyan VINES, the new one being on TCP/IP) – that might be valid. If both systems can run on the same infrastructure, then the issue is just made smaller – if you need to have two servers instead of only one, then do; the costs of having an additional server (plus costs of integration) are often much lower than the costs of risky customization. The strongest reason are probably the licensing costs, for example if after go-live of the new system you don’t want to extend the licenses of the old one for another year because it is too expensive. This is really the strongest reason, because licensing is many times more expensive than a new server. But in general, I believe that there are not too many valid reasons why running both systems in parallel for a little while should be avoided at all costs. Nice to see you back, Dave! I hope you enjoyed the holidays, and I do envy you, a little 😉
Ship Early & Often is definetly the way to go.
Working software over documentations (docs are required only when they really tell the reality)
I’m a certified Scrum Master and I really love the total paradigm shift from the rotten waterfall model that has served us for way too long