5 ways not to save failing tech projects

It’s an unfortunate reality of technology, and of life: You are going to encounter failure.

How often does this happen? More often than you think.

Companies rarely advertise their technology bungles. Unfortunately, this means others can’t learn from them.

As a technology consultant, I get called in at these times, when projects such as software development, platform rollouts, and systems installations are going off the rails.

Here are the top lessons from the field of what not to do.

1. Don’t find fault.

As the old saying goes, “Don’t fix blame. Fix the problem.”

There will be time enough to find out why it all happened. But ferreting out who was responsible is a waste of time when you have a technology project in trouble.

Forget about the why and focus on the what. What must be done right now to put things on a better course?

People often resist this strategy, thinking if they just find and eliminate the “culprits,” the project’s problems will be solved.

Following this path gets you nowhere.

Teams and vendors disintegrate into finger-pointing and blame-deflecting—an utter waste of time.

2. Don’t—be optimistic.

Sounds crazy, right? It’s always better to focus on the positive, isn’t it?

However, it’s important to make a distinction between a positive attitude and kidding yourself about reality.

Often, with a technology project that’s going awry, project leaders try to portray the situation in too sunny a light.

• “Things are not all that bad.”

• And, “If we just do A, B and C, the project will be back on track in no time.”

In addition, as I’ve noted in my book, programmers tend to be an over-optimistic bunch in general. 

Keep your positive can-do attitude but, at the same time, get the cold hard facts quickly. Tell your teams not to sugar coat it. You want to know the pessimistic reality, the very worst case, ASAP.

3. Don’t throw resources at it.

Consider the following dialog between two men:

First Man: How long does it take for a woman to have a baby?

Second man: Nine months.

First Man: What if I get two women working on it?

Illustration by Barbara Hranilovich/ https://hranilovich.com/

This silly scene captures an unfortunate reality about adding resources to a technology project at a late stage.

It never works.

Frequently, if deadline is key, managers will opt for this solution: “Budget be damned! We have to make Sept. 1. Call up the vendor and ask them for more people.”

Here’s why this doesn’t work:

Your current team has been working for months, slowly coming up to speed on business requirements, system eccentricities, task details, and timelines. Your new team members are going to somehow have to come into possession of all that knowledge. Who will onboard the new members? Your current team. Therefore, the project slows to a crawl as new members are integrated into the workstream.

Of course, larger teams are possible in technology projects. But this must be planned and coordinated from the project’s start.

Think of it like a ballet. In a large production, all the entrances and exits must be well choreographed so dancers don’t bash into one another.

4. Don’t squeeze the vendor.

Fact: There is too much vendor-blaming when a tech effort goes sideways.

It makes sense. Vendors are easy to scapegoat, saving internal teams from consequences and possible job losses.

That said, of course there are times when a vendor does not perform. If a vendor has made serious mistakes or shows incompetence, business managers want the firm to do penance. The vendor is required to provide fixes and remediations. Often, they have an A-team hidden away somewhere, and the business insists on this team being brought in to rescue the project.

At this point, the vendor is going to be seriously dipping into their profit margin or outright losing money. On top of that, the company is diverting its best, moneymaking A-team for a significant period of time.

Now, how is that really going to work?

In the real world, the A-team swoops in for a while and makes things somewhat better. Then, as the vendor gets tired of making amends, you get less and less of that team’s attention. For a truly non-performing vendor, it’s often much better and cleaner to cut ties and start with a new firm.

5. Don’t try to stay on budget and timeline.

In a tech project with problems, either the budget or the timeline (sometimes both) must be sacrificed.

Business managers waste valuable time asking their teams to investigate strategies to stay on the same budget and timeline. This is a fool’s errand, keeping you from developing a workable plan to save the project.

A key task is to prioritize. Which is more important—the timeline or the budget?

• If you have a promotion for Christmas, an audit deadline, or a license with a large renewal fee set to expire, it’s your timeline.

• If you simply “promised a delivery date to your boss,” then it’s likely your budget is more important than that date.

Career knowledge painfully purchased

Failure is never pleasant, but it is often a learning experience. Companies that handle tech failure well go on to improve performance on subsequent projects.

The spirit of these Don’ts is at the heart of a well-managed tech failure. Keep moving, focus on solutions, and save after-action reviews for later. At that later date, and with the hard lessons learned, the post mortem is much more valuable.