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?
Another month is over, and in my recently established tradition, I’m taking a look back at the past month to give you an overview of developments around NavigateIntoSuccess.com.
This was both a great month, and a rough month for me. Rough, because I had terrible hosting issues, and great because in spite of that, you visited this blog regularly and engaged in discussions more than ever before. Thanks!
So, let’s take a short overview of what this blog did in February 2009.
Continue reading A look back: February 2009
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
(Three compelling reasons to reshape your business processes, not your software)
Has your computer ever crashed while you were doing something important, causing you to lose all your work? A natural first reaction to this situation is frustration: your work is gone, your effort went in vain, you’ll never do it as well as you did it the first time…
And yet, when initial frustration is gone, and you start doing it over again, from scratch, you are more likely to produce results of higher quality than the first time. Why? The reason for this is simply called—experience.
Continue reading Starting it from scratch – do you dare?
The degree of fit is an important indicator of your project’s alignment with the standard functionality.
After you determine the degree of fit, and understand what it means for the project, do you just passively accept the findings, or do you do something to make them more favorable?
Continue reading The value of Degree of Fit: understanding risks