Movement from Scope to Benefits - Six Steps
Ramki Sitaraman
Engineering Partner at Thoughtworks | Healthcare, Energy Portfolio, Growth Enablement
I wanted to share a possible approach of shifting a culture which works on a predefined scope to a culture which looks at benefits/value. Many factors including relying on past success, allergy to ambiguity, long time habits of change resistance, politics develops the inertia to resist the move to a different culture. We need a concerted effort, empathetic to people that takes incremental steps towards a new culture. Having agile coaches, training, scrum models helps to get started but they give a new skin to the same animal- what we want is the animal to fly. Below, I have taken a 6 step process to move from one culture to another. Of course, easy on paper and takes tons of empathy & leadership to move them .
I have assumed a starting point of a situation where the scope has been already defined for a project and stakeholders are hell bent on defining scope upfront and doing it in scrum iterations ( what we call as Scrufall ) for multiple reasons. I have given alternatives at the end of these 6 steps to start in a different way. I have used the word ' project' a bit loosely here, an entity that includes product development also. Some of my fellow ThoughtWorkers will kill me for that, but I'm ok to resurrect again
Define any outcomes A good first step would be to introduce outcomes at the end of a scope definition. If it is difficult to steer the team to have outcomes at the start of a workshop, the agreeable practical thing would be define outcomes which defines success of the project/project. This helps to get a culture of measuring things and moving to outcomes rather than metrics around efficiency(plan %, #defects etc ). The outcomes could preferably a lead metric which can be measured. At this point of time, it is still scope based project, but scope with outcomes measured.
Revisit outcomes Once outcomes are defined, it needs to be measured and shown periodically for the stakeholders to see what has changed after a certain features have gone live. Even in cases where funding is done based on scope, it makes them tuned to look at outcomes and introduce a thought process to design around outcomes than scope. Doing this with cadence introduces a culture of defining and revisiting outcomes. As you might have guessed, the outcomes would have tanked if the scope did not help and there is a creative dissonance of a perspective of 'Certainty of future through a defined scope' with "measured outcomes showcasing telling a different story'
Changes to reflect better outcomes This is the toughest phase and change. Before this, you may want to have multiple 1-1s with your stakeholders, get their feedback, hopes, concerns to get a cohesive budget. A dialogue placing the different aspects into objectives & constraints is a useful discussion with smaller groups. Once this is done, you can define the new scope to get better outcomes - the previous steps ensures that the stakeholders are used to 'measures' and the current state of the project is not helping those measured.
Introduce Hypothesis By now, the stakeholders are used to measures, change in scope for better value of the measures. The world still expects the certainty of rules of gravity. Once we go through the previous steps multiple times and get success, it is time to have a team reflection of what is the least that can be done to avoid rework & be certain of outcomes. If we can facilitate this session with stakeholders, we get to a point where it leads to defining hypothesis- a scope that is based on assumptions to deliver value and we define multiple such hypothesis to ensure one of them will lead to a valuable scope.
Move to Customer outcomes, again With a set of stakeholders who are used to outcomes, the next big paradigm comes to shift the outcomes to customer space. We define the outcomes in terms of what value a scope creates for customer and measure that. This is probably the toughest because we have to look at the lens without, outside-in and think from customer perspective. There is always a push to define exact solutions, short cuts that helps internal business metrics but long term it kills the product, makes the product less responsive to customer needs as the product did not go through a journey of customer outcomes early on. Once you define the customer outcomes, repeat the entire process again- but this time the friction will be less on the process but on defining the customer outcomes.
Start with Customer Outcomes The final step is a great leap ahead. One, where we start with defining the goals in terms of customer outcomes and breaking them into next set of outcomes , hypothesis. The scope is never formulated at the start, it is the outcomes that are defined first followed by the method and the constituents of what will take to meet those outcomes. Like, how it is done in EDGE using LVT technique. This requires extreme flexibility in the organization to play around with budgets, focus on customer outcomes, periodically measuring and changing course based on that.
Please let me know if there are any comments.