Sam was in the middle of the task, steady typing the code once John called him.
- We have promised the customer a new button on a top menu, generating the weekly report in the Awesome App. Can you do this now?
- But John, I am finishing the task for ABC generator…
- No problem, just after that.
- I was going to start another there, as Mark cannot finish the C typer without this.
- But it’s urgent! And you’re the only .net dev who is not on the vacation right now…
- Well…
Sounds familiar? In every company, there are some overloads. It is very hard to precisely estimate the work needed for the project or predict when a new offer will be accepted and the project started.
What is overload?
Let’s start with the definition:
According to the Cambridge dictionary:
to give someone more work or problems than they can deal with – simple as that.
The Employee has more tasks than he’s able to perform in his regular working hours, there are too many tasks to give each of those enough attention and usually at least some of them should be finished yesterday.
Why is it bad?
You may say: “It’s cheap, everyone does this, nothing bad is going to happen”. Yeah, not quite…
- Decreasing morale – if it happens regularly, employees will be demotivated, stressed and frustrated. It’s awful to work intensively the whole day, knowing that it’s still not enough.
- Deterioration of work quality – when you’re overloaded you often have to multitask, which makes focus, together with considering all dependencies, much harder.
- Decreasing the productivity – overloaded people are tired and perform tasks longer. Ask a developer to write a simple functionality, in the meantime let some trainee consult his code with the developer and ask him about credentials to the test server from the old project ( you need it NOW, right?). This simple functionality will take him 3 hours instead of 1, because of the constant context switching.
- Missing opportunities – if there are already too many tasks, it’s not possible to start working on a new project or feature. A waitress cannot take your order if she’s holding 2 trays full of dishes.
- Reduced value of resource planning – it’s hard to precisely plan the work of the overloaded person. If the overload is unplanned it’s even worse (planned items will be delayed or unfinished, the developer will not be prepared).
But why is it happening?
To understand and mitigate overload you have to identify the main reasons for it:
- Unclear tasks – how many times have you seen tasks like: “add search functionality”, “implement comments”? It has the consequences:
- The developer will consult a client/project manager (PM) more often to receive more details, stopping and resuming his work.
- There will be a need to repeat the task as it will not meet the client’s expectations – “You’ve told me to paint the wall in some nice color, you have not told me that it can’t be pink!”.
- Tests will be more complicated as it is not clear what was the purpose of the task. How to check if the report is generating correctly if you don’t have the report specification?
- Product’s quality will suffer – if someone asks you to buy tires, you can pick the winter or summer ones, even for the same price the experience might be dramatically different. If someone will ask you to make a suit and you will not get the precise measurements, a man wearing it will feel not comfortable.
- Emergency fixes – errors in the production environment, influencing the business significantly – for example the malfunction of a cash register in a shop.
- Lack of Service Level Agreement (SLA) – this is the issue especially in smaller companies: a client refuses to sign the SLA agreement or a software house not offer it. Once the project is finished the client will expect instant fixes/changes (sometimes even for free), despite there are no developers assigned to the project.
- Underestimating tasks – once developers have started their work they found out, that it will be more time consuming or they will have to use another solution.
- Inadequate planning – if there are too many projects in a pipeline, resource planning is not done properly, the projects’ assignment might not be clear. Developers will not be aware of tasks and there will be conflicts between projects.
- Internal company’s tasks – There are some general company’s activities which needs the employees’ support, for example:
- New projects estimations
- Code review
- Knowledge transfer
- Audit
Ad-hoc remedy
Sometimes it is too late to prevent it. You are on the overload, what’s now? The answer will be a little different in every company, but I have gathered some universal advises divided into two perspectives:
Employee perspective
- If you receive a new task and already see that you will not be able to finish it during the standard working hours, communicate this to the person who is assigning this new task.
- Your team leader (TL) and PM should be aware that you are overloaded.
- If you don’t want to work over hours, which is often the result of overloading, communicate this clearly to the TL &/or PM.
- If it’s possible to reassign the task to some underloaded person in the same project, let the TL/PM know.
Of course, the contact person might vary depending on the company’s structure.
Manager perspective
- Check if it’s possible to assign the task to some underloaded person (a good resource plan will be helpful here).
- Avoid overloading if it’s possible (maybe you can postpone some tasks?).
- Set low priority projects on-hold (if possible).
- Check if it’s possible to outsource the tasks to other team or external coworker, check the finance.
Long-term solutions
The best approach is to minimize overload before it happens. To do this effectively, we have to focus on the causes.
- Unclear tasks
To know which tire you have to choose, you have to see the full picture. Where will it be used? In what kind of car? When?
Each defined task should contain at least:
- Business context – short description of business value brought by the task, what will be the benefits of implementing it. Without that, it’s easier to misunderstand the task.
- Acceptance criteria – short and clear bullet points describing products which should be delivered to finish the task.
- Designs showing the desired effect (if applicable)
- Any other useful information
- Emergency fixes
If you will not act quickly client will lose money or reputation, but you have to do this wisely.
- Well defined SLA makes the situation clear – you limit the ASAP tasks to the minimum and ease planning the rest.
- Forcing the client to buy the service hours as a part of the SLA – then you can book the developer’s time and it is much easier to undertake a fast action.
- Redundancy of knowledge – if there is more than one person who has enough knowledge to prepare the changes or fixes it is much easier to balance the work.
- Tasks in projects without SLA
- Clients should be convinced about signing on the SLA.
- The best effort support should be a part of standard software development agreement, like: „If there are any changes or bugs reported by the client, Software house has 4 weeks to start working on it. One hour of work costs x EUR/hour and there are no monthly fixed fees”. If the client will be not enthusiastic about this, you explain that it is for his safety and if it is not enough you can sign on the full SLA.
- If you will not support the application at all it should be clearly said, agreed with the client and included in the formal agreement.
- Underestimating tasks
- Estimates should be checked by another developer.
- Junior developers should have the support of more experienced colleagues.
- It should be clear what is contained in the task estimation, for example, manual tests, unit tests, documentation, code review etc.
- Once the tasks are finished the estimates should be compared to the work done. After a few projects, you will know which developer has what tendency in estimates (if he is usually too optimistic/pessimistic etc.).
- Inadequate planning
- Before signing-in the development agreement you should confirm that your company will be able to provide suitable developers for the project’s timeline.
- Regular resource planning meeting being done by adequate Managers.
- Assigning a new developer to the project should be confirmed with the rest of Managers to avoid conflicts.
- Internal company’s tasks
- Some of those tasks can be dedicated to the specific person, which will allow the company to book his time and leave the margin for the company’s tasks.
- If you will use the developers’ maximum capacity, any additional work will ruin the plan. It is good to leave some margin.
Overload will always be present, as it is not possible to precisely plan the entire work, forecast every client’s step and result of each offer. I hope that this article will help you to reduce it to a healthy minimum.
