Stories of Services I offer based on my skill-set : Design Sprint Master

Design Sprint Master

This type of sprint is used to solve a costly embedded internal business problem in 1 to 4 weeks. Every organization has annoying internal problems turn into a habit that stubbornly resists a solution, eating away at value creation and morale.

E.g. : Benefits of the Problem Resolution Sprint Project

  • Led by a neutral external sprint master
  • Concrete as it focuses on solving the problem of the internal customer
  • 100 % collaborative, drawing its legitimacy by actively involving all the stakeholders needed to make it work
  • Tested in the form of a Minimum Viable Product (service, product or app) by users and those who deliver it to make sure it works
  • Launched by decision of a business leader who wants it to work

Fun story illustrating 4 week Sprint Master role to solve a sticky internal value-destroying problem

CFO office Story

The 10-People Finance department of a Business Unit of one of France’s biggest corporations couldn’t do the job it is paid to do because it was spending over 50 % of its time answering internal queries : “have you signed up my new supplier”, “have you paid this supplier”, “finished preparing my tender “ …

We put together a small team to understand where the problem was coming from, how it was being addressed, and if a simple solution could be imagined, tested and put in place within 1 to 4 weeks to free the team while answering internal teams’ queries satisfactorily.

It rapidly became obvious that 80 % of the business-line queries were answered by the team by finding the information in a select number of pages in the company’s ERP.

A solution was (legally) hacked (put together rapidly) to enable users to access just the relevant section of the ERP.

A test was set with a a selection of internal users who had frequently addressed queries to the CFO office team asking them to turn to the hacked interface and explaining how this could be done. The riskiest aspects were identified and KPis set up to decide what a successful success ratio would be for the users to validate the solution.

The solution was a success, initially addressing 70 % of queries to user’s satisfaction. The solution was carefully communicated to all internal users with the proviso that they could call if they could demonstrate the solution clearly didn’t deliver the required answer. The remaining 30 % was “plugged” over the following 6 months.

The hardest (or nicest) part of the story was to put to rest the original idea of the CFO office team which had been to design a Bot from scratch to solve the same problem.