Example Reflection – Learning Launch

Challenge

My organization is in software development industry, specialized in enterprise content management.

Our projects consist of implementing document management systems according to business needs

and rules of our customers. For that, we use our document management platform, which is capable

of defining different workflows for specific types of documents.

We had a following challenge -

•  The client was not having internal resources (key users) capable of defining

workflows for the documentation.

•  There were no clearly defined business rules for the documentation management at

the beginning of the project.

•  The documentation handling was manual or through e-mails with lots of back-and-

forth between employees.

•  In addition, it was important to have a quick win in order to boost the confidence of

the client's employees involved in the project.

Selection

Client's business processes were unclear but it was not the matter of defining them but rather

discovering them. Processes were somewhat in effect as there were defined business needs and

employees' responsibilities.

One of the options was visualization that would help stakeholders to see the workflows and the

effects they have on the documentation being handled (lifecycle states, approvals/rejections,

attachments, electronic vs hardcopies etc.).

However, as the stakeholders were previously involved in similar activities with other consultants

and with unsatisfying results, we concluded that the risk of saturation is too high and we should skip

as soon as possible to the phase where we can show actual system, even with flaws.

Furthermore, as we already had a document management platform which was in itself a minimum

viable product it was was economical to go directly to learning launch.

Application

For a learning lunch, we set up the system where users could send documents between each other

without any business rules as if they were using e-mail. The only rules were following:

•  All documents must go through document management system (no "hardcopy workflow");

•  When users receives document that is not intended for him/her forwarding to the colleague

who is likely the right one to handle it is preferred to returning it back to the sender and

•  All users should process documents swiftly (as we have not implemented any escalation

scheme to deal with documents not processed on time).

The last person in the process (the one who was proclaiming document effective or send it to

archive) was also in charge of defining the type of document. We assumed that this would be the

person who would certainly be able to classify the document by type.

As the documents in the system were reaching the last life cycle phase (archive), our consultants

analyzed logs to see how the documents were circulating.

This way we were able to determine optimal paths (workflows) for different types of documents

through experience.

In future learning launches we introduced document types with workflows used from the beginning

of the process (scanning) and different roles for users.

In some cases it was not possible to timely define the path for some documents so users had to

reverse to face-to-face or phone calls to determine what should be done with the document but it

was also helpful for us as it has pointed to important exceptions.

Insight

Using the learning launching tool, we achieved the following -

•  Quick win that boosted the morale of the project participants

•  Showed that it was feasible to process all document through document management

system

•  Gained data for sizing different aspects of the project (resources for scanning, need

for mobile solution etc.)

•  Defined participants who can best contribute to the project.

•  At the beginning we had some expectations of how will the workflows turn out since

we had experience with the similar customers - the learning lunch confirmed some of

those and highlighted the specifics for this client.

Approach

We were very satisfied with learning lunch as a tool in this particular project but we tried not to use it

as a main tool in future projects as it is best suited for situations where we cannot gain sufficient

insight from other tools.

It required more technical resources than some other design-thinking tool would use.

In one similar situation when we had to determine workflows but could not use learning lunch we

used modified mind mapping - users were passing "play" documents of different types between each

other around the conference table and we were writing the names of the participants in the process

on each document (post it). This provide for a shallower insight but achieved in a shorter time and

with less resources.


Example Reflection – Learning Launch Challenge My organization is in software development industry , specialized in enterprise content management . Our projects consist of implementing document management systems according to business needs and rules of our customers . For that , we use our document management platform , which is capable of defining different workflows for specific types of documents . We had a following challenge - • The client was not having internal resources ( key users ) capable of defining workflows for the documentation . • There were no clearly defined business rules for the documentation management at the beginning of the project . • The documentation handling was manual or through e - mails with lots of back - and- forth between employees . • In addition , it was important to have a quick win in order to boost the confidence of the client 's employees involved in the project . Selection Client 's business processes were unclear but it was not the matter of defining them but rather discovering them . Processes were somewhat in effect as there were defined business needs and employees ' responsibilities . One of the options was visualization that would help stakeholders to see the workflows and the effects they have on the documentation being handled ( lifecycle states , approvals / rejections , attachments , electronic vs hardcopies etc . ) . However , as the stakeholders were previously involved in similar activities with other consultants and with unsatisfying results , we concluded that the risk of saturation is too high and we should skip as soon as possible to the phase where we can show actual system , even with flaws . Furthermore , as we already had a document management platform which was in itself a minimum viable product it was was economical to go directly to learning launch . Application For a learning lunch , we set up the system where users could send documents between each other without any business rules as if they were using e - mail . The only rules were following : • All documents must go through document management system ( no " hardcopy workflow " ) ; • When users receives document that is not intended for him / her forwarding to the colleague who is likely the right one to handle it is preferred to returning it back to the sender and • All users should process documents swiftly ( as we have not implemented any escalation scheme to deal with documents not processed on time ) . The last person in the process ( the one who was proclaiming document effective or send it to archive ) was also in charge of defining the type of document . We assumed that this would be the person who would certainly be able to classify the document by type . As the documents in the system were reaching the last life cycle phase ( archive ) , our consultants analyzed logs to see how the documents were circulating . This way we were able to determine optimal paths ( workflows ) for different types of documents through experience . In future learning launches we introduced document types with workflows used from the beginning of the process ( scanning ) and different roles for users . In some cases it was not possible to timely define the path for some documents so users had to reverse to face - to - face or phone calls to determine what should be done with the document but it was also helpful for us as it has pointed to important exceptions . Insight Using the learning launching tool , we achieved the following - • Quick win that boosted the morale of the project participants • Showed that it was feasible to process all document through document management system • Gained data for sizing different aspects of the project ( resources for scanning , need for mobile solution etc . ) • Defined participants who can best contribute to the project . • At the beginning we had some expectations of how will the workflows turn out since we had experience with the similar customers - the learning lunch confirmed some of those and highlighted the specifics for this client . Approach We were very satisfied with learning lunch as a tool in this particular project but we tried not to use it as a main tool in future projects as it is best suited for situations where we can not gain sufficient insight from other tools . It required more technical resources than some other design - thinking tool would use . In one similar situation when we had to determine workflows but could not use learning lunch we used modified mind mapping - users were passing " play " documents of different types between each other around the conference table and we were writing the names of the participants in the process on each document ( post it ) . This provide for a shallower insight but achieved in a shorter time and with less resources .