Reflection – Learning Launch

Challenge

I am working for a big IT Consulting company. I’m part of a team which is responsible for dealing with  Enterprise Resource Planning (ERP) systems. Recently, I joined a project where our customer (a  fortune 500 corporation) migrated their ERP operations from a rather old software version to a very  newer software version. This planned migration took about one and a half years to complete, which  is the normal time frame for complex and large-scale IT transformations. Now, during all this time,  enhancement requests* from different business units of the client were naturally kept on hold. So,  the number of such requests went on increasing. After the successful go-live, few new members  including myself joined the team and our task was to effectively and efficiently deal with the pending  enhancement requests.   *An enhancement request is meant to improve some specific process from the systems perspective,  which eventually helps a business in saving time and money.

Selection

We decided to use the Learning Launch tool. The plan was to pick only a handful of requests from  the pool and drive those requests from their design to completion. The less number of requests  would ensure a short time frame. The idea behind it was to observe the process/stages to find out  what’s working and what’s causing issues. It would also let us know the challenges so that we can  possibly modify our approach while scaling out. Initially, there were some concerns from client side  but after holding a detailed discussion, we were able to convince them with our plan. We reckoned  that it was our best bet to learn from one short execution cycle, later do full scale implementation(s)  and keep the whole business with us. On this project, I was working in the capacity of IT Business  Analyst cum Functional Consultant.

Lecture Reference: https://www.coursera.org/learn/uva-darden-design-thinking  innovation/lecture/F04r6/learning-launch-tool

Application

We requested business champions of different business units (spanning across EU, APAC, LATAM,  MEA and Americas) to cherry-pick some requests which they wanted us to work on a priority basis.  We reviewed these requests and found that few of the requests were very complex in nature. Then,  we had a meeting with business champions and were able to convince them that deferring some of  these requests would be in everyone’s interest. Total pool of requests was 250+. The pool of requests  was not static but growing because client’s users across geographies were using the new ERP system  and discovering some new gaps or coming up with “should have” features or “Wish-Lists”. These  requests were vetted and then finally added to the pool by a separate team (client’s customer care).

We initially got about 22 requests to work upon but we mutually agreed to pick 16 requests for the  initial learning launch. Then, some quick follow-up discussions were held where we finalized the  design. After that, a team of four developers and a technical lead had two weeks to finish the work.  I was closely coordinating with the team and also testing the requirements as soon as the technical  lead was done with his review. This helped the team with timely inputs and initial feedback. With  this strategy, we entered the CRP (Conference Room Pilot) phase within three weeks of the kick-off  date. Then, much of the activities followed as they usually do in a SDLC i.e. User testing, issue

reporting and resolution and then full-fledged SIT. In SIT, apart from the requesters, other key users  were also invited to test the new functionalities. Some new issues were also logged and development  worked to resolve those issues as quickly as possible. Then, we reached the FAT phase and it was  mostly smooth. We migrated the new functionalities to client’s new production system in a little over  two months. It was well received by business champions and the work was greatly appreciated.

Now, to some of us, two months may sound like a lot of time but in ERP space, it is not. It’s because  the deliverables have to meet the established quality standards and they also have an impact on how  clients do their business. But from this ‘Learning Launch’, we learnt a lot of things. We actually ended  up making a SharePoint page for recording ‘Lessons Learnt’ and it was open to every team member.  This exercise equipped us with the right tools and provided us an opportunity to fine-tune our  strategy. It provided us with the confidence boost to deal with the remaining pool of requests. It  didn’t surprise us when we found out that some new requests have also been logged during this  intermediate time. This was going to be a constant stream of business for us and value-add for the  client’s operations. Based on the feedback from the concerned stakeholders, client was more than  convinced that it would be a worthy idea to make this a long term iterative project.

Insight

As mentioned above, we created a ‘Lessons Learnt’ page. There were several insights, a few of those  are listed below:

  Most of the requests were marked as ‘Global’ (impacting all business units) by client’s  customer care and hence they were developed as such. While in reality, some of these were  raised by a particular business unit and had no value-add for other business units. In fact,  there were two requests which caused issues for multiple business units. Subsequently, we  came up with a mechanism to control the applicability. So, learning was to ensure that the  requests were truly global.

  An associated learning was to conduct a detailed cost-benefit analysis, especially for the  requests which were applicable for a particular business unit only. This action was on client’s  customer care team.

  We realized that some of the third party system which were needed for testing the  developed requests were down or behaving erratically in the demo environments. We had  to do a lot of coordination with other vendors and client’s team to make it work. So, going  forward, we added a prerequisite related to the functioning of all third party system.

  There was a three-year-old request in the backlog and it made it to our Learning Launch list.  During CRP, business realized that they no longer want it since the associated operation has  changed since then. So, it was decided to have an additional review process in case the  request is more than one-year-old. Only after the review, requests would get picked up by  the development team.

Without the Learning launch, a full-scale project would have been so difficult for us to execute and             most likely marred with several problems!

Approach

In future, I would also like to deploy the Mind Mapping tool. In my line of work, Mind Mapping could  be useful during several stages of a project. While dealing with complex projects of a large scale, it  would be good to identify all the concerned stakeholders and bring them to a table (could be  virtual/video conferences for team placed in different geographies). For instance, Representatives  from business side could talk about different functional and technical aspects and the results they  are expecting from the project. Delivery team could talk about the challenges and risks that they  think could become a roadblock. In this manner, very interesting insights could be derived. These  insights could be categorized into several parts. It would allow creation of Action Lists, Mitigation  Plans, List of checkpoints et cetera. All the moving pieces would be visible to everyone and how are  they connected to each other and then how everything is related to one central vision of the project.  Use of whiteboards in these meetings would really aid in describing the flows, diagrams and ideas.

Many of the ‘Lessons learnt’ which I have described in the previous section could have been  discovered quite early, if we were to use the Mind Mapping approach. Going forward, my strategy  would be to use a combination of Mind Mapping and Learning Launch. I would also strive to shorten  the time frame of Learning Launch and appeal for increased participation from the stakeholders to  have additional inputs for innovation and optimum solution design.

