Example Reflection – Learning Launch

Challenge

I am an intern on the Structural Analysis Department on a company in my town. Currently,  my department is facing a problem with the software we buy to do our job (this software  belongs to an external company). For matters of confidentiality, let´s call this software  “Namsys”. Since the external company charges Namsys by its time of use, a problem that  has emerged is that the workers of my company sometimes forget to close Namsys when  they are not using it (when they go to eat, for example) and, because of this, on these  situations, the costs of the use of Namsys raise even if it is not being used, since it is still  opened. My team calls this extra costs “idle costs” since they are being produced when  Namsys is idle, or not being used. Because of this, the challenge I was given was to reduce  the idle time of Namsys to reduce the extra costs this provoked.

Selection

When I was called for this project, the initial steps of the process were already taken: they  already had the data that was needed and a brainstorming process took place after that.  After this, we decided to test one of the solutions: to create an internal software that detects  when Namsys is idle and that closes it automatically when this happens. For this, we used  the learning launching tool. To make it short, a learning launch is a fast and cheap  experiment to test an idea and to prove a hypothesis. Our goal with this idea was to see if it  was the right solution and, if not, to learn from it to deliver something better.

Application

For this first learning launch, the first thing my team did was a hypothesis that we wanted to  prove with the release of the software we were making. This hypothesis was made from the  gathered data on the previous steps on the project. We wanted to satisfy our stakeholder´s  needs and to solve their problems. When going deep into this obtained data, my team  realized that the software should not only be able to close Namsys when it was idle, but it  should also have a user-friendly interface for the workers and an autosave function for the  work they don´t save when they leave the software idle, for example. Also, the managers  wanted to have knowledge of the time each of their workers was using Namsys and how  much of this time was idle. All of these things, among others, were gathered together to form  a design criteria statement in which we were based on to make our first prototype.

When we launched the first prototype, the principal thing we were concerned about was that  the software was functioning the way it should. When we prove it was working the way we  want it to, we then focused on the users (the workers of the company) and on their  managers. We were concurrently asking them how they were feeling about the software.  This was very useful since we received very useful feedback that allowed us to work on  several more iterations that served as subsequent learning launches. The speed and  efficiency of these iterations was beneficial for the team and the company in general. This  process lasted about one month until we finally reached a functional software with which  everyone felt comfortable with.

Insight

As said before, when releasing the first learning launch, the team had some interviews and  talks with the workers and the managers that were involved in this project, which helped us  to receive useful feedback that was implemented on successive learning launches. From  these interactions, my team was able to identify new insights that were not identified at the  beginning, which helped us to improve our software. With these insights, modifications from  the user interface to the data displayed to the managers were made in a way that the product  was more useful and comfortable for everyone. In fact, with these insights, the team learned  the right ways to display data and to make a friendly user interface, for example. Small  details were important. I learned, with this process, that even if at the beginning we analyze  data, that doesn´t mean we know it all at that stage; we can learn during the execution and  we can get new insights as we make prototypes of our idea.

Approach

Since the internal software that was made by my team had to accomplish several tasks that  were identified on the first stages, our team focused on doing everything for the first iteration;  that means, we tried to cover everything that the project needed on the first learning launch  hoping there was nothing to correct and that everything would go perfectly. However, as  stated before, this did not occur, and we had to iterate until we got to a final product. I  honestly think that was a mistake we made and something I will do differently for other  projects. The fact that we made a big project at first made us do big changes that took  several time after the first iteration. On this course I learned that it is better to do small  learning launches that are fast and cheap, so maybe the best thing we could have done  here was to divide the project in some logical parts and release it one after another,  correcting what was needed. This could have saved us a lot of time and resources. This is  something I learned on this course and I experienced during this project.


Example Reflection – Learning Launch Challenge I am an intern on the Structural Analysis Department on a company in my town . Currently , my department is facing a problem with the software we buy to do our job ( this software belongs to an external company ) . For matters of confidentiality , let´s call this software “ Namsys ” . Since the external company charges Namsys by its time of use , a problem that has emerged is that the workers of my company sometimes forget to close Namsys when they are not using it ( when they go to eat , for example ) and , because of this , on these situations , the costs of the use of Namsys raise even if it is not being used , since it is still opened . My team calls this extra costs “ idle costs ” since they are being produced when Namsys is idle , or not being used . Because of this , the challenge I was given was to reduce the idle time of Namsys to reduce the extra costs this provoked . Selection When I was called for this project , the initial steps of the process were already taken : they already had the data that was needed and a brainstorming process took place after that . After this , we decided to test one of the solutions : to create an internal software that detects when Namsys is idle and that closes it automatically when this happens . For this , we used the learning launching tool . To make it short , a learning launch is a fast and cheap experiment to test an idea and to prove a hypothesis . Our goal with this idea was to see if it was the right solution and , if not , to learn from it to deliver something better . Application For this first learning launch , the first thing my team did was a hypothesis that we wanted to prove with the release of the software we were making . This hypothesis was made from the gathered data on the previous steps on the project . We wanted to satisfy our stakeholder´s needs and to solve their problems . When going deep into this obtained data , my team realized that the software should not only be able to close Namsys when it was idle , but it should also have a user - friendly interface for the workers and an autosave function for the work they don´t save when they leave the software idle , for example . Also , the managers wanted to have knowledge of the time each of their workers was using Namsys and how much of this time was idle . All of these things , among others , were gathered together to form a design criteria statement in which we were based on to make our first prototype . When we launched the first prototype , the principal thing we were concerned about was that the software was functioning the way it should . When we prove it was working the way we want it to , we then focused on the users ( the workers of the company ) and on their managers . We were concurrently asking them how they were feeling about the software . This was very useful since we received very useful feedback that allowed us to work on several more iterations that served as subsequent learning launches . The speed and efficiency of these iterations was beneficial for the team and the company in general . This process lasted about one month until we finally reached a functional software with which everyone felt comfortable with . Insight As said before , when releasing the first learning launch , the team had some interviews and talks with the workers and the managers that were involved in this project , which helped us to receive useful feedback that was implemented on successive learning launches . From these interactions , my team was able to identify new insights that were not identified at the beginning , which helped us to improve our software . With these insights , modifications from the user interface to the data displayed to the managers were made in a way that the product was more useful and comfortable for everyone . In fact , with these insights , the team learned the right ways to display data and to make a friendly user interface , for example . Small details were important . I learned , with this process , that even if at the beginning we analyze data , that doesn´t mean we know it all at that stage ; we can learn during the execution and we can get new insights as we make prototypes of our idea . Approach Since the internal software that was made by my team had to accomplish several tasks that were identified on the first stages , our team focused on doing everything for the first iteration ; that means , we tried to cover everything that the project needed on the first learning launch hoping there was nothing to correct and that everything would go perfectly . However , as stated before , this did not occur , and we had to iterate until we got to a final product . I honestly think that was a mistake we made and something I will do differently for other projects . The fact that we made a big project at first made us do big changes that took several time after the first iteration . On this course I learned that it is better to do small learning launches that are fast and cheap , so maybe the best thing we could have done here was to divide the project in some logical parts and release it one after another , correcting what was needed . This could have saved us a lot of time and resources . This is something I learned on this course and I experienced during this project .