The Eisenhower Matrix is a very well-known method for determining priorities. For example, in Stephen Covey's famous book, The Seven Skills of Highly Effective People, an entire chapter is devoted to the matrix.
The matrix is a tool for prioritizing tasks. Invented it, they say, the 34th President of the United States Dwight Eisenhower. Prioritization using the matrix is simple and effective.
As far as he is known, he is not so common in our environment whether it would concern work or life. The Eisenhower matrix looks like this:
Any task that needs to be done falls into one of the four quadrants of the matrix. Perform in order from top to bottom, from left to right. First - urgent and important, then - urgent and not important, then not urgent and important, and, finally, not urgent and not important.
The key problem that people face when working with the Eisenhower matrix is the classification
of tasks by urgency and importance. To be more precise, the main problem is to understand what urgency and importance are. Without having understood, people throw a matrix, having played a day or two. Let's try to figure it out.
Unfortunately, or fortunately, there are no unambiguous criteria. Anyone can come up with their own rules, but not everyone will do it. Therefore, let us do this: I will tell you how I define urgency and importance, and you decide for yourself whether this approach suits you or not. So come up with your own rules.
Let's start with urgency, because it takes priority.
What task can be called urgent? I do not remember where I heard this criterion, but I really liked its simplicity. The urgent task is one that you can no longer do after the expiration date
. Simple and straightforward.
But to apply this approach in life is not easy. That base has ceased to work for a client - is it necessary to repair it urgently or not? By criterion - no, because The base must be raised now and tomorrow, and in a week. If you try to explain someone’s urgency in a crisis situation, nothing good will come of it.
Therefore, we will take a smoother criterion. Urgent - this is when losses are high due to the fact that the task is not solved
. Take a break and think about how urgent the tasks that we are accustomed to consider as such?
Unfortunately, many managers tend to call urgent tasks all in a row. Regret is not that they are wrong, but that the system of priorities stops working - all tasks look the same. It’s hard for a programmer to choose.
Objective urgency is often encountered in the tasks of clients - for example, the aforementioned base drop. Or in the courtyard of the 19th of October, and the client must take the VAT, and the declaration is not formed. Or, God forbid, the end of March, and the income tax does not count. Or invoices are not printed, for an inexplicable reason, and there are downtime in the shipment.
Such tasks are urgent, because they satisfy our criterion - there are real losses from the fact that the task is not solved. And it’s not just there - the profit tax that is not handed over in time threatens with a serious grave.
It is important to be able to separate the concepts of "urgency" and "deadline." Term, anyway, is at any task, even if it is not designated. Then I am a little ahead of myself, the time will be discussed another time, but I want you to understand: the availability of a term is not an urgency
. As well as the approach of the term - this is not an urgency.
The urgency of the task does not correlate with the date of its execution. For example, the deadline for completing a task may not be the “date” type at all, but “as soon as possible, damn it!”. Ie, formally, there is no time limit. The task, however, is urgent. Or the task may have a deadline tomorrow, but everyone understands that it was put by a person who doesn’t need a solution — he will postpone the deadline to any date at the first request.Or the system is so arranged that the task cannot be entered without a deadline.
Urgency is a separate attribute of a task, characterizing the context of its birth and life, and not managerial designations such as “deadline” or “inclusion in the plan of this day.”
Now about the importance. Let's return to the classic - Stephen Covey. He identified important tasks for the future
. Simple enough, though not entirely clear definition. Let's try to decipher.
There are tasks from the solution of which nothing fundamentally changes. You decided it, the client paid the money, and there were no significant changes - neither you nor the client. The solution of this task didn’t cause a flurry of new tasks, a long-running project wasn’t launched, no one was fired or hired, any oppressive problem of the client’s business wasn’t solved.
And there is the client’s task, deciding which, you get the project. There is a central task of the project phase, which translates it from testing to operation. There is a task to test the hypothesis in risky development, after solving which you have the first release, and you can finally show your product to users and get feedback. There is a task on the solution of which the reputation of the team or your entire company depends. There is a task by which your promotion will be judged. There is a task on which your hourly rate depends.
These are important tasks. Something depends on them. And not just “something”, but a specific “something” that is understandable to you and useful to you. They not only influence the future, but also form it
For example, I create this material, which will later become a course. Until I write the material, there will be no course. There will be no course - there will be no sales. I will write a course - everything will happen. Writing a course is an important task. Instead, I can be distracted by current tasks - do something for clients, or release another release. Perhaps these are urgent tasks, but they do not create the future. And the course - creates.
That is the importance of the task. Everybody understands it implicitly, but here's the catch - understanding alone is not enough. When we talked about choosing a task, we noted: if a person decides for himself what task to undertake, then he is guided by his own criteria. And what kind of person, in his right mind, will willingly undertake an important task?
You understand: high importance is high responsibility
. Whatever we think about people or about ourselves, we try to avoid responsibility. Therefore, an important task will be postponed, and the programmer will do what he likes.
In order for important tasks to be carried out in the first place, it is necessary to adjust the system of priorities and help the executive with a choice. And now the moment has come when we bring the first algorithm into our system of priorities - we will determine the order of execution depending on the urgency and importance.
Technically it is very simple. It is enough to add two fields to the task - urgency and importance, and arrange the queue by them. For example, calculating the priority of the task in the form of numbers. If the task is urgent, then we add 2 conventional units, if the important one is 1 conventional unit.
Total, not important and not urgent task will have priority equal to zero. Urgent and not important - 2. Not urgent and important - 1. Urgent and important - 3. Now we arrange the task list in descending order of calculated priority, and we get the result - the correct sequence, which reflects our strategy.
The rules for calculating the numbers of urgency and importance - not hard. And, unfortunately, they work only if urgency and importance are assigned to the task thoughtfully, and not just so that they can do it quickly.
For example, it often happens that the tasks from clients are recorded by managers, and executed by programmers. Managers, having understood the system of priorities, begin to sculpt the urgency and importance of all tasks in a row, especially when a specific programmer is not assigned to a manager or client.The manager’s desire to move his task to the top of the queue is, in general, understandable, but by striving to get as many signed acts as possible as quickly as possible he negates all your efforts to build a system of priorities. And seriously pokes out programmers.
There are several solutions to this problem.
The first, harder is not to let the manager put urgency and importance. Let him just write down the task. If there are any additional requirements that can affect the priority, let it be stated in the task description. In fact, suddenly there really is an emergency? The coordinator, or team leader, or the lead programmer in this case will be guided by information from the manager.
The second option, softer is to make two assessments of urgency and importance. One - from the manager, the second - from the one who understands something, and the final priority to calculate the sum of conventional units. Maximum 3 conventional units from the manager, and maximum 3 - from the coordinator. The system of priorities will become more multifaceted and balanced.
Well, do not forget the simple rule: there are no urgent and important tasks in the world
. When regulators such as urgency and importance appear, the hand itself stretches to use them. It seems that something is missing when urgency and importance are not indicated.
The lack of urgency and importance of the task is normal. But there is one problem - such a task, theoretically, can never be fulfilled if new ones constantly appear, having at least one conventional unit of priority. How to avoid such a situation, let's talk another time.
- The Eisenhower matrix is a simple prioritization tool;
- Priority is governed by two signs - urgency and importance;
- The urgent task is one whose losses from default are high;
- An important task is one that affects the future;
- Urgency over priority;
- There are tasks that are not urgent and not important;
- Priorities work only when consciously determining urgency and importance.