How to carry out an analysis in an optimization project properly?

In my job, I try to use the following techniques and methods of analysis:

• Examining the documentation – if there is any.
• Interviewing owners and process participants – it is important to understand not only the needs and ills of the management but also spend as much time as possible with ordinary employees. Thanks to that, you can get to know their point of view. They are on the front line while carrying out tasks in the process.
• Analyzing questionnaires and surveys – if the group of surveyed stakeholders is too big to discuss the form of a workshop, preparing such materials may be useful. People involved in the project can fill them independently, which will facilitate gathering detailed information on processes.
• Conducting workshops – live interaction in the form of a brainstorm, collaborative training, and experiments that may be a fun and easy way to gain an enormous amount of new ideas.
• Having individual conversations, best in person – people rather say out loud what they feel and need, when their colleagues and leaders are not around.
• Observing – committing in meetings, videoconferences, listening to talks with customers, watching the real work of a task performer is a great way of acquiring objective knowledge on current processes in the organization.
• UX (user experience) testing – creating clickable mockups, verifying concepts, experimenting, and testing them with users for finding the best solution for a specified process or workflow. In this case, sessions in real life with individual users work best.

Analysis methods – choose the best combination

The question arises as to how to choose the best method of analysis for area optimization. There is no straightforward answer. It depends on many external and internal factors that are distinctive for a given project or area. The team project should work out possibly the best way of gathering optimization requirements, and as a result, usually, a combination of the methods mentioned above is chosen.

Personally, I commonly start with documentation examination and then with short preliminary interviews. When it is possible, I suggest an observation as well as workshops. This way, I gain knowledge not only directly from key personnel in the organization but also from line employees who participate in processes that I am interested in. Observations and comments of particular people often derived from conversations without the involvement of their supervisors may provide many valuable as well as non-obvious information. We may consider and use a user-centered design approach in which ordinary process participants define requirements and approve implementation – they are the ones who know best what do they need.

Regardless of which approach will be adopted, you always need to consult with a sponsor and key stakeholders. There may occur financial or organizational constraints related to the suggested method; for example, due to the lack of budget for business trips, requirements workshops might not take place. Stakeholders’ and users’ availability may be limited because of the need to maintain production or service continuity. Caution, as well as remaining vigilant, are always needed both when choosing methods and when filtering received information.

There are situations when we talk to two people at similar positions in the company’s structure and get radically different opinions on the same issue. Also, an uptight organizational culture of the company may cause employees to answer more likely honestly when the anonymity is ensured. Very often, customers are not able to define their expectations precisely, and therefore, UX tests may prove useful.

A few words about diagrams

• Diagrams are your best friends when it comes to illustrating what have you investigated and found out. There is no way to mention all of them in one article – yet again, I suggest a combination that works best for me.
• Mind map – organize your wandering thoughts and draw a map. While creating it, I never force myself to a rigid concept. A mind map is a loosely related picture of what I have in my head. It helps to sort out what dependencies are between tasks, areas, documents, guidelines, and whatever else I think of.
• Process map – guess none is surprised. Depending on the complexity of the project, there may be from one map to several. Still, there is no better method of presenting as-is and to-be processes.
• State machine diagram – a diagram perfect for showing object transition from one state to another and point what conditions have to be fulfilled. This diagram suits best visualize a life cycle of a lead or payment to business.
• Data flow diagram – where data comes from and where it goes.
• Domain diagram – what objects do we have in the system and what the relations between them are, for example, one-to-many, many-to-many, etc. Usually, I draw it to myself to get to know the system better and identify relationships that should be modified in a given project.

I could go on and mention a class diagram, a sequence diagram, a use case diagram, and so on, but not always each one of them will be useful. Those I listed are my personal must-have.

How about you, what methods and techniques do you use?