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.