Loading...
Quick Links

The Three Most Common Risks in Project Management

Projects hit the same risks over and over again:

  • The requirements may not be adequately defined, causing re-work;
  • The team members may not collaborate adequately, causing delays and cost overruns; and/or
  • The client may prove mercurial, causing delays, cost overruns and re-work.

As you look at those three risks, you probably have a reasonably high confidence level that they’ve happened on your own projects. They’re common. They’re pedestrian. They happen on virtually every project. People are human and change their minds. Requirements are generally difficult to define. And yet, we still act surprised when these three things evolve on our own projects.

Assuming you are immune to common risks is like assuming you are immune to the common cold. It’s a lovely thought, but…

Perhaps the more amazing thing is that these three common risks actually have common strategies for risk response:

  • Take sufficient time to define the requirements;
  • Give team members the opportunity and rationale for playing nicely together; and
  • Get information from the client and give information to the client in writing while looking for any dangerous language along the way.

On Defining Requirements

“Forget the requirements! Start building!” Oddly enough, that’s the real-world sentiment of many organizations. To show physical, visible progress, they want to start creating something before they fully understand what it is that they need to create. Sometimes they succeed, but more often, they don’t. What’s a major risk to almost any project? Unclear or undefined requirements.

To validate whether you truly understand a requirement, it takes at least three participants. One should be a representative of the ultimate product owner. That person can define what they need. Another should be a representative of the product provider or generator. That person can define what they’re going to deliver. And the third person should have been an English major in college. This individual will be responsible for determining whether vague language is included in either of the other parties’ statements.

The easiest way to find iffy requirements is generated by an adjective hunt. Seek out the adjectives. User-friendly. Legible. Sufficient. Fast. Limited. Uninterrupted. Reasonable. Those are the words in a requirement that anyone can leverage/exploit to their own advantage. They are the holes in what may otherwise be a reasonable document. Or better still, they can be defined down the road. Suggesting that terms can be defined later generates huge risks. Don’t do that.

On Helping Team Members Play Nicely Together

The Internet era has brought about a strange phenomenon. Workers can communicate real-time with someone halfway around the world. They can also use the same communications tool to talk with someone two cubes down the hall. Just because they can, doesn’t mean they should. When staff are deployed in the same physical space, it’s a good idea to allow them some face time. Faces matter. They provide a human touch and a human connection. And for those team members that are halfway around the world? We need to make sure we find some ties that bind.

Little things matter. Dogs. Children. Cars. Vacation spots. Hometowns. Familiar landmarks. The more that we can do to find the small threads that bind us to the rest of those with whom we work, the less chance they will assume anything less than positive intent. As managers we want positive intent. We want our team members to feel like they are genuinely part of something larger than themselves. And they need to know that we appreciate them and believe they add true value.

Team members are often left in isolation under the assumption they’ll get more done if they just get basic direction and someone to point the way. Don’t do that.

On Getting It in Writing

From virtually any perspective, this risk strategy sounds cold and calculating. Sign it. Someone asks you to do them a favor. You say, “Sure! Happy to! Just sign here that you wanted that favor done!” It sounds impersonal and like you’re doing harm to the relationship. But nothing could be further from the truth. Signatures have meanings. We only sign things that truly matter. If someone really wants a favor, they’ll be willing to sign a piece of paper saying, “I wanted that favor.”

It affirms what’s been said. I always confirm that everyone knew what was requested, when, why and how. It clarifies relationships. Sadly, many relationships die on the altar of miscommunication, but the written word affirms communication. In a somewhat ironic twist, many managers refuse to ask for a signature because they feel it creates more distance in a relationship. In the long term, it’s the documentation that affirms the relationship existed in the first place!

Managers often refuse to ask for promises in writing because they’re afraid the other party might be hurt. Don’t do that.

These three “don’ts” may not seem like much in the scheme of a multimillion-dollar project or a decades-long relationship. But they represent three of the simplest, clearest, most readily implemented risk responses you could put in place.

Do you have risks you’d add to this list? Let the MPUG community know in the comments below.

Carl Pritchard
Written by Carl Pritchard

Carl Pritchard, PMP®, PMI-RMP® is the author of seven project management texts, and co-produced “The Audio PMP Prep: Conversations on Passing the PMP® Exam” with Bruce Falk. He is the U.S. Correspondent for the British Project Management Magazine, “Project Manager Today” and serves on the board of directors for ProjectConnections.com

Share This Post
2 Comments
  1. So simple, yet so profound. As an IT software implementation project manager for nearly 20 years, I live by these very basic but key principles partnered with another key principal of the triple constraints. Thank you for this very succinct and clear summary of the critical elements of implementing any project.

    Reply
  2. Carl, thank you very much for this very practical tips to mitigate project risks. Especially “on getting it writing” is a really important one and also that with the requirements. The combination would be: Let all important stakeholders sign the requirements documentation!

    Reply

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Please complete this equation so we know you’re not a robot. *

Thanks for submitting your comment!
You must be logged in to comment.