Reflection – Learning Launch

Challenge:

I am part of a global Finance team and my challenge relates to a large system implementation  project.  My organisation is implementing a new system that will transform the end to end source to  pay process, impacting a significant number of different users across the world.  The scope of the  project is very broad impacting 8 countries and the operations process of a number of different  departments, such as Commercial, IT and Finance.  My activities on this project include learning  about new system functionality, assessing its applicability for my Company, defining global policy  changes in accordance with the agreed deadlines.  As a project team we need to make sure that we  deliver a tool with associated processes that bring improvement to the user experience of procure to  pay and delivers benefits in terms of additional functionality, ease of use and efficiency.  I am  working in the finance stream with a small number of people that need to design and deliver the  finance potions of this Project in the next 6 months.  The challenge is how to deliver the design on a  number of processes that will meet user expectations in a short time frame with tight resources.

Selection:

Design thinking is being used as part of the wider project but in terms of how we approach the  Finance workstream I have chosen the Learning Launch tool.  This is a tool that facilitates  experimentation, allowing ideas and prototypes to be tested quickly on a small scale.  This provides  learnings that allows improvement to be made to the idea and hypothesis.  I selected this for my  challenge is it provides an opportunity to experiment, test, improve and move forward to a more  improved and user centric prototype or model.    Application:

We applied the Learning Launch tool during the testing phase of the project

At the start of the project there were a lot of ideas and potential functionality that we could use and  a set of assumptions/hypotheses about what we thought users wanted and would find useful in the  day to day work.  We needed to find a way to match the functionality to the hypotheses of user  needs and want.  There was not an easy way to decide what would best suit our business and the  users and how to set up the functionality and process appropriately.  We therefore decided to take  an experimentation and prototyping approach to the testing by setting up 3 prototype phases.  We  decided on this approach so that we could initially break the tasks and work into smaller chunks and  make some quick decisions in terms of initial processes to use, test the hypotheses and design.  We  were then able to configure these based on our understanding and hypotheses of user needs, test  them and learn, pivot and tweak the configuration and process to get us closer to a best practice and  user centric process.  As we progressed through the prototyping we added more processes and also  more users into the testing so that we could test their expectations and gain their learnings, allowing  us to incorporate wider perspectives into the design of the process.  Each prototype was like a mini  go live as new users became involved in the tool design.

This process worked well although the only challenge remained how we could keep track of the  learnings and make sure we could adjust the process and configuration in time for the next  prototyping session.

Insight:

By applying the tool I feel we were able to better design functionality for end user purposes.  By  testing the hypotheses and expectations we had about user needs we have ended up with a more  robust system design that will actually meet their needs rather than meeting the needs as we  though they might be.  After the prototyping we removed processes that were not important to  users and redesigned others that did not meet their expectations following feedback.  For other  processes it was positive confirmation that we were on the right path and our hypotheses were  correct.  By walking in the shoes of the user and involving them to test our design we feel confident  that we will go live with a user centric tool that will meet their needs with no surprises.  Without  doing this and having the design thinking mindset I think we may have designed processes based on  an incorrect set of assumptions and gone live without testing it on the user base first.  This would  have led to a tool that did not have users at the forefront, did not meet their needs and would have  surprised us on go live with negative feedback and rework after the fact.

One of the harder things to keep at the forefront of my mind was that we never failed during the  prototype phases, we were merely learning, pivoting and improving.  Just because a hypotheses was  proved wrong didn’t mean we had failed, it provided an opportunity for us to actually meet  expectations where we might not have otherwise done so.

Approach:

Next time I use this approach I would try to get the learnings quicker and “fail” faster.  We had 3  prototype phases and were perhaps too reluctant or just learning and feeling out the process during  prototype 1.  If we had tested more processes and had more users involved earlier I think we could  have spaced out the workload and gained insights quicker allowing ourselves more time for  redesign.  If we had packed more into Prototype 1 and 2 we would have had the learnings and not  had to rely so heavily on prototype 3 when the deadlines were tighter.

I would also take the learning of this approach forward to any future system projects to make sure  we can gain the insights from users and test our thinking out before going ahead with a solution that  we think is right.

