7 signs business stakeholders will sink your IT project

IT projects fail at alarming rates — nearly 70% of them, according to project management tool provider TeamStage. Common factors of project failure are missed deadlines, blown budgets, or deliverables that fail to meet original objectives.

CIOs and project managers understand these risks. They do everything they can on the IT side to address them. They pay keen attention to business requirements. They set and manage expectations and guard against scope creep. And they keep on top of project budgets.   

But what if your problem isn’t IT but with the users themselves?

My first IT job was as a junior programmer. I’d been assigned to a large order-entry system project when users in the Order department began to rebel. The project had been going for over a year, but user resistance became so great that the project was cancelled, and both the CIO and the project manager lost their jobs.

As a junior project person, I didn’t really know what went wrong—but I did learn at an early point in my career that running into headwinds with users can be catastrophic.

Later as a CIO, I took this early lesson to heart. I made it my business to stay in regular contact with users and business managers. Part of this job was keeping an ear to the ground for early signs from users that created project risks — key stakeholders in particular.

Here are some common early warning signs of stakeholder behaviors that signal a project could be in trouble.

1. Failure to attend meetings

Project meetings start out strong with full attendance and enthusiasm. The meetings include managers of the user areas that are involved in the project. Over time, however, you notice that these managers begin to skip meetings. At first, they let you know they have a conflict, but as time goes by, they don’t even tell you. They simply don’t show up.

This is a sign of stakeholder disengagement with the project. It impacts both user and IT staff morale because they also see the lack of interest from stakeholders— in some cases, their own managers.

2. Sending subordinates

Another sign of stakeholders and user managers disengaging from projects is when they start sending subordinates to meetings in their place. Inevitably, a critical project decision comes up in a meeting, and the subordinate says, “I don’t know. I’ll have to check with my manager.”

Inability to make decisions in meetings is a primary reason why meetings become dysfunctional. In a critical project, a CIO or project manager can’t afford to have too many of these occurrences.

3. Missed user deadlines

You’re running a project with vital user input and collaboration. IT is hitting its task due dates, but when a task gets over to the users, such as a function test, there are repeated delays and missed deadlines.

The most likely reason is that the user domain has other priorities that it sees as more pressing, but sometimes it is a sign of sidelining the work on the part of the stakeholder who heads the domain.

If a regular pattern of missed user deadlines begins to form, it’s time for the CIO or project manager to pay a visit to the business unit stakeholder to ask whether the project should be deferred or cancelled.

4. Distraction

Managers are called on to do many things, so it’s not uncommon to reach a point where a user manager who initially advocated for or initiated a project becomes so distracted by other business that they can no longer focus on what’s necessary to move the project forward.

Managers try to juggle priorities by giving each task what they can, but it may not be enough. When other priorities get in the way, it’s time to consider pausing the project rather than letting it run aground in due course.

5. Negative feedback

A key stakeholder champions a project, putting a get deal of energy into getting it off the ground and progressing. But suddenly you begin to receive negative feedback from the stakeholder and their staff. Constructive criticism is to be expected when project members see corrections that must be made, but if the criticism continues to grow, it’s time to take stock and call a meeting.

The sooner this is done, the better, because many times a stakeholder won’t directly tell you that they’re disappointed with a project, so they’ll turn to negative feedback.

6. Pursuing other options

I once was assigned to a project where users and IT were working on a system, but the users had already soured it. What the users did was budget their own dollars to purchase a commercial system that wasn’t as robust as the internal system being developed, but that was easier to use.

IT should have stopped the internal project then, but leadership didn’t know the users had gone on to another system. Instead, the users continued to give feedback on the internal system, although not with regularity, and the project continued, redundant and effectively dead.

In an ideal situation, the CIO should have maintained close contact with user management so IT would have been alerted immediately of the move to a commercial system. Further work on the internal system could have been stopped, and IT could have moved on.

7. New boss

Things are going great on a new project that IT and users are building. Then the original stakeholder-advocate leaves the company and a new manager comes in.

The new person isn’t interested in an internal system. Instead, he favors a system that he used at his former company. You sense he’s likely to go with the system he’s used to, and pull the plug on the project.

The best approach is to discuss the situation head-on with the manager and other stakeholders so a definite project direction can be agreed to.

Touch base regularly — and pivot when necessary

Great projects are characterized by strong collaboration and enthusiasm among IT and end-users, management and budget backing, and excellent user and technical performance. Pundits continue to tell us that many projects fail, but they don’t have to.

What we do know is that the easiest issues to troubleshoot and resolve in projects are the technical ones. The tougher issues involve people, and many times these people are the end-users a project is meant to benefit.

For this reason, the CIO and IT leadership team can reduce the risk of a failed project by regularly touching base with users, keeping a finger on the stakeholder “project pulse,” and immediately stepping when they sense a change.