Tag Archives: Standish Group

Is agile ERP implementation possible?

image Agile has been gaining momentum among software development methodologies for past decade or so. Various researches and surveys consistently show that software developed under an agile approach is generally better than the software developed under waterfall approaches.

At the core of any agile approach is an assumption that whatever the requirements might be at the beginning of a project, they won’t be the same at the end of the project. The longer the project, the more truth there is in this assumption. To mitigate this situation, agile methodologies start with smaller sets of requirements, they start small and deliver functionality incrementally in a series of releases. No single release covers all requirements, but every release delivers more than the previous one.

With ERP implementations, we generally don’t subscribe to this idea. And at that, we might be wrong.

Continue reading Is agile ERP implementation possible?

Panorama’s ERP Report reveals important facts

For a long time, the ruler of project reports was Standish Group’s (in)famous Chaos report, which analyzed IT project success/failure factors. While many of the Chaos report’s findings applied to ERP implementation, the report as a whole was primarily about software development projects. And as we all know, implementing ERP is not the same thing as software development. Hopefully.

Panorama Consulting Group, an independent ERP consulting firm from Denver, Colorado, has conducted a market research in 2008, that explains ERP implementation project success factors and reveals some interesting metrics about real ERP costs, duration and benefits. Finally, we have a decent ERP project report, which reveals some important facts about Microsoft Dynamics.

Continue reading Panorama’s ERP Report reveals important facts

How to prevent failure: project education

According to Standish Group, top causes of failed IT project are these:

  • lack of end-user engagement,
  • unclear specification,
  • changes in scope,
  • lack of management support,
  • lack of planning,
  • unrealistic and unclear goals.

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?

Continue reading How to prevent failure: project education

Business case – do I eat it or?

It’s a well known fact that IT projects fail every so often. Standish Group has been researching the success and failure factors of IT projects for a decade and a half, and they publish their results in their CHAOS report every two years or so. According to their 2006 report, only about 35% of projects can be categorized as successful, while 65% are declared unsuccessful. In this report, word unsuccessful can mean anything from exceeding time and/or budget (46% of projects) or failing altogether (19% of them). With such a huge proportion of projects going astray, maybe there was something wrong with these projects from the very beginning. Were the time and budget unrealistic? Were the project requirements, or even objectives, unrealistic? Maybe. Or maybe not. How can you tell?

Continue reading Business case – do I eat it or?