When dealing with different types of tasks and priorities, often happens to mistakenly consider urgency and importance as synonyms and hence manage tasks, resources and time with a wrong approach.
Urgency is normally driven by external or emergent factors: a customer request, a short deadline, a blocking bug. Importance is usually driven by internal factors: a well known technical debt, a required refactoring, a performance and optimization improvement. You will probably find several definitions on the web concerning these two characteristics. Here, we will try to focus on their appliance to IT projects and how they could improve our perception of priorities and the effectiveness of our productivity.
Therefore, the first step to better manage your time and task allocation is to distinguish between what is urgent (and what is not) and what is important (and what is not). As you could guess, these characteristics can generate up to four combinations of different types of tasks as shown below:
- Not Urgent, Not Important: think about a wrong log information, a typo error in a label of a graphical interface: things appearing in your task list which are easy to fix and not urgent for the client.
- Urgent, Not Important: think about the same information as above but more relevant for customers and auditors: an audit records containing wrong information and used for the generation of a report, it’s an easy fix, not internally important but urgent for the user.
- Not Urgent, Important: things become important, but probably the client is not aware of them (and he/she should not in most of the cases): it could be a refactoring, a performance issue, which has to be fixed, internally, and worries the IT Architect because if not corrected in a short term it could then turn in an headache for the whole team and project.
- Urgent, Important: a blocking bug or a wrong algorithm implementation which affects several layers of the software architecture, has impacts on client side and its propagated to several components of the product.
It’s important to note that the four combinations above do not represent static states: they represent set of tasks, which are dynamics because affected by customer wills, time constraints, product evolution. Tasks could hence move from one combination to another (and thus from a product back log to another), converging – applying a pessimistic but often realistic pattern – to the worst of them, as show below:
A wrong log information can become urgent for the client if affecting customer care interventions on determining the source of an unexpected error (Not Urgent Not Important > Urgent Not Important); a new column in a report table required by the customer but internally not considered important can suddenly turn in something much relevant if the required data would then be needed by other tables and relationships (Urgent Not Important > Urgent Important); a postponed refactoring can be become urgent if blocking new required features (Not Urgent Important > Urgent Important). And, naturally, whatever was urgent and important can only increase its urgency and importance by the time (Urgent Important > Really Urgent Important).
Hence, every single task could, in the worst case, converge to a more urgent and more important task. Indeed, tasks should never move two states further, spotting a wrong prediction or uncorrected requirement in the project: if a Not Urgent and Not Important task, like a supposed to be easy and isolated bug, became an Urgent and Important issue it would definitely mark an underestimation at the beginning. More realistically, Not Urgent and Not Important tasks would remain in that state for a long time, moving from a back log to another and perhaps gaining a bit of urgency when becoming really old or just disappearing as consequence of refactorings and related fixes. And it would be absolutely normal, because depending on their assigned combination, you should manage tasks differently, as suggested below:
Urgent and Important tasks should always have the priority before any other task: you don’t have much choice, you (or any Senior Developer of the team) must work on them, as soon as possible. You should also focus as much as possible on Not Urgent but Important tasks and spending time to identifying them, allocating the right time and resources for them in order to avoid future urgency and pressure: these are the common tasks that would keep an IT Architect and a Senior Developer busy. Urgent but not important tasks are usually easy to fix, don’t require much time but have to be part of the coming release, thus you could either work on them or try to delegate to an experienced team member while Not Urgent and Not Important tasks could be delegated to a newcomer or a Junior Developer, somebody who needs to work on the projects on easy tasks which would introduce him/her to the product through narrowed bug fixes and minor tasks.
That’s it. We actually went through resource and time management just applying four different combinations of tasks, as simple as that. Refactor your ideas, hence, looking at urgency and importance in a different way, optimizing your daily to-do list and increasing the effectiveness of your productivity.
Very often as time passes we fail to revisit our plans as we get busy with our daily tasks. A person who focusses on daily planning will be better at managing time and resources in alignment with the project needs. Team huddles and meeting with senior management to understand the goals of the project on a weekly basis can help to keep the quadrants in sync with the ongoing efforts of the project.
NeoLite
http://javawithneo.blogspot.com