“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.
Last week I delivered the C/SIDE Development course for partner community in Zagreb. As always, questions abound afterwards. Today, I’ve got a question from an attendee: “What’s the best way to print a report in multiple languages?”.
Up front: this is NOT a technical post. It IS about technical solution, but it is primarily about design, usability, standards and best practices. I’ll plain ignore the fact that it does use a few C/SIDE or C/AL references, so please, do likewise 😉
(I said this because I kind of swore not to C/AL around this blog anymore, but again – sometimes I just have to do it.)
According to Standish Group, top causes of failed IT project are these:
I haven’t seen too many failed Microsoft Dynamics NAV implementation projects, but those that I did see fail, have failed precisely for a selection of these reasons.
Take a closer look at the list above. Doesn’t it seem that the blame lays mostly on the customer? But is it really customer’s fault?
Implementing a new Microsoft Dynamics solution doesn’t merely introduce a new piece of software into your environment. Yes, the software is an important part, you need to deploy it successfully, configure it as necessary, probably even customize it and change the business logic under the hood.
One component, however, is easily overlooked, and you wouldn’t believe how often it’s not addressed until late. Or too late. It’s the infrastructure.
Infrastructure is tough. It’s not just servers and desktops with some wires, switches and access points in between. Its a lot more. What kind of hardware do you need for your servers or desktops? What kind of performance do you really need? What kind of network layout is optimal for your transaction volume? Should you run the client on desktop machines, or would a remote desktop access be a preferred method? Do you virtualize your servers? What kind of failover capacities do you need? Can you retain any of your old hardware? How many users will use the system? Tomorrow? In five years? What about interfaces and integration to other systems or applications?
A couple of wrong answers, and down you go.
(A short rant about eye-contact-based specifications.)
In short, there is no such things as an eye-contact-based specification. And for a reason.
While kicking-off of a project, we had a discussion with the customer about the change management approach, and specification detail.
Last Friday, while enjoying a not-at-all healthy Salisbury steak with cheese, I had an interesting discussion with a partner: should NAV consultancies create default databases?
A default database (in this context) is a packaged solution built upon standard Microsoft Dynamics NAV, where a consultancy has introduced a number of features that they sell to all their customers as the standard solution, instead of standard NAV. The modifications to standard NAV can range from simple report adornments to minor feature improvements to full-scale horizontal or vertical functionalities.
Some time back, as I was riding a taxi from Prague airport to Holiday Inn hotel, I wondered about the fixed price I was about to pay for the ride.
– “Airport to city is 700 flat.” – said the driver when I asked how much approximately will it cost.
Common wisdom goes that flat rates mean you get it worse than if it wasn’t flat. Indeed, if it was on meter, and if the driver took the shortest route (I had a GPS device on me, I could’ve easily checked it!), the fare would’ve been lower. And yet, I decided I loved the flat rate.
Each phase of Microsoft Dynamics Sure Step methodology is equally important in an implementation project. You could argue that analysis is the most important, or that design is the most important, or that operation is less important. I’ll paraphrase Scott Adams here and ask: how one phase can be more important if each of them is completely necessary? Well, except for Diagnostic phase.
Hint: this is a post for developers, and mostly junior developers, those who are still learning how to code properly. I know, I promised not to blog about stuff like this, but I simply couldn’t help this time.
A friend of mine has asked me for help.
“There is this C/AL function I had to rewrite, now I end up with 106 BEGINs, and only 105 ENDs. Do you have any idea how to find where this missing END belongs?”