Project management

A couple of days ago, at a Sure Step 2010 training at Sundsgården, Helsingborg, Sweden, while students were preparing to take the exam, one of the students asks me where she can download Sure Step 2010. I give her the link, but she tells me: “No, that’s Sure Step 2012, I’d like to download 2010” .

Service Providers (or colloquially partners ) often refrain from undertaking organization or process changes during implementation projects of Microsoft Dynamics solutions. And it comes as no surprise: there are many risks related to it, and customizations are taken as a more traditional approach.

It’s official now, and it’s time I announce it here: after two years at Microsoft I’ve decided to take the helm of my career and venture into the realm of independent consulting. Two days into it, and all I can say about it is: what have I been waiting for this long?

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.

Take that project you are currently running, and imagine, just for a second, that it came with only 3% budget overrun. Most of people in software industry would call it wild success. In motion picture industry, however, trampling measly 2% or 3% over initial budget would be considered a failure.

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.

Prescriptive methodologies, such as Sure Step, are double-edged swords. They are aimed at increasing repeatability, consistency, traceability, manageability and more of your projects, yet they seemingly increase overhead and contribute to an inflated project price tag.

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.