Risk isn’t necessarily Harm

The term “risk” gets batted around projects like a ping pong ball zipping around a startup. It’s everywhere. Your schedule is at risk. Your budget is at risk. Your resources – fraught with risk. Your scope is basically nothing but risk.

But how often do we really stop to evaluate what we’re (a) worried about and (b) able to manage?

Fundamentally, each dimension of a project is of course going to have risk, in the sense that something incomplete could not get completed. It might not be completed by a certain time (schedule risk) or at a certain amount of money (budget risk). But are we sure we’re properly equating risk with harm?

Harm is bad. We want to avoid harm. The notion of harm insists that there’s a consequence to a bad outcome. Risk… Is a little murkier. It implies that there are consequences, but the nature or impact of those consequences may not necessarily hurt.

Here’s an example: Your sponsor walks in the door and says, “This new software application is critical for our 3rd Quarter sales numbers. So you must have the project complete by end of June.” Now you’ve established a time-box, and all future decisions (scope, budget, resources, etc.) are likely derived from this boundary. Slipping any of those facets might result in increasing the risk of your project. But can you clearly articulate the harm? This is where an honest discussion needs to happen with your sponsors & stakeholders.

The Discussion:

Product & Project Manager: You said that the app is CRITICAL to 3RD QUARTER… Can you define those two things?

Sponsor: Not really. I’d just really like to have it done by September so we can train everyone during the holiday slowdown.

Sometimes, it’s that silly. The 3rd quarter really means the 4th quarter, and critical really means “nice to have.” But, sometimes the discussion can be direct, and creates a measurable structure to evaluate risk:

Sponsor: Sure – We think that this will boost our sales team performance by 5% per person. Right now my average salesperson is doing $120,000 per month, so I’d like to net an extra $6k per person per month. Across our 10 salesperson team, that’s $60k incremental per month, starting July. That gives us an additional $360k revenue for the year.

Product Manager: Which features in the scope are the ones most directly associated with the revenue bump you’re looking for?

Sponsor: [ Points to 1 “magic feature.” ]

Now you’ve established your risk profile: Every “day” of slippage past June 30 is going to cost the company something like $2,000. Also, you’ve found the #1 item on the deliverable that without implementing nets actual harm to the project. If that feature doesn’t work right, the whole “app” might as well be useless.

These sorts of discussions can be tricky, so have them at the right time (hopefully early – before you’ve committed to anything) and with the right people (ideally, the sponsor / product owner). But now, if a resource slips on a non-essential feature, you can at least differentiate between harm and risk in a meaningful way.