Three Common Risks in Project Management

And why “DON’T DO THAT!” can be an effective strategy

Projects hit the same risks over and 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
  • The client may prove mercurial, causing delays, cost overruns, and re-work

As you look at those three risks, there’s a reasonably high confidence level that they are (or have been) happening on your projects right now. 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, on many projects, we act somehow surprised these three things evolve on our project.


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 very common risks actually have very common strategies for risk response. The strategies are to:

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

Take time to define the 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 or not 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 or not 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.

Give team members opportunity & rationale to 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; but 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.


Just because you can send an email down the hall doesn’t mean you should. Communicating in-person matters in building a well-functioning team.


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 we work with, 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 genuinely are 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.

Get 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, then they will 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 that.


Carl Pritchard, PMP, PMI-RMP, is a thought leader in risk management, an Edwards Performance Solutions supporting consultant, and the author of seven project management texts. He is the U.S. Correspondent for Project Manager Today (UK) and lectures and presents training in project management globally.

---

Categories:

Leave a Comment

 

Comments

Harry Hall

Great article! I was once asked to recover a challenged project. I quickly discovered a key problem — poorly defined requirements. My response was to get the appropriate stakeholders together and restart the requirements process — elicit, analyze, document, and validate the requirements. The developers were furious – “We’re already behind schedule. We don’t have time for this.” In the long run, it was the revival of the requirements process that saved the project.

Reply