How to: WOOP Your Project / Process Success

Welcome to the series of How To:Quality. Your 3 min guide on how Quality Professionals address various business needs to drive Improvement and Governance.

Quality Professionals, regardless of the sector they work in, strive to help businesses achieve their strategic objectives. They do this in various ways: be it deploying governance frameworks, implementing improvement strategies, or delivering assurance programmes.

This month, I bring you four steps you can follow to ensure you can increase your chances of success when implementing a change programme. Many business leaders are good at scenario planning, and Quality Professionals have plenty of tools in their tool box that support initiatives to succeed.

How to: Quality

Working to achieve a desirable state for a process or project is an ongoing approach all business leaders strive to achieve. So how do you plan for success while considering risks and opportunities. There are plenty of approaches that could guide you through the process. In the post, I will take you through the WOOP approach as referenced in The Theory and Practice of Change Management by John Hayes (2018, 5th edition).

Change Management is the ability to transform or convert something from a current state to a new desired state. Achieving this newly desired state has to be considered and planned for. WOOP tool stands for wish, outcome, obstacle and plan and follow it in this order:

  1. Wish
  2. Outcome
  3. Obstacle
  4. Plan

1. Wish

This is where you are set out your desired new state. For example, if you are working on improving a process performance, you can set out your wish with your team by stating that ’we wish to respond to all new queries promptly and not have our internal customers chase for their requests to be answered’

2. Outcome

In this stage, you refine your wish to make it a bit more achievable. Generally speaking you achieve this if you have a bit more factual information that would help you make a fact-based decision, or choice.

Say for example you have a full year worth of insights on tickets and requests, you know how long it takes the team to provide the first response, and you also can see how many times did your internal customers have to chase for their query to be answered. This data helped you and your team say: we wish to respond to all new queries within 48 hours of receiving the request. This will aim to increase our internal customer satisfaction and help provide a more prompt approach to their requests.’ As you can see, the wish is now a bit more refined and has some achievable metrics you can work of.

3. Obstacle

If you a project manager or work in project environments, you know that operating without outlining your assumptions and risks is not sustainable. Whether you have a process for risk management, or whether you work of scenario planning, whatever your approach is, it fits into this step.

Hayes states in his book that a good approach to follow is to full in the blanks:

If/When [insert obstacle], I will [insert action to overcome obstacle]

The Theory and Practice of Change Management, Hayes (2018)

💡Listing your scenarios in the above If/when, then approach is not sufficient on it is own. Quality Professionals always work with PDCA (plan, do, check, act) or PDSA (plan, do, study, act) approach. Once your scenario planning is done, make sure you and your team review the above and assess that the responses will continue to support the outcome you defined earlier.

4. Plan

This is your final stage before you proceed with your implementation. It is the stage that includes all your action items, your tasks, your change champions who will help you implement, the systems you need, and the monitoring of the progress. This is what you do to press Go for the team.

Hayes shares 8 principles which impact the dynamics of the group and influence the design of this change management approach. It is based on a research done by Cartwright in 1951. I will only share one principle that I found extremely useful:

Principle 8: Applying changes to one part of your entire operating system is likely to cause strain on other parts of your system. I find this very useful because it reminds you to consider how to plan your implementation and changes, and whether these changes will cause strain or in fact produce benefits and efficiencies in other parts of the business.

If you enjoyed this How To scenario, why not follow me for other scenarios dropping straight into your inbox 👇

If you would like to see a particular topic covered in this series, please get in touch and let me know the topic or scenario, and I will do my best to help. You can get in touch on your preferred platform 👇


Discover more from the Quality strategy

Subscribe to get the latest posts sent to your email.


Comments

Leave a comment

Discover more from the Quality strategy

Subscribe now to keep reading and get access to the full archive.

Continue reading