6 ways to predict project trouble

Project management deadlines

How can I get early warning when a project is likely to run into trouble?

As a project manager, we have all worked on projects that went well, and projects that went less well. Once a sprint or milestone runs late, especially if it's very late, or if this happens a few times in a row, it's fairly obvious a project is in trouble. But by this time, it's already difficult to recover.

Are there ways to anticipate trouble earlier in the process, before it shows up in delays? Here are some suggestions:

1. Key people missing

Key stakeholders, designers, implementers, or management are missing from sprint ceremonies and important meetings where scope and requirements are discussed

2. Meetings are not valuable

Meetings don't seem to be producing valuable output. Team members might be contributing very little. Or they might be constantly debating the same topics, without coming to resolution or decisions.

Team members are scared to raise important issues, especially if they risk announcing bad news.

3. Architecture fixed too soon

If the architecture is fixed too early, especially if the decision is made by someone very senior, requirements that come in after this point are often bent to fit the shape of the solution. This should be the other way round.

4. Estimates are very large

If size estimates are very large, or hold a lot of risk, this is often a sign that the project requirements are not well understood.

5. Reviews or approvals slow

If you have procedures for code reviews or quality signoff, QA, or UAT, and these are happening very slowly, this can be a symptom that either the reviewers are overloaded, or there is a lack of respect between the reviewers and the rest of the team. Either suggests that the team balance is not right.

6. Requirements or constraints appear late

If requirements or constraints only surface after the requirements phase is closed and implementation has begun, this is likely to derail project timelines. Teams are often under pressure to accept the changes under initial contingency sizings, but if there is a major new requirement, it probably needs contingency in its own right.

Summary

While none of these are easy to fix, being aware that they are often symptoms for project delays later on should help you to make the decision to investigate further, and address them early.