Blog

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

Managing a project is managing a project. If you are building a skyscraper, constructing a ship, running a presidential campaign, or researching new medication, your project has these three things: budget, timeframe and scope.

Managing a project means primarily managing these three: cost, time and scope. There are other things you are likely managing on your projects: quality, communication, risk, people and procurement. Since all these processes interact, you need to manage their interaction, or integration. According to PMBOK, this is what you do, no less, no more.

This is a bird’s eye view, and in itself it is correct, for software projects equally so as for any other kind of project.

A great book by Fergus O’Connell, How to Run Successful Projects III: The Silver Bullet (3rd Edition) (which should be no news to any software project manager) gives a practical perspective over this, which it calls “The Ten Steps”:

1. Visualize the goal; set your eyes on the prize;
2. Make a list of jobs to be done;
3. There must be one leader;
4. Assign people to jobs;
5. Manage expectations, allow a margin for error, have a fallback position;
6. Use an appropriate leadership style;
7. Know what’s going on;
8. Tell people what’s going on;
9. Repeat Steps 1–8 until step 10; and finally
10. The Prize

And again, this list applies to just about any type of project there is.

It does, because it is generic.

However, something being generic doesn’t mean we should banalize the specifics of a field to which we are applying some general rules. Football, basketball or handball all have very simple principles, after all, they all have to do with teams focused on putting a ball in a target under other teams control. Yet, a successful football or trainer might be a total failure in basketball. Because specifics, not generics, in the end drive success of any activity.

There are many areas where software projects are very specific, and require a lot of appreciation for these specifics, from project management side:

• Scope is alive: managing scope in any kind of projects includes managing change. But managing scope in software projects sometimes comes down to only managing change. Construction can follow an up-front plan and rely on it as much as to be sure that nobody will come and demand three more storeys or ask for the whole building to be five meters wider after the construction has been half done. In software, this is exactly what happens, and it has nothing to do with the quality of project (and scope) planning.
• The stakeholders come in flocks: top management, middle management, key users, end users are a common population. With ERP you have customers and vendors, often the government. Government is easy, as it always wants the same stuff, but all other members of the food chain often seek different things every single time. When building a ship (for example), you don’t interview future passengers about their cabin size and furnishing preferences. In software projects, especially in implementation projects (such as ERP or similar), you discuss the needs and preferences at length sometimes directly with end users.
• The estimates are unreliable: almost always. There is no reliable estimation tool or technique. Whatever you do, developing software or implementing production order management, or financial management, or sales management, your work is almost never the same for two projects. PERT or similar techniques that take optimistic, pessimistic and most likely estimates can give a somewhat reliable but very wide certainty range for any estimation. Probably the best explanation of this phenomenon is Todd Little’s paper Agility, Uncertainty, and Software Project Estimation.
• Inadequate contingency: unreliable estimates require excessive contingency. According to Todd Little’s paper, 90% certainty requires 3 to 4 times greater schedule and budget. Less certainty is often unacceptable to management, yet contingency needed to play it safe is often much more than most customers are ready to set aside. Without enough contingency, cost overrun risk is high, and when it occurs it causes quality and scope tradeoffs which rarely come out well for the customer.
• Time and cost are often unrelated: at basic level ERP implementation cost is a function of schedule and people involved, but funny things happen when you try to crash the schedule. In ERP implementation projects (as with most software development) there are almost no effort driven activities, crashing schedule is also not in linear relationship with costs, and this effect is probably best described in Fred Brooks’ timeless The Mythical Man-Month: Essays on Software Engineering.

These are just a few most important specifics of ERP implementation project management. All of these specifics can be addresses with general rules of project management, such as those explained in PMBOK, as all of these still relate directly to scope, communication, time, cost and risk management. However, two things often happen:

• a project manager inexperienced in software or ERP implementation projects can easily oversee or underestimate the importance of these specifics;
• these specifics, if handled only by generic principles, have heavy impact on time and cost, often unacceptable to management, therefore software and ERP implementation projects often run within unrealistic constraints.

So yes, all projects are the same, but software and ERP implementation (and any other discipline for that matter) impose important constraints that must be taken into account.