How an analyst can work with task priorities
I’ll say right away that it’s difficult to prioritize your tasks. I came to clear guidelines about how to prioritize only when, after working as an analyst for several years, I worked as a Product Owner, project manager and department head.
Therefore, everything below is a look at working as an analyst through the prism of how your “supervisor” looks at it all. In what follows, I will use the term “manager” very loosely – it can be any team member who gives you more than one task in one period of time, without specifying in what order the tasks should be done. Because in this case, he takes on the task of prioritization. You will only be required to give 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 prefer analytics as an example.
What is task prioritization? This is sorting all the tasks that fall on the analyst in order of their importance and deadlines.
The topic of priorities at work is very closely related to such soft skills as responsibility and independence. The manager gives you the right to decide how you manage your own time, and believes that the work will be done on time and in full, and if you have questions, what is more important, you will come to him in advance.
Aspects of work and priorities
Prioritization concerns several aspects of an analyst's work. Let's look at the lines of behavior in each, which, in my opinion, are worth sticking to, at least until you have built your own guidelines.
If you have a contract/technical specification, then all the requirements from it are your first priority. You must submit the project according to these requirements, and if some requirement is not implemented, all the wishes that you made for the customer will become unimportant. A contract or terms of reference is a legal document. Don't be distracted by anything unnecessary and remind your team or manager of your obligations. Since working with requirements is within your competence, it is also your responsibility.
If you, for example, are working according to some kind of agreed scope of work for a release, then the principle is the same, it’s just that these requirements are no longer formalized legally.
It often happens that an analyst is alone on a project, and the analyst is faced, for example, with two tasks for the same day – to finish the user manual (which is not on, but which you already want to finish) or to formulate a development statement.
At this point, I always ask myself, “does the team have enough work and am I slowing down someone else’s work?”
Downtime for 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 budget. Therefore, if the team has a reserve of tasks to implement, then you can add to the manual. Otherwise, see if you are slowing down someone else. And are you missing the deadlines set by the Manager? Often two tasks with the same deadline can be separated by deadlines, but you need to understand in advance that you are not on time and report the problems to the Manager. Moreover, this needs to be done in so much time that in the event of a hard deadline, you have time to complete the task that is not moving.
When actively working with the customer, wishes, 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 get to work. Priorities for work scope and new requirements that are included or not in the project plan are taken by not an analyst. The project manager is responsible for the content and scope of the project, unless otherwise stated (and if you have an analyst responsible for this, you have a chance to get promoted, you are doing two jobs at the same time).
A behavior strategy that has been tested by me and several teams is to honestly sit down with the customer and agree on what to do with such requirements and letters. You will need to determine together what is considered urgent and important, and how the customer wants you to act in such situations. There can be a lot of options – from a simple answer to a letter within a day to pausing the release and reprioritizing the release scope.
A recent example.
We developed the system using agile, and users were already working in the system. The Client Working Group (WG) had a clear road map of what should be done in each release. But users constantly sent in interesting improvements that ultimately increased the usability of the system, and I really wanted to make them. RG sent us 5-7 letters every day with wishes and questions. The problem was that the scope had already been formed several releases in advance, and the analyst did not have time to do anything other than respond to these letters, and active correspondence began over several letters. Additionally, over time, RG began to get angry that their “urgent! important” letters were answered with a delay of several days.
We sat down with the RG and agreed on the following:
We answer all letters in the order they arrive (FIFO principle “First in, first out”). If some letter has a sign of importance, we answer it first and then return to processing the queue of letters.
At times of peak load on the analyst (at the beginning and end of the release), we try to answer 2-3 letters a day, in the middle of the release we catch up on all the “debts”. Here we thought about hiring an additional analyst, but the tester and analyst decided to share responsibilities for letters – if there was a question about the system, the tester prepared an answer on his own and the analyst only checked and sent it to the customer.
In the scope of each release, low-priority tasks were identified, occupying 20% of the time of the total scope, which could be sacrificed (or transferred to the next release) and some critical requests from users be made. The decision to include or exclude a feature had to be made jointly with the RG 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 analyzing your entire list of tasks. The Eisenhower matrix helps me in my work, which allows me to break down tasks according to Urgent / Important.
Important and urgent. This is your crisis or deadline that you didn’t know about, but it has come. An example could be a list of comments on a reporting document that you planned to calmly submit two days before the closing of a contract stage. You cannot postpone the deadline, and without corrections on this document they will not accept it from you. Solution: you give up everything and do only it.
Important, but not urgent. This square contains all the tasks for the project that need to be completed within the planned time frame: implement the requirements of the technical specifications, generate output documents, undergo advanced training. Solution: You need to have a list of such tasks with an indication of the deadline for their completion. Here I would additionally advise having two deadlines – the deadline for issuing the result and the formal deadline. This way you will have time slack in case of crisis tasks, and the opportunity to correct something if comments come in.
Not important, but urgent. Usually these are tasks for the sake of tasks. A striking example would be a customer’s request to download the entire Jira with implementation statuses in order to understand how quickly you respond to problems. Solution: discussion and revision of the deadlines for 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 your work. For example – a project manager sends you a presentation that they made with marketing on all customer projects with a request to watch and give your opinion. This is not your responsibility and is not even close to your control. Solution: When faced with such a task, your first reaction should be the word “no”. Don’t take them “on board” right away, and then you won’t get rid of them; it’s always harder to refuse when they’ve already been thrown off to you.
About responsibility and independence
I strongly advise not to rely on your understanding of priorities at first. At the beginning of a new project, when communicating with a new customer, the new team needs to discuss expectations from the analyst’s work. This way the Leader will know that you and he have the same understanding of what needs to be done. Plus, in any unclear situation, I would advise immediately contacting the Manager and clarifying expectations. Situations may change, you may not know everything, and the Leader did not have time to convey the information to you. Less misunderstanding means less stress.
