Back to News
Can you re-engineer core processes in just 48 hours?
Written by Louise Clark, | Posted in News on 5 February 2021
Well, as it turns out, we could!
Louise Clark, our Junior Service Designer reports on exactly how we tackled this challenge in this week’s post.
Why change?
As part of our business transformation and a drive to improve the quality of client service we offer, we rolled out a new service desk platform across the company. Many of our processes got switched to run through the new platform. However, Incident and Change Management, two of our most critical workflows, were still not as agile and efficient as we wanted. They were only partially digital, and we knew we could transform both to be better and more efficient.
Challenging ourselves to move quickly β
Late last year, I was responsible for facilitating a 2-day design sprint with a cross-functional team of 9, including key stakeholders from across the business. The purpose of the 48 hours was to run as fast as we could at the problem, and by getting the key people in one room, we were confident we could hit our goals.
The team π₯
Louise Ikonomides β Managing Director
Dom Rodwell β Product Director
Linda OβNeil β Operations Director
Harvey Gill β IT Director
Lynn Jackson β Compliance Manager
Jeanette Devine β Project Manager
Nick Day β Technical Architect
Dave Evans β Senior Software Engineer
Louise Clark β Junior Service Designer
Our toolkit π§°
We kicked off by agreeing on our toolkit. We focused on the software we were all familiar with and that we knew would work well together: Zendesk, Slack, Jira, and Coda. We supplemented this with some bespoke code (courtesy of Dave Evans, our lead software engineer – read more about this here) to help with seamless integration.
One of the great things about our office is (was!) the space we have dedicated to workshopping and collaboration. We have wall-to-wall whiteboards, post-its galore and enough filter coffee to fill a pool. As we all know too well, access to the office has been restricted for some time now, so we had to get creative about re-creating this environment remotely.
Again, we turned to our toolkit. I created a deck in Paste to outline the workshop structure and activities. Using Miro, I set-up individual workspaces alongside a shared collaborative space, to allow people to focus on just two workspaces across the sessions.
Finally, and perhaps most importantly, we established clear objectives for the session and the outputs to deliver across the two days.
Our objectives π₯
The core purpose of the workshop was to define the requirements for both Change and Incident Management. Further to this, we would build a working proof of concept to manage the process for each.
- Define the incident management workflow
- Define the workflow for one type of change
- Build working versions of both processes using existing tools
- Build a backlog for further development (and then implement quickly)
At Banking Works, we are big proponents of rapid prototyping and its effectiveness as a mechanism for quick, cheap, low-risk validation of ideas. By following this approach to design and build, we test assumptions at pace, discard ideas that fail and then iterate our way to the right solution.
Day One – confirming the problems to solve π΅οΈββοΈ
Generate
We kicked off with an exercise called Lightning Talks. Individuals took 5 minutes to share their primary considerations for Incident Management and Change Management. After the share-backs, we allowed 20 minutes for reviews and to identify the insights that overlapped: measuring standards and metrics, visibility of the incident lifecycle and links to continuous improvement.
One key takeout from Lightning Talks was the value gained from including a broad stakeholder group. Because each person interacts with the processes at different touch-points, we gained a holistic view of user experience.
After mapping all the user challenges, we used How Might We (HMW) to turn the challenges into design opportunities. HMW is a design-thinking approach used to reframe problems and encourage creative thinking.
Instead of saying: Our teams are too insular. You would write: How might we better connect our teams?
At this point, we separated the group into two teams and used Zoom breakout rooms. Each team had fifteen minutes to generate as many HMWs as possible.
Categorise
We reconvened to review and cluster HMWs that focused on the same topic. We split the HMWs across ten categories for Incidents and thirteen for Change Management. These included Source of truth, impact assessment, roles & responsibilities and communications.
Vote
When it came to voting, Miro’s in-built voting features came in very handy. It enabled me to select a voting area, allocate votes to the group and set a timer on the session. We allowed each person ten choices, spread across Change and Incident Management, and limited voting time to ten minutes.
Voting was probably the most challenging part of the day for the group. Both processes are complex, so choosing just ten votes was difficult and challenged the group to decide what was of real importance.
Mapping
Our final task of Day One was to begin the high-level mapping of the primary user touch-points across the Change and Incident Management processes.
Starting with Change Management, we mapped all the individual steps that make up the processes. Once mapped, we could begin to track the required functionality. Our lighting talks from the morning had also helped identify some of the main pain-points!
This mapping activity closed-off a productive day and helped us define scope, backlog and plan for day two.
Day Two – solving problems at pace. π
Backlog
Day two started with taking stock of completed work and revisiting our goals. Using our newly-defined maps, we broke each process into individual Design, Development, Documentation and Training tasks. We would continue to work through this backlog to deliver the live solution in the proceeding weeks.
Build
Next, we broke out into working groups. One group worked on the rules logic used to determine risk classification and priority definitions. This rules logic is integral to the success of the process. They also created a harm table and an impact & urgency matrix to guide the classifications.
Redacted version of the harm table:
The second group focused on the rapid prototyping of a proof of concept for the Change process using Zendesk, Jira and Coda.
By the end of the day, they had built out a working prototype, building digitally-native workflows on top of Zendesk tickets, creating dynamic documents in Coda and alerts and approval requests into Slack.
It just shows how much can be achieved in a short space of time if you focus on the right outcomes, modern digital collaboration tools and a bias towards taking action.
And now…
Two months into 2021, and under the weird time protractions induced by the pandemic, the workshop seems a very long time in the past! The rapid design and prototyping work we achieved across the two days provided a strong foundation for the work which has followed. Over two intense days, we fast-tracked design work that would have taken weeks or months under BAU constraints. The working group established has continued to meet regularly, and the communication approach initiated has rolled-out to other business projects.
Could your business be more agile?
Slow, cumbersome processes? Contact us to see how we can help you do the same.