I will say right away – it is difficult to prioritize one’s tasks. I came to clear instructions on how to prioritize only when I worked as a Product Owner, project manager and department head for several years after working as an analyst.

Therefore, everything below is a look at the work of an analyst from the perspective of how your “manager” looks at it all. In what follows, I’ll use the term “supervisor” very loosely – it can be any team member who gives you more than one task at a time, without telling you in which order to complete the tasks. Because in this case he takes the task of prioritization upon himself. You will only be required to submit the results one by one in the order that has already been determined for you.

You can also freely talk about priorities in any other work, but I am closer to analytics for example.

What is task prioritization? This is a sorting of all tasks that fall on the analyst in the order of their importance and deadlines.

The topic of work priorities is closely related to such soft skills as responsibility and independence. A manager gives you the power to make decisions about how you manage your own time, and you trust that the work will be done on time and in full, and if you have a question, more importantly, you will come to him in advance.

Work aspects and priorities

Prioritization involves several aspects of an analyst’s work. Let’s look at the lines of conduct in each, which I think are worth following, at least until you have established your own guidelines.

If you have a contract / terms of reference, all requirements from it are your first priority. You must submit the project according to these requirements, and in the event that any requirement is not implemented, all the wishes you have made for the customer will not be important. A contract or terms of reference is a legal document. Do not be distracted by something unnecessary and remind the team or manager about the obligations. Since working with the requirements is within your competence, it is your responsibility.

If, for example, you are working according to some agreed scope of work for a release, then the principle is the same, it’s just that these requirements are no longer legally formalized.

It very often happens that the analyst is alone on the project, and the analyst faces, for example, two tasks on the same day – to complete the user manual (which is not burning, but which you already want to finish) or to formulate a proposal for development.

At this moment, I always ask myself “does the team have enough work and am I not slowing down someone else’s work?”.

The downtime of an entire development team is a minus to the company’s budget and a decrease in trust from the project manager who is responsible for the project’s budget. Therefore, if the team has a stock of tasks to implement, then you can add management. Otherwise, see if you’re holding someone else back. And don’t break the deadlines set by the Manager – often two tasks with the same deadline can be spread over the deadlines, but you need to understand in advance that you are running out of time and report the problems to the Manager. Moreover, it should be done in enough time so that in the case of a hard deadline, you have time to finish the task that is not moving.

When actively working with the customer, requests, questions and ideas fly in from the Customer almost every day, and often letters have the priority “urgent! important!”

Please do not rush to react and take to work. Priorities regarding the scope of work and new requirements, which are included or not in the project plan, accepts not an analyst. The content and scope of the project is the responsibility of the project manager, unless otherwise stated (and if you have an analyst responsible for this – you have a chance to get a promotion, you are doing two jobs at the same time).

The behavior strategy, which has been tested by me and several teams, is to honestly sit down with the customer and agree on what to do with such requests and letters. It will be necessary to determine together what is considered urgent and important, and how the customer wants you to act in such situations. There can be many options – from a simple response to the letter during the day to stopping the release and reprioritizing the release scope.

A recent example.

We developed the system with agile, and users were already working in the system. The working group from the Customer had a clear road map of what should be done in each release. But users kept coming in with interesting improvements that ultimately increased the system’s usability and they really wanted to be done. WG sent us 5-7 letters with wishes and questions every day. The problem was that the scope was already formed several releases ahead, and the analyst did not have time to do anything except to answer these letters, and after several letters an active correspondence was established. In addition, the WG began to get angry over time that their “urgent! important” letters were answered with a delay of several days.

We sat down with the working group and agreed on the following:

1. We respond to all letters in the order of their arrival (FIFO principle “First in – first out”). If any letter has a sign of importance – we answer it first and then return to processing the queue of letters.

2. At times of peak workload for the analyst (at the beginning and end of the release), we try to answer 2-3 letters per day, in the middle of the release we catch up with all “debts”. Here we thought about involving an additional analyst, but the tester and the analyst decided to divide the responsibilities by letter – if there was a question about the system, the tester prepared the answer independently and the analyst only checked and sent it to the customer.

3. In the scope of each release, low-priority tasks were identified, which take 20% of the time of the total scope, which could be sacrificed (or moved to the next release) and do some critical requests from the users. The decision to include or exclude a feature had to be made jointly with the WG and only before the middle of the release, so that the team had time to implement these features.

Eisenhower matrix principle

Working on priorities always requires an analysis of your entire list of tasks. The Eisenhower matrix helps me in my work, which allows me to break down tasks by urgent/important.

• Important and urgent. This is your crisis or deadline that you did not know about, but it has arrived. An example can be a list of comments that arrived two days before the closing of the stage under the contract for the reporting document that you planned to hand over calmly. It is not possible to postpone the submission deadline, and without corrections to this document, it will not be accepted. Decision: you drop everything and do only him

• Important, but not urgent. In this square are all the tasks related to the project that need to be done within the planned time frame: implement the requirements of the technical task, create source documents, undergo advanced training. Decision: you need to have a list of such tasks with a due date. Here I would additionally advise to have two terms – the term of issuing the result and the formal term of the deadline. So you will have time leeway in case of crisis tasks, and the opportunity to correct something if comments come.

• Not important, but urgent. These are usually tasks for tasks. A clear example would be a customer’s request to download the entire jira with implementation statuses to understand how quickly you respond to issues. Decision: discussion and revision of the terms of such tasks, delegation of tasks, discussion of the real value of the task.

• Not important and not urgent. If possible, avoid such tasks, they distract you from things. For example, the project manager sends you a presentation they made with marketing on all the customer’s projects, asking you to look at it and give your opinion. It is not your responsibility and is not even close to your competence. Decision: when recognizing such a task, your first reaction should be the word “no”. Do not take them “on board” right away, then do not get rid of them, it is always more difficult to refuse when they have been dumped on you.

About responsibility and independence

I strongly advise against relying on prioritization at first. At the beginning of a new project, when communicating with a new customer, the new team should discuss the analyst’s work expectations. This way, the Manager will know that you and he equally understand what needs to be done. Plus, in any unclear situation, I would advise you to immediately contact the Manager and clarify expectations. Situations may change, you may not all know, and the Manager did not have time to convey the information to you. Less misunderstanding means less stress.