ERP Implementation & Methodology

If projects were completely predictable, there would be no need for risk management . Everything could be planned and executed according to plan. However, we know better. Unexpected things happen, disrupt the original plans and cause time and cost overruns. In IT projects, these overruns are far too common to be ignored.

Project plan. A fancy term we all like to use. But believe it or not, most of us don’t even know what a project plan really is. I don’t know why, how and when it came to be that in IT we started using the term project plan , but whatever the origin, the term we use is somewhat incorrect, and when attached to what we often attach it to, it’s downright wrong.

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.

“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.

Microsoft’s Sure Step team has been pretty busy recently. They have just published the new update to Microsoft Dynamics Sure Step methodology, which includes several important new features and many content updates worth your attention. I’ve just downloaded and installed it and I am impressed with the improvements.

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.

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.

– “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.

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 .

“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 .