Quote from Mark Twain - too much whiskey is barely enough

Can you prove it?

Organizations and team embrace a framework or technique for a purpose. That purpose is generally to address a real or perceived problem.  When you get very specific, each change is done a different reason.  When teams or organizations are asked whether they attained their goals, solved the problems they intended or realized the promised benefits, very few have gathered more than a handful of success stories before losing focus and moving to the next big thing. Unless you can answer whether the framework or technique delivered tangible value,  leaders will be reluctant to spend money on changes.  Best practices are a point in case.  Best practices are, by definition, practices that some have found useful (or at least that someone has professed are useful).  Every process improvement and/or best practice adoption that is not legally mandated needs to follow the following high-level feedback loop.

  1. Decide why you are making the change and what the outcome of the change will be in tangible terms. Developing a solid reason for why you are making a change may sound like a trivial step, however, the rationale will often directly impact the passion for making the change. People pursue survival changes with a lot more vigor than incremental quality of life improvements.
  2. Develop a hypothesis of why the change you are making will satisfy the rationale for the change.  Changes that actually work rarely are the outcome of magical thinking or dumb luck. If there is no logical reason the change you are proposing will have an impact you are very likely wasting time and money.  Use the scientific method!
  3. Set SMART goals that will be used to track and evaluate the change.  As a reminder, SMART stands for specific, measurable, achievable, relevant, and time-bound.  The goals should cover the journey and outcome based on the hypothesis crafted in step 2.
  4. Benchmark the process you are changing.  Consider collecting data specific to the change and data to evaluate the impact on the overall system.
  5. Make the change.  You still have to make and support the change.  Your journey measures will be helpful to make sure that the change is being implemented well.
  6. Collect the data to show the impact (compared to the benchmark developed in step 4) for several cycles after the change has been implemented.
  7. Use the data you collect to tune the process. Pick a feedback loop and tune the process.  Rarely are major changes perfect right out of the box.  Using feedback to tune the process helps to ingrain the change and to make sure it is delivering value.
  8. Report your findings.  Share the impact with everyone involved.  Positive data will help to reinforce the change and will help sell the next round of changes.  In scenarios where the change doesn’t deliver value reporting reinforces the principle of transparency.  If a change doesn’t deliver, don’t double down on a failure; revert back and try something else.

People make changes to how they work on a daily basis.  Some changes are minor and, in some cases, are not worth developing a full-scale proof of impact. For example, deciding on whether to order grilled tofu or pizza for the team lunch doesn’t require a proof of impact.  Some large-scale changes like adopting Scrum, Kanban or DevOps require a great deal of time, focus, and money. It makes sense to be able to answer the question of whether you got what we thought you would get with something more substantive than a shrug.

Next an example

Advertisements