I’ve seen a few projects where customers said they didn’t need contingency, because they decided to adjust the budget as changes happen.
How does this sound to you?
To me, this sounds pretty bad, because there is an important distinction between adjusting the budget based on change requests and consuming the contingency reserve.
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. But something came to my mind today, and it’s really an important differentiator of ERP projects from other kinds of projects.
“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. But ignoring their specifics is almost as wrong as saying that software projects are completely different than other projects.
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?
Last week I participated in a discussion about budgets and whether you should ask your potential customers their budget. It made me think: how often do customers reveal their project budgets before the consultants bid?
From my personal experience—not too often. What a waste! Of time, money, and opportunity.
(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.