Those of us who deploy ERP systems for a living know clearly of the disconnect that sometimes occurs between clients who wish for the world but are less anxious to acknowledge the true costs – in time and treasure – of committing to a successful deployment of a new (or upgraded) business management system.
So hearing it from another independent source can serve as a beacon to all of us about the importance of realistic expectations.
One of the books that we consider required reading around our firm (because we implement Microsoft Dynamics NAV software, among several ERP systems) is entitled “Implementing Microsoft Dynamics NAV 2009” by David Roys and Vjekoslav Babic, both expert consultants in NAV.
In their book, the authors touch on the Triangle, a concept we’ve embraced since first learning about it nearly ten years ago. Simply put, the triangle looks like the one at the top of the page. The idea is deceptively simple: Pick Two.
When implementing a system you can control any two sides of the triangle. They give the analogy of building a skyscraper: You can’t build a 100 story skyscraper in three months on a $500,000 budget. If it needs to be built in 3 months, it’s not going to be 100 stories. If it needs to be 100 stories and finished in three months, it will cost a fortune. It’s obvious.
And it should be no less obvious when deploying a business software solution. You can do it fast and cheap, but it definitely will not be done well. You can do it in stages, and have it fulfill the majority of your scope requirements and… well, it doesn’t necessarily have to cost a fortune… but it will be an investment.
As the book’s authors point out:
“Software projects often start with unrealistic expectations. Budgets are OK, as are time constraints. What doesn’t fit this triangle is features. Customers want features. They want many of them. This is called scope creep, and it’s consistently taking projects down.”
The authors’ (and our) answer: a formal methodology for implementation. While it’s true that such a process requires a project manager and some extra paperwork – all of which add overhead to a project’s costs – the truth is that a systematic and disciplined approach to an implementation is the very thing that makes a project predictable and manageable.
As the authors note, “The problem with projects led without a formal methodology is that they only appear cheaper at first, but they rarely finish on time, within budget, and hardly ever deliver against the expectations.”
And that’s a very poor and shortsighted way to lead a project upon which your company’s very mission usually depends. In the end then, these ERP projects are not about technology success, they’re about business success.