The Four Most Common Software Project Mistakes

The four most significant mistakes that get in the way of good software project management and what to do about them.

A clearer identification of who is in charge of software management is key to short and long-term success.
A clearer identification of who is in charge of software management is key to short and long-term success.
Anna Murray

Here are the four big mistakes that get in the way of good software project management and what to do about them.

Mistake #1: Thinking having a “project manager” is project management. It’s not.

A project manager is a professional who has studied the tools and procedures of the project management discipline and often holds a certification, such as a PMP. Despite the all-encompassing connotation of the title, many people are surprised to find out the PM’s role is rather limited. On a well-run software project the PM is tracking tasks and budgets and timelines. For that reason, I like to use the term “literal project manager.” In the gallery above is a diagram showing the literal project manager’s place on a typical project team. 

Project management, in contrast, involves many more people. There are those who will discover and understand the business requirements, who will make strategic decisions about technology choice, who will set the project’s goals and establish metrics. In short, good project management is holistic, not limited. 

What you can do: Learn all the business roles involved in holistic project management.

Many business people are not aware of the roles or “hats” necessary in a software project to achieve good governance and management, such as a project sponsor, program manager and business analyst. Taken together, all these roles achieve good project management.

Mistake #2: Not understanding the word “risk.”

In regular life, when you hear the word “risk,” you probably translate it to the following statement, “There is a chance that I will endure some harm, but in all likelihood, I probably will not.” Software development “risks” have a high likelihood of impacting budget and timeline. Many times, risks are not identified, or accepted heedlessly. So timelines and budgets are blown.

What you can do: Understand the most common project risks and account for them in the timeline and budget.

Every software project has risks. Getting the definition straight—that a risk is likely to have consequences—is the first step. Next you must identify your risks. Most businesspeople do not know how to identify risks in a project. These five items always go into my risk column until proven otherwise:

  1. Integration — the need for one system to exchange data with another.
  2. Data migration — porting data from an older system into the new one.
  3. Customization — inventing a novel feature or function.
  4. Unproven technology — employing a new/hot technology just introduced.
  5. Too-large project — tackling a massive project in one fell swoop rather than breaking it up into parts.

Sometimes risks can be avoided. If a business leader is aware of risky items and their likely consequences, he or she can eliminate features in a project or put the kibosh on some sexy new technology an influential cadre of people want. When risks are identified and accepted, contingency budgets and timelines should be set aside to deal with them.

Mistake #3: Not understanding the accuracy of the budget.

There are four methods of budgeting in software development.

  1. Comparative budgeting — when a vendor or internal team uses a recently completed equivalent project to estimate a new project.
  2. Bottom up budgeting — when a detailed list of tasks exists and can be estimated one by one.
  3. Top down budgeting — usually on a large or innovative project. Where few equivalencies can be identified and it is not practical to develop a detailed list. The team estimates big “buckets” and how long they will take.
  4. Blends — a budget that involves two or more of the above. 

As you can probably tell from reading the previous list, the accuracy of the budget will vary according to the method used. Comparative budgeting and bottom-up budgeting are generally more accurate than top-down budgeting. A businessperson may not understand why a current software development project is going over budget. They might say, “I did a project last year that seemed very complicated and it came in on time and on budget! What is wrong with you people?”

They may not understand that this previous project was comparison-budgeted against a very similar project. The current project required top-down budgeting based on its degree of innovation. Top-down budgeting is almost always less accurate than comparative budgeting, where a good recent equivalency exists.

What you can do: Understand how the budgeting methods work. Understand the different software budgeting methods and know which one(s) was used in your project. Set aside contingencies for the methods that are less precise. 

Mistake #4: Business leaders shirk their responsibilities in project management.

Business leaders with little experience in technology often raise their palms to the sky and say, “I don’t know? What should we do?”

After a few interactions like this, a group of programmers may think, “It’s my responsibility to decide.” Many organizations get into enormous amounts of trouble and expense because all strategic technology decisions are being made by mid-level programmers who have no insight into any of the organization’s actual strategy. Business leaders end up discovering too late that their customer database is a mess or that they are in violation of federal data-protection guidelines.

What you can do: Step up! It’s critical for organizational leadership to accept that however unprepared they may feel, they are in charge of making strategic technology decisions. This means involvement in software project management – in the holistic sense.


Anna Murray is a technology consultant and the CEO of emedia, LLC. Her email address is [email protected].

More in Software