how not to forget about projects or people

how not to forget about projects or people

Hello, I’m Vika Synelnikova, the head of the special projects department at KTS. I will tell you how to plan a team for a large volume of projects every week and not go crazy.

What’s in the article:

How development planning works in most companies

Most development teams, even within our company, work on projects that start at least a month or even three.

When the total project term is calculated in months, it is customary to plan work in sprints. For example, other departments of our company work in two-week sprints. This gives the manager and supervisor a known and predictable team load for months ahead. At the same time, the volume of planning is reduced.

When working in sprints, the vast majority of planning occupies the pre-start of the development itself. Next, the entire volume of tasks of several months is systematically divided into stages of several weeks. In the process of work, the manager and supervisor monitor the implementation of the plan and, if necessary, update it.

How our department works

The main difference is that the development period of some types of projects can be only a few days. Such deadlines greatly affect the planning of the loading of the entire department.

The project for us, as I think for many teams, does not end with launch, but goes into support status. The workload and audience of these projects is very large (the audience can reach several hundreds of thousands of people during the day of the project). Therefore, support is also very important to consider during planning. I will note right away that it is impossible not to plan anything except support for a person or transfer support to another developer. In the first case, the developer may be underloaded, because the volume of support projects does not allow switching the person completely. In the second, you need to know too many nuances inside the project.

Also, in addition to project work, we have daily meetings, mentoring meetings and internal tasks. Therefore, it is important to take into account all these tasks when planning, so that it does not turn out that the time of developers is reserved only for the development of new projects. And distribute all this within the framework of an eight-hour working day.

The first attempts to plan the work of the department

Five years ago, I was the only manager who developed projects with short deadlines at KTS. I kept the entire volume of tasks, project launch deadlines, developer downloads in the halls of my mind and occasionally wrote them down on paper.

When the number of managers increased, we faced the problem of scheduling developers. The same developer could be responsible for different stages of projects—for example, development and support—under two different managers. We tried to solve this problem by creating a chat with the managers of each developer. It was not ideal, but it helped both us and the boys to understand the priority of the tasks and the time to solve them.

The further we grew, the more we understood that a planning system was needed. At first, we tried to start off by planning control points on the project. This was necessary to know who should do something on a specific project on a specific day and not be burdened with other tasks. Then, in 2019, our first table appeared with the name “Future Day”, which says. It is expected that the ideal did not work out immediately and it quickly became clear that the approach itself was wrong.

The letters “p”, “z”, “k” indicate control points on the project.

Evolution is gaining momentum

We entered the year 2020 with a new nameplate and tried to make the loading distribution clearer. Then it seemed that it was enough just to add developers to it.

This helped, but did not solve the planning problems. The most useful thing about this table was that we started pre-empting projects that could be confirmed.

Already from the table of the 20th year, you can see a teaser of the upcoming problem: the layering of tasks from different projects on one person. We slightly changed the table itself in the 21st year, it became better, but it still could not fully solve our planning goals.

Table-cosmolite for planning

After previous experience, we realized that:

  • it is critical for us to understand not only the developer’s schedule for the day, but also for every hour of the day. It may sound scary, but when we analyzed why there was not enough time for some tasks, we noticed that everyone has small switches during the day (for example, going to a meeting) – and began to take this into account;

  • we need accounting for associated costs. These are, for example, meetings with mentors or internal tasks;

  • we need to consider not only the development, but also the support and roar of projects;

  • the team grew and it was important not to forget anyone;

  • both managers and development leaders in the department could work with the table;

  • fast loading analytics are needed to make decisions on new applications and to reconcile the department’s economic plan.

What we have achieved can be suitable for teams where it is necessary to work on all projects at the same time, for example, small agencies.

What our table looks like now

The table has two formats: a collapsed view with graphs for a quick analysis of the department’s workload, and an expanded view that shows details for each of the guys in the department.

Collapsed view

In the picture below, you can see that we have mastered the graphics inside the cells and most of the guys in the department are planned. Their scheduled hours are summarized and highlighted in green inside the chart. The red balance is calculated in relation to working hours, taking into account the different format of work (full-time/part-time). You can also immediately see summary information about loading the entire department, who goes on vacation and when. This type helps to quickly make a decision on confirming the terms of new applications and verifying the compliance of the business plan.

Here, most of the clock is already planned.

Expanded view

The breakdown of possible types of tasks for each individual developer is presented in an expanded form. All tasks are divided into project tasks – this is development, support and maintenance – and non-project tasks. The latter include status updates, mentoring meetings, and internal tasks from the department.

In our planning, we try to allocate time for development, but since these are internal costs, it is important for us that their volume does not exceed 10% per month.

On the right is a column with the employee’s name and a list of projects he is working on. From the top – the number of working hours.

Department load analysis

In addition to quick access to structured data, the table also has an option for quick analysis. There are scheduled hours, unscheduled hours and their percentage ratio.

The results

The main results of working with our “cosmolot” were:

Of course, this table is not a panacea and there are many other scheduling services (we also considered them, even within our task tracker), but they did not completely solve our tasks, so we made a convenient “tool” for ourselves, which significantly simplified the work with planning.

After switching to hourly planning within the day, we clearly began to see which tasks can affect each other, and more precisely determine the deadline for their submission.

It is easy to be indispensable, it is more difficult to do the work in such a way that even without my participation, everyone knows what they are doing. With the help of the tablet, it became possible to delegate the planning process to other managers and development leaders. Without my presence, the planning may take longer, but it is not blocked by me.

Previous tables were too unstructured, so it was difficult to connect team leads to work.

Now, in addition to managers, there are always team leaders of each area of ​​development at the meeting. From planning, they understand their tasks, the tasks of other developers, and the future planning of projects.

In addition, the table is able to solve not only our current problems, but also future ones, when, for example, developers will have their interns and they will need to plan their working day.

To share is to care

This table reduced uncertainty in planning and disagreement among managers. Maybe it will help you as well as us.

I copied our table, took away the extra and duplicated all the months a year ahead. The table has markings on how to use it and examples of filling in different team members: link to it.

We do not stand still

While working on this article, we in the team reached the next task that we will solve – convenient planning of project managers. It would seem that it sounds like resource planning, but in reality it turned out to be not so simple. But this is a completely different story.

Although… If you have your own pain and a solution to the same problem, I will be very happy if you share it.


If you need help with your business tasks, you can write to me telegram and our team will help to come up with a game solution.


Our other management and analytics articles:

Related posts