Thoughts on managing risk

Peter Nelson’s thoughts

Risk

Risk is like fire. Embraced with respect and awareness, it’s not an inherently bad thing. The reality is that even when we do things that we’d like to believe to be “risk free,” there’s still some inherent amount of risk present.

How do you reduce risk to a point that it’s known, respected, managed, and mitigated - as much as possible? Here are the approaches that I’ve employed, that have worked well for me.

Listen Early

At SensusDx we’ve rallied around an approach that we call listen early. The approach is to always be aware of what’s going on around your project and to be questioning, inquiring, and challenging as early as possible. The one thing about risk is that the sooner you identify it, the more time you have to deal with it.

The other thing about listen early is that it implies that there is conversation happening with other people. As a participant in the conversation, you are appropriately focusing on what’s being said and shared. Listen early also looks for what’s not being said. This is akin to what great jazz players do with their performances. It’s not just the notes on the page they play that creates a great performance, it’s everything that’s in between, behind, and under those notes too.

Stakeholders

Talking about people … it’s also crucial that the dynamics within and between all stakeholders are understood. If you are attempting to deliver a project in a highly contentious or dysfunctional environment, the odds are stacked against you. Even if the financial rewards are attractive, the future grief and angst likely to emerge offsets any monetary gains previously hoped to be realized. This may take time to research all of “the players” in the project, but it’s time well spent. Ideally, each party isn’t too far apart in its expectations and you can bring the project together to satisfy most, if not all, of the stakeholders. 

My remedy to these situations is to be face to face (or FaceTime or an individual Zoom or Teams chat), as much as possible, with the person or people where the friction is emanating from. I used to call it “putting my head in the mouth of the lion.” It’s not a particularly fun thing to have to do, but it does have to be done. And in my experience, people give you a lot of respect for confronting these things directly - even if they don’t want to deal with it. 

Requirements

Iterative development has changed things a bit with regards to requirements development. However, knowing what you are trying to build and knowing that all of the stakeholders agree - and perhaps they also know that what’s being built can change dramatically over iterations - also puts you well on your way to successfully mitigating risk. 

Software sage Steve McConnell has written about how requirements aren’t just out there, they have to be developed. This is the whole idea behind elicitation. Uncovering requirements from people takes time, patience, finesse, organization, persistence, and focus to ensure that all stakeholders are on board with what various stakeholders put forth. If you go through this effort with diligence, care, and sensitivity, you can bring everyone together and mitigate a lot of risk.

Documentation

Having created a very successful knowledge base with my colleagues at Informz, I’ve seen firsthand how a documentation mindset reduces risk. When the technical writers are part of the development process, they often see things that would otherwise be overlooked. We often think of a documentation person as a writer, but if you dig a little deeper you’ll realize that they are really wonderful QA/Testers and User Experience advocates. Because a good technical writer is always thinking about their audience - an end-user role of some sort - they always bring that customer perspective to the table.

Great documentation also feeds the efforts of the learning, marketing, sales, integrations, support, and other developer teams. As well as reducing risk, a solid documentation strategy provides tremendous lift to an organization.

And now, over to Garry!

Garry Polmateer's thoughts

While I’m no fan of project risk, I accept that it lurks behind every corner and needs to be dealt with.

The context for this piece is managing risk in regards to a technology project.  My experience is mostly with Salesforce technology projects, but there are some universal truths which I believe hold true in any tech project (and probably beyond). In my current role, I help construct project scopes & plans every day.  I want to help design a project to be great for the customer while also managing risk for both parties.  When I look back over the past, there were themes that were consistent on great projects, and similarly, on not so great ones.  Here are a few things that I’ve found to be quintessential to project success.

Project Champion

Without someone who is invested in the project’s outcomes, the project will not have that constant cheerleader and motivating force behind future success. If no one is raising their hand enthusiastically about “owning” a project, it’s an early warning that there could be a lack of interest to see the project through. If you can’t find a champion, consider realigning the project to be something that someone can be excited about, or create incentives that generate excitement.

Experience

People who have “been there, done that,” are more likely to attain project success. Are you getting useful insights about the team’s experience (on both sides) to assure the mix of talent is in place to make the project successful? If there are serious deficits, these can be offset by additional training - if time permits - or by bringing in additional staff or skilled contractors.

Documentation

Nobody likes documentation but please, please be kind to your future self and invest in documentation early!  It doesn’t have to be a massive undertaking, especially if a culture of writing things down is core to the initial project.

Technical Debt

It’s always tough to look into your crystal ball to try and predict the future. Tech debt is real. Accept that it will happen. Investing in discovery and research up front can help minimize technical debt, but ultimately things change and technical debt will begin accruing.

Contracts

Well written contracts can make or break a project. I’m not just talking about whether the contract passes legal muster for all stakeholders, but that the consideration that was put into the project scope is sufficient.  Was the contract drafted by technically competent and experienced individuals? Is there a change control process in place? Is what’s in scope and what’s out of scope clearly defined?  

Lifecycle Perspective

The launch is just the start. What about when the project is “in orbit”?  Are you considering the maintenance of the application? Some themes I’ve seen again and again:  Adoption, Usability, Data, Upgrades, Support, and Security.  These aren’t always considered at the start of a project.  All of these are “over time” items which benefit from ongoing effort. If you have an active champion, it can REALLY help with this.

Change Management

Over thousands of projects, we’ve seen a lot of surprises along project lifecycles.  Expecting that there will be some kind of change is crucial in how to recover from a surprise.  

Exciting Conclusion

We hope you’ve enjoyed our views on managing risk. We’ve shared these views to “get the conversation started.” We encourage you to add your comments and share your favorite risk management resources.

Thanks!

Garry & Peter