Fix 4 common software project errors

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

Mistake #1: Thinking that 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 project manager’s role is rather limited. On a well-run software project the project manager is tracking tasks, budgets, and timelines.

For that reason, I like to use the term “literal project manager.” Here’s 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; those who will make strategic decisions about technology choice; and those 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. Timelines and budgets are blown.

What you can do: Understand the most common project risks—and then account for them in 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, that leader can eliminate features in a project or put the kibosh on some sexy new technology an influential cadre of people want.

On the other hand, when risks are identified and accepted, contingency budget and timeline 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 the costs can be estimated one by one.

3. Top-down budgeting—Usually used 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 methodologies.

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 business unit executive may not understand why a current software development project is going over budget. “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?” is a typical reaction.

The executive may not understand that his 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, “OK, it’s my responsibility to decide.”

That’s likely the beginning of trouble.

Many organizations get into enormous amounts of trouble and expense because all strategic technology decisions are being made by mid-level programmers. These employees 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 most holistic sense.