Some projects are successes, but a frightening number are not. If you are ever on one that is destined for failure—and odds are you will be—how will you know before it is too late? In “Three warning signs that your project is doomed,” we examined some business-related signals that your project is headed for a less-than-glamorous end. Here, we will continue our look at some of the danger signs by examining four warning signs that involve people issues.

Because much of what leads to project failure is not technology related but rather people and process related, it is important to consider these “softer” issues. Specifically, we will look at factors that involve users and stakeholders on a project (users not communicating and project sponsorship problems), as well as shortcomings in developer communication (change management and status reporting). If you see any of these situations on a project, it may be a sign that the project is on the slippery slope to failure.

Problem #1: Your client or user group will not speak with you
It’s never a good sign when the client or user will not speak with you. It can mean a lot of things and none of them are positive. It may mean that the business group has higher-priority work or is too busy to cooperate with you. If that is the case, the project is headed for disaster. You must have the cooperation of the client and users to successfully implement a project.

Lack of user participation can mean that users are resistant to change. There is an entire field called change management that is based on gaining end-user support and acceptance of new systems and processes. This should not be confused with change control processes that are used to manage the scope of the project. Change management is outside the focus of this article. The point is that for a system to be implemented effectively, the users must be involved.

Other reasons may underlie a lack of client or user participation. It may be that the business has decided to kill off the project or implement a different solution. The project sponsor may be leaving the existing users out of the project because they are losing their jobs when the system is implemented. Or it may just mean that the sponsor is incompetent.

Projects need input from the client or the user group. Without it, requirements and system design take place in a vacuum. The ultimate solution may not meet the needs of the business.

If your client or users are not working with you on the project, you have a problem.

Problem #2: The project sponsor is ineffective or unavailable
Having a good project sponsor is a critical success factor for project delivery. He or she can help to keep a project focused and on track and help remove major roadblocks for the team, especially in a politically charged environment.

Project sponsors must be competent to clear those roadblocks, and they must have the power to resolve issues with conflicting interests. They also need to be able to make tough decisions to support the team.

If the sponsor is unavailable, the roadblocks can begin to affect the project. Company politics can begin to take a toll on the team and progress. And when a project sponsor leaves the company, a number of questions arise. Why did the sponsor leave? Was he or she forced out? Will the political foes of that sponsor try to kill off the project or change its scope midstream? Will your career be affected by these political foes? You may not want to stick around to find out.

Problem #3: There is no mechanism for managing change
We all know by now that change on projects is inevitable and that managing the change is important. Good change control processes are not hard to manage, but they do require attention to detail and diligence. Effective change control requires close cooperation with the client or business owner for the software solution.

Unfortunately, some projects are still run without a process to manage change. Either the scope of the project is vague, there is no discussion of change control, or the client or business owner continually changes what the solution is supposed to look like. Projects without change control processes are impossible to estimate accurately because the size of the solution is changing continuously. In addition, changes usually result in some rework that further delays progress and demotivates the project team.

Keep in mind that clients are not the only source of change. Sometimes the team itself can cause a change of scope. Team members are human beings, after all (most of them anyway), and humans make mistakes. Members of the team may have heard or made assumptions about the solution that is “changed” from what the client actually stated. Another possibility is that the requirements are sufficiently vague so the team members interpret them differently from the original intent. Or team members could inadvertently be creating a more elegant or complex solution than required. This is often referred to as gold plating.

If the team you are on does not have or follow a published change policy, ask why. If you don’t get the answers you want, be alert to the possibility of a project that is out of control and risking failure.

Problem #4: There is a lack of accurate status reporting
Accurate status reporting is the lifeblood of a project. It provides communications to the stakeholders and offers a mechanism to determine whether corrective action is required. It also serves as a scorecard to show where the project is versus the plan. All projects need status reporting.

There are two main reasons why a project might not have status reports: The project manager doesn’t realize they’re needed, or the status is so bad the manager has stopped reporting on it. Of the two, the latter is probably worse. If a project is so far behind the stated goals or over budget that it’s not being reported on, it’s a candidate for cancellation.

If your project lacks status reporting, it is not critical to find out why. Run away as fast as you can.

What if your project is in trouble?
If you’re not the project manager, there may not be much you can do about a failing project. However, if you can determine that the project is in trouble, there is some action you may want to take.

  • If your users are refusing to participate in a project—or won’t even give you the time of day—try to open your own dialog with a key individual on the user side of the project. It may not save the project, but it sure can’t hurt.
  • Look for another project (one that’s in better shape than yours) that you can transfer to. And by the way, don’t say why you’re leaving your current project. After the fact, everyone will just think you made a lucky move.
  • If things are really bad, look for another project at another company.

If you’re stuck performing a death march on a failing project for the next one to two years, it will not do your physical, mental, or career health any good. Take action now. If you can’t save the project, at least save yourself.

What is the health of your project?

If you have been on good projects and bad, what has been the difference in how they were run? What actions have you taken when stuck on a failing project? Send us an e-mail with your thoughts and experiences or post a comment below.