The Invisible Enemy to Project Success: Negative Cues

There’s an invisible enemy that can kills projects.

Robert Greene, author of Mastery, puts it in these terms:

The Return of Sherlock Holmes. 1903.

In the Arthur Conan Doyle story “Silver Blaze,” Sherlock Holmes solves a crime by paying attention to what did not happen – the family dog did not bark. This meant that the murderer must have been someone the dog knew. What this story illustrates is how the average person does not generally pay attention to what we call negative cues, what should have happened but did not. It is our natural tendency to fixate on positive information, to notice only what we can see and hear. It takes a creative type such as Holmes to think more broadly and rigorously, pondering the missing information in an event, visualizing this absence as easily as the presence of something. (Pg. 194)

 Six Negative Cues To Manage In Your Next Project

1) The project sponsor goes quiet.

At first, the lack of intense questioning may seem like a relief. After a few weeks, you realize that the sponsor was withdrawing from what they perceived to be a doomed project. It’s hard to tell unless you find out what’s going on.

2) A previously very outgoing team member stops contributing to the project discussions.

Perhaps the team member is facing some difficult problems at home. In any case, the sudden decline in contributions may be an early warning sign that you need to pay attention to their deliverables.

3) Lower than expected charges from a supplier.

At first glance, this appears to be cause for celebration. I know what you’re thinking: “We budgeted $100,000 for IBM and only got billed $50,000 – that’s great!” I view such declines as a symptom of a deeper problem – perhaps the supplier misunderstood the project’s requirements and only delivered half the features you thought you requested.

4) No bugs or malfunctions during QA testing.

Software design is complex. Complex systems rarely perform as expected. That means there ought to be some bugs in coding. If there are none at all, two possibilities suggest themselves. First – the QA tester is not looking closely enough. Two – the software in question is incredibly simple and thus has a limited probability of malfunction. Before celebrating your “clean first draft” code, a second QA effort may be in order.

5) Ignoring strategy during planning.

Mark A. Langley, President of the Project Management Institute, recently wrote that “project managers are now required to be strategists.” It is easy to jump in technology and the nuts and bolts of projects right away. If nobody connects the project to the organization’s strategy, you risk running a project of dubious value.

6) Skipping the risk discussion.

In certain sectors – finance and health, for example – risk is constantly considered. In some cases, risk is ignored. That’s an understandable reaction – few people enjoy thinking about risk.

Tip: If you’re struggling to get started with risk, read my article How to Prevent Project Failure with Pre-Mortems.

7) The missing skills challenge.

Many are attracted to work on projects for the potential to learn new skills. The drive for growth and development is admirable. Project leaders should celebrate this drive. However, this drive to learn can be a mixed blessing. If a project team member lacks training resources, they may struggle. Nobody likes to admit when they’re struggling to learn something new either – so they may not tell you.

The proactive response to this challenge is simple, though not easy. Add a step in your project planning process to consider skill gaps. Weaknesses in the project team may be especially clear in the area of technical skills. Keep in mind that soft skills and political capital in the organization are equally important.