Reframing to Reduce Risk

From what I have been able to decipher in my career businesses are around to make money. The way they make money is by offering goods and services to people willing to pay for them. Each business has their idea of the best way to deliver these goods and services they believe in some way sets them apart. Most businesses I have come across have come to settle on an approach that allows them to work on individual separately managed projects resulting in an increment of business value being delivered. Something similar to this:

• Organize around projects
• Present the work that needs to be done in “clearly defined” requirements
• Staff the project appropriately according to the initial understanding of the scope and demand of the project
• Work hard on this project until it is completed and delivered to the market

In my experience some risks for delivering these projects on time and on budget might be identified by a project manager early on in the initial inception phase of the project and might be reviewed at the end of each project, but not much attention is paid to the risks during the life of the project.

I understand that the following might not be a revolutionary brand new concept, but I wanted to work on exploring the intricacies of this idea with you while I continue to work through this myself.

Staying with a “Known Loser”

By not reassessing the risk throughout the life of the project we miss out on some great information to help us determine if the work can be completed on time (or at all for that matter) until the project is actually released.

We will continue to sink money into the project until it is “finished” even if everyone understands that there is no way to recoup our money through the sales of the eventual end result. I believe a big reason for staying with a “known loser” is that we become emotionally invested in these projects and stop looking at them objectively.

What if we were to stop looking at projects as work that needs to be done, and reframed them into a bucket of risk that needs to be removed.

Shifting Focus

By shifting the focus to reduce risk it allows us to have a different conversation about the work we are evaluating. If we are performing a lot of work without reducing our risk, we are simply pushing out the inevitable delay of a project thus causing us to spend even more money. However, if we were to focus on removing the risk associated with the funded work we can determine if it is still worth pursuing or if the money earmarked for this project would be better suited spent somewhere else.

I have recently begun to realize that the project progress drivers I used to focus on and track are actually not very helpful to measuring the likelihood of a project being completed on time.

Buckets of Risk

I believe that reframing our projects as a reduction in our exposed risk will allow us to focus our conversations on how valuable this investment is as opposed to how much money we might possibly make. If we continue this theory as we get more granular with the work and identify specific “buckets” of risk that are threatening to derail our progress we can more accurately predict if we will be able to deliver our work on time. The buckets I have used to date are Technical, Business, Verification & Validation, Organization and Dependencies. Let’s see some of the questions I’ve asked for each of these risk drivers and then you can decide if you think that these drivers will help you track the progress of your project.

Technical:

• Do we have the technology in house already?
• Is this going to impact our current architecture?
• Do we have the appropriate skill set for the needed technology?

Business:

• Do we have clarity of scope?
• Do we understand the target market?
• Can we deliver on the intended business value?

Verification & Validation

• Do we know how we are going to test this work?
• Do we have sufficient information to be able to know when we should address this risk?

Organization

• Are the teams that need to work on this risk stable and fully staffed?
• Do we have the appropriate environments available to properly develop and test our work?

Dependency

• Is there anything that must be done outside of this team in order to deliver this work?
• If there is work required by others, do we know their lead times?

Answering these questions will provide us the information necessary to truly understand our progress and make key decisions around the work we are evaluating.