The story of the master workflow - before and after

As a Greenlight Consultant I am extremely proud of what we can achieve as a team for the benefit of our Clients. I like to reflect on some of the changes I have been involved in since starting with here and one example that stands out for me is that of the Master Workflow. This blog presents a before and after story of the Master Workflow.

Symptoms: People & the Process

Delivering change across a blend of people, process and technology is what we do. So is fixing business problems. In this instance we walked into the Client and witnessed what we now understand as symptoms – a defective process, frustrated people, stressed out teams, little or no reporting, undefined roles and responsibilities and what seemed like an endless stream of issues. Everything was broken.

In a nutshell, our mission was to review, design (improve), implement and embed an end-to-end process. Much like an iceberg, on the surface this appeared to be a relatively straightforward process improvement piece… streamlining people, process and, well, technology. That’s where the straightforwardness ends and the Story of the Master Workflow begins…

Root Cause: Facing the Master Workflow

Remember those puzzle games you used to get in magazines where you have to choose the right path to reach the end goal? But instead of being one clear path to the goal there were multiple paths; unorganised, tangled and just one big mess really. The Master Workflow resembled exactly that.

Greenlight Blog | Master Workflow | Jersey, Guernsey, Channel Islands

For the purpose of context, The Master Workflow existed in the core operating system outlining the workflows for managing the process. It provided a back-end view of what was built in the system and how it would work in principle. Essentially the Master Workflow reflected how confused and disordered the process had become.

I will never forget how it felt when the system expert turned his screen to show us what we now know was the Master Workflow. Even he was taken aback! Panic and a slight feeling of dread built inside me whilst on the outside I remained calm and attempted to think rationally. It was hard.
How did it get so bad? Why is it like this? What happened? How can we fix this? What is the real problem here? So many questions and very little time to turn this around…

The “Journey” (Approach)

So what did we do about it? We followed seven simple steps to turn the Master Workflow into logical and organised workflows with clear worksteps, owners and triggers.

Step 1: Investigate

Before work got underway we spent some time investigating the current state of affairs, understanding exactly what was going on and what the Master Workflow was telling us. We referred to the version control – who is/was responsible for making it this way? What were their reasons? How big is the problem? Without this initial detective work I truly believe we would still be sat their attempting to tackle this problem! As they say, you have to start from somewhere.

Step 2: Create a Vision

It is very tempting to get caught up in (often unnecessary) detail. I truly believe that before any in-depth analysis takes place it is paramount there is a clear vision in place to support your mission. Despite the name, a vision can help ground people by keeping the reason(s) for the change in mind. In this case I used to carry around a screenshot of the Master Workflow to provide that much needed context. The vision for this project: Simplify, standardise and rationalise.

Step 3: Requirements & System Capability

Once the vision was communicated and clear we moved on to working with the workstream leads to understand their requirements and simultaneously what the system was capable of doing through a series of workshops. At this stage the challenge is about being realistic about needs vs wants. Yes it would be fantastic to have an all singing, all dancing system. But the purpose of the project is to simplify, standardise and rationalise, therefore the requirements should reflect this.

Step 4: Build, Test, Check, Repeat

Over the next couple of weeks our attention turned to building in the demo environment and testing the workflows defined in the previous workshops. Working with the system specialist we used the requirements specification to test and validate each element. Often at this stage key stakeholders are left out of testing. I disagree with this. Regular updates and visibility of the build in the test environment is key to ensuring stakeholders are aligned to the vision, the overall project aims and for them to check their requirements are being met.

Step 5: Roll back planning (just in case!)

As a realist (and occasional optimist) it must be considered that things don’t always go to plan hence why roll back planning is an absolute must! A roll back plan involves outlining some steps to take when go-live doesn’t go to plan. For example if the system changes involve automated processes, the roll back plan could involve teams returning to manual processing.

Step 6: Train the trainer(s)

With direction from the system expert and development of training guides the workstream leads were trained to be trainers. Not only did this empower the workstream leads, it ensured that each team were aligned and consistent in their approach in using the system. Well attended by their teams, the sessions were successful and one to one sessions offered where individuals needed that extra support. This is key to encouraging ownership of the process going forward. This also allows for the teams to learn together. This helps in the future by allowing them to support each other.

Step 7: Go-live & ongoing support

System changes were implemented overnight. As a team we met relatively early in the morning to personally test the changes before their teams even woke up to catch any bugs & action any fixes before anyone noticed. Enthused with a newfound sense of ownership and involvement in the process the team were prepared, floor walkers assigned and procedures up to date and ready to go.  From this point on the emphasis was on embedding the changes and providing support where needed.

Benefits of the Master Workflow

Waving to the system expert as he left for the airport I thought about the newly formed team and everyone who played a part along the way I remember feeling a sense of pride. Not only did we treat the symptoms, we solved the root cause of the problem resulting in a simplified, standardised, rationalised and most importantly fit for purpose Master Workflow.

Greenlight Blog | Master Workflow | Jersey, Guernsey, Channel Islands

As a result of this engagement the Client has realised (and continues to realise) the following benefits;

  • Logical order and flow of information through the process
  • Clarity around process roles and responsibilities
  • Accountability at each stage of the process
  • Development of supporting processes for maintenance and upkeep
  • Consistent processes, procedures and training
  • Working as a team as opposed to individualistically  
  • Improved reporting, greater visibility of performance and the ability to measure success

Ultimately the process was repaired, the people regrouped and the system rationalised to ensure the change was a success.

The End

The Story of the Master Workflow is a favourite of mine. One reason for this is that I was fortunate enough to be involved in what I perceive to be an extremely successful and rewarding change across people, process and technology. Secondly because the change was deeper than that. The change delivered with the Client was cultural and really felt by the organisation and particularly by those involved.

I hope you enjoyed reading about one of my favourite engagements, have you had any similar experiences? Or want to share your favourite change-related story?


Greenlight Blog | Kimberley Marriott | Jersey, Guernsey, Channel Islands

About the Author

Kimberley was the first of our Graduates and boy has she excelled. She has become a true all round business analyst and project manager, delivering large scale change and handling complex business requirements.

View Kimberley's profile