Analyst's work in conditions of uncertainty

For an analyst, working under uncertainty and tight deadlines is a common occurrence. Especially if he or she is involved in research or startups. But commonplace ≠ normal. In such a regime, the brain has a hard time, cognitive abilities decline: planning and decision-making become more difficult.

Dinar Karimov, an analyst at Naumen Contact Center, explained when uncertainty arises and how to reduce the risk of its occurrence.

Dinar Karimov

Analyst at Naumen Contact Center

What is the difficulty of an analyst's job?

An analyst is an intermediary between a business customer and a developer. The business wants to be sure that the output will be exactly what it expects. The developer needs to understand what needs to be done and what result to provide. So, the analyst needs to understand why the business needs the development, conduct analytical work and, at the output, in the form of a statement, inform the developer what is required of him.

Our task sounds quite simple: find out what is needed, collect requirements, conduct an analysis and assign the task to the developer. But what if we need to take into account unidentified or unformalized requirements?

In one of the projects, I encountered exactly this situation. Our team's task was to develop a pilot system that would take into account innovations in a particular industry. At the concept and idea level, everything was clear, but in order to develop detailed requirements and design a solution, more detailed and specific information was needed. We did not have it – there was no regulatory document and recommendations from the department that was planning the innovation. We collected information bit by bit, searched for statistical data on the Internet, consulted with the department, and even joined a working group that discussed the planned innovations. This is how we were able to formulate requirements and develop a pilot system. But since the regulatory document was never adopted, the level of uncertainty remained in any case.

The lack of formal requirements is directly related to the complexity of the task: the more complex the task, the higher the uncertainty. A striking example is working in startups, innovative projects and projects with many research tasks. When we are involved in such projects and participate in the development of products and individual features, we cannot say in advance what the result will be, what path we will take and whether we will get what we originally planned.

When uncertainty appears

Demonstrates uncertainty behavior very well cone of uncertainty — a graph that shows changes in the project estimate depending on the stage at which the estimate is made. That is, the scope of work, costs, and functionality become clearer as new information appears.

The initial stage of work on the project is the initial concept. The author of the idea, Barry Boehm, considered that the estimate at this stage can deviate from the final values ​​several times. After the initial stage, there is an agreement on the requirements for the product, completion of the requirements, and so on. In the end, we receive a finished software product. It is at this stage, when the development is already completed, that we understand how much time we spent on this work, how much labor costs and what functionality is in this product.

The ideal situation is when we managed to define and take into account all the requirements at the start of the project. But, unfortunately, it is extremely rare to completely eliminate uncertainty at the early stages – it is impossible to know absolutely everything in advance. Uncertainty is almost always present at the start of the project, but it can also appear in the future. For example, if we work according to the agile methodology: we have a backlog, set priorities, estimated labor costs, planned the next sprints. But we cannot be 100% sure that tomorrow the customer will not say that he wants to change the priority of some feature or refuse it altogether. Such a decision can affect other features and even the architecture of the solution.

The closer we are to the end of the project, the less we can influence the project, and making changes is more expensive. Below is a graph showing how the level of uncertainty and the ability to influence the project change depending on the stage of the project life cycle.

The downward curve is uncertainty that decreases towards the end of the project. The upward curve shows the cost of making changes to the project at different stages. The graph shows that if we encounter changes at the end of the project, they will cost us much more. Therefore, the sooner we reduce uncertainty, the more we can reduce not only risks, but also losses for the team, the company and the business customer as a whole.

How to Minimize Uncertainty

So, what can you do to minimize uncertainty? I’m sharing an action plan that helps me work through uncertainty.

Step 1. Create a mind map.

I use this tool as a knowledge base. Mindmap is always at hand, so I actively use it when performing analytical tasks to eliminate the possibility of missing something.

I create it like this: I divide my area of ​​responsibility into areas → I divide the areas into aspects → I divide the aspects into questions that need to be answered and a solution obtained, and the tools that are needed to answer the questions.

There are often tasks that are repeated regularly. I took aspects, questions and tools from the mind map that help to work through such tasks. The result is a checklist that speeds up the execution of typical tasks: I go through the questions and clarify the information using tools.

Step 3. Iterative approach.

Over time, I return to those questions that I couldn’t clarify right away. If I think I missed something, I double-check. Perhaps it’s some important question that needs to be taken into account.

Step 4. Updating the mind map.

If I come across questions and tools in the tasks that helped clarify the necessary information, I update the mind map and keep it up to date.

These steps help me control and minimize uncertainty. But I can't always anticipate all the requirements. And that's okay: I view such cases as a lesson and an opportunity for growth, and I regularly update and update my mind map to avoid making the same mistakes.