In our Transformation practice, we are helping organizations change how they plan and execute work to be done. We help them shift from a focus on outputs to prioritizing outcomesand delivering business value. As the product practice lead, I help our clients on the develop-the-planparts of Transformation.
Only The Starting Point
The starting point of developing a plan is to focus on outcomes—benefits for the business—and then to determine which things could be built which provide value to users and customers, in ways which contribute to the outcomes for the business. In the world of “valuable, desirable, and feasible,” this is the combination of valuable and desirable.
But that’s only the starting point. Every plan has implicit risk in it, and the first area of focus is on the business risk—the risk that these “things” are neither valuable nor desirable. The next step in developing a plan is to understand how much risk is in the planand to make the risks explicit.
I was working with a client team who had previously made a set of commitments to deliver a set of functionality to stakeholders for the rest of the year. This team had been operating in an “output oriented” mode, committing to a set of deliverables by a given date. Fixed scope.Fixed schedule.
The first steps in the journey of Transformation,for LeadingAgile clients,is to move from the heroic-operations mode of asking teams to meet changing requirements to fixed deadlines (the upper left quadrant of dealing with emergent requirements in an organization which values predictability) to the lower left “standard” model of predictability. Stabilizing the system of delivery, such that the team is able to make and meet commitments.
There is a subtle Transformation which takes place here too. The team must acquire the ability to make and meet commitments on the outputs they are delivering. This is necessary, but not sufficient. The team must also Transform to develop the ability to be outcome oriented, and that means making and meeting commitments with respect to outcomes.
- StepOne:is to predictably deliver the things you said you will deliver. It doesn’tmatter if those things are valuable,or desirable. They only have to be feasible. Of course,if you’re wasting the team’s time and asking them to build things which are unimportant, then you have a different problem.
- StepTwo:is to predictably deliver the outcomes you intended to deliver when you chose the “things” to be delivered.
So, What Do You Do?
This is where that giant business risk comes in. What if the things you choose to build don’t deliver the outcomes you intended? What do you do?
More importantly, what do you do ahead of time? You de-risk the plan. By making those implicit risks explicit. By forming hypotheses and testing them before you commit the team, the time, and the resources to building stuff. But how do you know what to test? You test what is most important to test, those things which are most likely to be wrong, and which would most jeopardize your outcomes if they’re wrong.
You estimate the size of the damage of being wrong the same way you estimate the value of being right. Your business case, or estimate, or wild-ass guess of value. Most people would then combine this with their confidence in the mechanisms of value delivery—that the things actually work.
Most people would be wrong.“I don’t care how confident you are. Your level of confidence doesn’t matter.”
The team described one of the outputs they had committed to deliver, and explained why they believed this “thing” was both desirable to the users and valuable to the business. Something seemed wrong to me, and this was my first workshop with the team and exposure to their plan, so I asked “how confident are you that this thing will deliver the desired outcome?”
The team responded with complete agreement – “80% confident.”
I then showed them the following confidence rubric with a 1 to 5 “confidence” scale which I developed while working with another client. Along with some chuckles, the room was filled with only “zero” and “one” responses.
How Justified is YourConfidence?
5 – hypothesis based on extensive research
4 – extrapolation from correlated data
3 – inference from related data
2 – “expert” intuition based on domain knowledge
1 – speculation: “I imagine / expect this will work”
0 – “Let’s try something and see if it works”
The rubric is a range from “no reason at all to be confident (0)” to “very good reason to be confident (5).” The team now assesses the justification of confidence of all their hypothesized methods of delivering value, and is well on the way to making and meeting commitments in terms of outcomes and not just outputs.
Our early goal to make and meet commitments in terms of outcomes is sensitive to the risk of building the wrong things. When the team delivers the wrong things on time, they fail to deliver the outcomes. They fail to deliver valueto the business. To identify where the greatest risk is, in terms of delivering value, we need to combine both the greatest impact of being wrong with the greatest likelihood of being wrong.
Likelihood of being wrong correlates with the justification for your confidence, not with your actual confidence. Use this rubric to better identify the risks to be tested. Your plan will be better.