How to recognize the warning signs of a project crisis

You sometimes can identify markers for an imminent project meltdown. But you have to pay attention to the red flags. Here’s what to look for.

I should have recognized the signs earlier. Everyone else in our startup software company was busy at work, aware that we needed to finish our software to acquire the venture capital we needed. Yet, Sandra began bringing the newspaper to work, and reading the entire thing, while the people around her wrote code, worked on the business plan, or tried to make sense of our accounting. Although it was inevitable that she'd leave – and perhaps the team implosion was also a foregone conclusion – I somehow refused to deal with the early indications.

Not every software development crisis has an early warning system, but plenty of them do. If you learn to recognize the signs early enough – and you're willing to confront the problem, as I was not – you may be able to prevent the project from failing. If you can’t prevent the meltdown, perhaps you can save yourself.

Meetings of the minds

When you first join a team, or when you begin to have a bad feeling that you can't quite name, pay attention to the way people behave during team meetings. I don't mean necessarily that you should rush to get your résumé in order, if people get upset with one another. But do watch for signs that the proceedings don't matter to the participants.

A quality engineer at a midrange German bank attended his first meeting on a new project. People arrived and left at will, without saying a word. Nobody kept minutes, he told me. "We usually don't need that," project participants told him. At that point, says the engineer, "I knew that the level of discipline in this project was far too low to produce anything valuable. This proved to be true within a year." 

Are developers writing code instead of paying attention to what the users are asking? Do people regularly check their e-mail? It's time to wonder about their commitment. 

Meetings also show stress among the people who are supposed to be working together, especially when meetings don't happen. In one project, where formerly independent teams were expected to merge, "They saw themselves as competing with one another," reports Solomon, a programmer at a large financial firm. "When we did the requirements interviews, the users (and their managers) were looking to 'protect' the 'way we've always done business.'" Some managers planned to limit the influence of other groups; political battles were fought over the design. "There was no process for surfacing these issues (many of them valid business issues) and having management make a decision," Solomon says. 

In fact, the number of meetings you attend is a sign on its own. If you have to gather a committee for a two-hour roundtable for every decision – because nobody can accept one person making the call – bump that project to the bottom of your priority list. Particularly so if meetings have more than five people, or when managers outnumber workers. Each such meeting moves the project doomsday clock closer to boom. 

Another red flag is procrastination about timely updates for stakeholders. For example: A decision is required but not yet made. A milestone is not reached due to delays but someone doesn’t want to disclose that stumble. “Those may not kill or put a project in ‘zombie,’ status,” says one programmer, “But if the communication has broken down it's a good indicator of heading that way.”

Expectations out of whack

I've heard dozens of stories from developers and tester about the signs that a project is headed downhill. By far, the most common source of problems is inaccurate or poorly-communicated project expectations – and an inappropriate reaction from management when things go awry.

"Why haven't we done [this task]?" 

"Oh, [task] is easy; we can do that any time." 

For example, one tester once was on a project that was completely oversold. The project team spent long weeks on the project. They even pulled all-nighters. But the scope was too large for the timeframe and the staffing. "The pressure on the company to produce a customer (and on the executive team) was such that the team was nearly run into the ground." 

This tester was lucky. After a wholesale change in upper management, a VP was sent to fire everyone in sight, after being told that the problems were the team's fault. But this executive was astute enough to listen. The VP realized the problem wasn't the staff, but the sales person and upper management who had sold the project. "He was able to slightly reset expectations with the customer, and we managed to put the project into production, producing a reference in the process." Whew. One happy ending. 

Others aren't so fortunate. Don, a software consultant, found that "the surest single measure of increased likelihood of project failure is a management or owners who believe the task being performed is of one or more orders of magnitude less complexity than it actually is. This is usually reflected in poor or inept staffing… and other resource and planning shortfalls."

The C-suite gets involved

If there’s no project champion, by whatever job title, you should worry. Project sponsors need clout; the people above them have to respect them. Otherwise, while projects can be completed, they're rarely transformational. However, the project champion also captures and communicates the team’s vision.

The sad alternative is when you see a big upswing in manager and upper-level manager check-ins. There’s a sudden surge in, “Is there anything we can do to help?” questions that would have been useful two months earlier. 

Or personnel appear who aren't integrated into the team. They don't seem to have clear roles. For instance, a director from another department shows up, demanding to know why they weren’t consulted on the project, even though their superior had approved the process or task. 

Another sign: Your project scope changes like the weather, for reasons you cannot fathom, and you have no ability to push back. As one techie described a too-familiar scenario: “The smoke of your burning deadlines will outline vast and terrible corporate gods who do not wish you well.”

Project plan? What project plan?

Often, those inaccurate expectations are a sign of earlier errors in analysis. A sure sign of failure is when time pressure exceeds normal limits – by far. "All of a sudden, you have loads of work to do, in ever-decreasing time intervals,” says a consultant who works in financial organizations. “This clearly shows that some points during the analysis and/or design phase was done horribly wrong.”

A related sign: The software is being built in parts, and nobody has integrated the parts yet. Especially if it's because they don't like to collaborate with the other authors. 

There are so many variations.

• The project manager never presents a timeline, schedule, or milestone list.
• A deadline for an important task is postponed more than two times.
• Your weekly update call includes a lot of awkward silences. Or the definition of “done” drifts into science fiction.
• You hear, “Are you sure this will take that long?”
• Or they say, “Let’s use the occasion to also do <big thing that’s completely unrelated> while we have leverage.”

You don’t have to wait long for over-complicated expectations to emerge. Solomon adds, "When the chief architect explained the project, I started to count the tiers, and arrived at seven. A seven-tier architecture would contain so many chances to fail that I was immediately sure that the product would never see the customers. I was right. Twenty-three million Euros for nothing."

The attack of the killer accountants

Your first clue: The snack closet doesn't get refilled.

The more elaborate version: A random bean counter yells for the fainting couch when you submit a project expense line item has been utterly unremarkable during your entire tenure. Long-standing vendor contracts are scrutinized. Suddenly you need signoff from busybodies who have to render judgment on a critical spending component of your plan which nonetheless represents <1% of the budgeted outlay. 

The cost cutting isn’t logical. They don’t lay off an engineering team, which might be a hard-headed business decision. But they cancel required services, such as the organization’s Trello subscription.

Inappropriate staffing

Instead of dealing with the underlying problem – the team or the company can't deliver what they'd promised – one way that poor management deals with the impending crisis is to hire or fire people. Unfortunately, they often pick the wrong ones. For example, in one project, Management felt the project was underfunded for the goals it was trying to reach. They couldn't hire enough people with the right skills (that was too expensive) and caused the project to be slow to deliver.

When you can't hire as many people as you need, you attempt to get more from the existing staff. In some cases, management threatens to lay people off if they don't work harder. In one tester's one-on-one session meeting, the manager pointed out that the tester wasn't at work in the evening. The tester told him he currently worked 50 hour weeks, and the company only paid for 37.5 hour weeks. The manager responded, "If you are not working 60 hour weeks, you are not working hard." Ten minutes later, he added, "If you are not working hard, you are the list of people to be laid off." The tester took the boss at his word. "I'm not sure if that project ever shipped. I quit and found a new job." 

How long do you wait before you recognize there's a crisis? David's ready to throw in the towel. He's in a group that handles a couple dozen products, but David is the only developer, tester, and now manager. "I know the situation is bad. My company decided to fix the problem with people leaving or being laid off by building from the top. My program manager left, so naturally they replace him with a VP of Sales." Two months later, the company brought on a VP of Development, but there's no product manager "…and the planning is basically left to me. I'm still the only developer, several months later, and the VP of Development still hasn't had time to find out what my product line does. At least he hasn't made any real decisions yet. They fired the VP of Sales yesterday, due to some personality conflicts and probably a lack of improved sales." I think David is looking for a new job. 

Is there a crisis looming in your project? What are your own warning signs? Tell us about them on Twitter at @functionize.

Please read this article: "Selective QA Interview Questions for Managers to Ask" that can also help tracking down out the root cause.

It may not save a project gone awry, but it might help to have a Chief Quality Officer to ensure that someone in the organization cares about making the software work correctly.