Developing an OS – Learning lunch

Challenge & Selection

The tool I applied is the learning lunch, which basically consists on testing a prototype of the  final product idea with the stakeholders in order to improve/modify the idea and reach the  best final product possible.

I work for a consultancy firm based in Barcelona and the challenge was to ensure that the OS  that was developing another IT partner for our client was perfectly adapted to the final user  needs. The OS basically consisted on an integrated system for a production company (stock  management; cost assignment to departments; sales rapport etc). The usual approach for this  type of projects basically consists on developing completely the system, with the IT  department involved on the OS development, before the final user sees it. Even though it’s  true that the technology department of the firm guides all the process, they are not the final  users, and their concerns don’t always coincide with the concerns of the final users, that’s why  we decided to apply something very similar to the concept of learning lunch: test the different  prototypes of the OS with the final users before the software is completely developed in order  to ensure that the final solution perfectly suits the user needs.

Application

I am going to describe briefly the way we structured the project using as example the main  department of the firm.

The first thing we did consisted in identifying which was going to be the final user of each one  of the different modules of the OS. The most important module was the production module,  since this was the department with the highest number of workers and the less willing to  adapt the way they were working to the system, so the system must fit perfectly the workers  main needs.

Secondly we selected a small group of representative workers among the production  department and we set up a meeting with them on a friendly environment (not on the small  meeting room where usually this meetings take place, but in the big conference room with  coffee, juice, tee and biscuits, where almost never go) and we let them try the different  functionalities (stock registration, registration of hours dedicated to each project etc) of the  system as it was developed in that moment. On that meeting, the workers identified many  things that weren’t working the way they expected to. For example: The registration of hours  required introducing the code of the project they were working on, and many times the  worker doesn’t know this code or, in the initial stages of the project, it has not even been  created.

After the meeting, we analyzed the comments and the feelings given for the workers,  translated them into possible solutions (in the registration of hour example, we proposed to  insert a searcher where the workers could find the code of the project by introducing words  related with the project itself) and we gave those solution to the partner that was developing  the OS.

Once the developer implemented the solution we proposed we met again with the workers  and repeated the whole process three times before reaching the optimal solution.

Insight

I thing that the way we conducted the project (showing the system to the workers even it  wasn’t completely developed and taking into account their concerns into the development  process) gave us the possibility to provide a final solution that fit the workers need almost  perfectly and needed minimum adjustments.  Because of that, the client was highly satisfied  with the OS he ended up with and we also saved the costs and time of introducing major  changes once the development is finalized (which usually are much higher).

I think that involving the stake holders on the early stages of the development is generally an  excellent way of improving the solution you’re selling to the client and preventing future (and  more expensive) costs.

Approach

I think that if we developed the OS we would try to take into account workers concerns even  before starting the development process, as we learned on the “what is” lectures. Probably if  we had done that, this solution would have been better designed from the beginning and we  wouldn’t have needed to readjust the prototypes so many times

