How we manage projects for the development of analytical reporting

Hello, Habr! My name is Vladimir, I am a business analyst in the Rostelecom data office and I am involved in the development of reporting. The company is committed to developing a data-driven culture. The demand for data and analytics from the business side is growing, and accordingly the data management ecosystem, including the organizational structure and business processes, is evolving.

By the end of 2019, the volume of reporting tasks has grown dramatically and this has become a kind of load testing for our processes. It became clear that it is becoming more and more difficult for us to work in the old way and comply with the SLA. New rules of the game were needed, compliance with which would make managing common tasks easier, planning more predictable, and fulfilling commitments realistic even in conditions when the growth of the team was very limited, and the growth in the number of applications was unlimited.

From the beginning of 2020, we began to build a project approach, considering requests from businesses as projects. The controversial issue was the choice of the person responsible for the task as a whole, i.e. who in these projects should act as the project manager. Here we describe how we solved this issue and what results we got.


“You need to run as fast just to stay in place, and to get somewhere, you need to run at least twice as fast!” – wrote Lewis Carroll back in the days of Victorian England. A hundred years later, the “Black Queen principle” was called the evolutionary hypothesiscomparing the struggle for survival to an arms race. The faster the environment changes, the more important is the speed of adaptation. For organizations, this rule works the same: to stay afloat, you need to quickly adapt to changes in competitors, learn and rebuild processes more efficiently.

The telecom industry, and especially data management, is growing rapidly along with the demand for services, but this same growth, together with opportunities, creates many problems… This is especially important when the activities of the organization are diverse and contain a lot of specifics, which makes it more difficult to apply someone else’s experience. Because of this, you have to improvise more often and instead of generally accepted good practices (why, in this case, the best practices are “good” rather than “best” – I recommend reading from Roman Zhuravleva) look for alternatives that are optimal for a particular situation.


To choose the optimal solution, you need to know the conditions for which it is intended, so I’ll start with an overview.

In the corporate center of Rostelecom, all core areas working with reporting are combined into Data Office. These are more than two hundred employees in Moscow and the regions who are engaged in the development of a data management platform, work in the direction of in-depth analysis and the development of analytical reporting.

The direction is extensive: reports use data from several hundred source systems, requests come from all divisions of the company, which have their own characteristics, business processes and applicable regulations. The geography of business is the whole country, divided into seven macro-regional branches, each of which was not so long ago separate company… The importance of reporting and the requirements for quality analytics are growing as the business uses data to make day-to-day management decisions and data becomes an important part of the company’s operational processes.

The development of reporting is organized as follows: permanent teams of 10-30 analysts and developers are assigned to business segments, from which working groups are formed for individual tasks. There are many differences in the business processes of the segments and it is unproductive to understand them every time. Developers are easier with this, but still want to keep the teams that worked together. The segment team is led by a front manager who combines the role of resource manager for the team and account manager for the customer.

Usually, a front manager has 10-12 tasks at work, with each task at different stages from 2 to 5 people can work. The duration of such tasks is from several weeks to six months (this is a very rough estimate to show the scale). For each revision, it is required to create artifacts: a set of documents that will be used by the maintainer to work on incidents, and reporting in JIRA on the amount of labor costs, work times and resource utilization, which allows you to analyze the effectiveness of processes.

In order for the task to pass the route and not slip, it needs an owner immersed in the object and interested in its timely completion. Previously, front managers did this, but by the end of 2019, the volume of tasks had grown so much that they had no time left to manage individual tasks. The fronts have the main responsibilities – interacting with business customers, routing incoming requests and managing the team, and the management of individual tasks can be delegated, otherwise it will be like in the picture.

Finding a solution

In fact, we were choosing between two options: to recruit dedicated performers for the role of the RP, or to organize the combination of this role by someone from the team. To do this, it was necessary to figure out what tasks the RP will manage, what this management will consist of and what activities need to be coordinated. This made it possible to determine the skills necessary for our RP and to assess the volume of tasks with which one RP will be able to work in parallel. A separate important question is how the appearance of a new leader will affect the rest of the team.

We realized that in our case many of the “classic” project manager competencies would be unclaimed: for example, there is no need to manage the budget or suppliers, projects will be carried out according to the same regulations, and the subject area will always be limited to reporting for a specific business segment. The tasks are most often typical, but they require immersion in the subject area, understanding of the development process and the content of work at all stages.

We concluded that an RP with a small number of tasks will cost unreasonably expensive and will be underutilized, and in a larger volume of tasks it will not have time to figure it out, and its management will be limited to purely administrative functions. On the other hand, adding a dedicated RP to a small team will significantly complicate communication – you will have to keep another boss informed of issues that he does not directly deal with.

The costs for the team will increase, but this will not solve the problem. Proceeding from this, we refused from the selected performers in the role of RP. On the other hand, analysts are already:

  • immersed in the subject area like no other;

  • participate in the task at all stages;

  • play an integrating role for the team.

From this perspective, the idea of ​​combining project management with the role of analyst (business or systems) began to look logical.


Then we designed and documented the process, combined with the already existing operational processes, some of which have already been told by my colleagues (articles on Habré: one, two). In general, the development process took the form:

The documentation was compiled in the format of a management methodology, rather even instructions. Somewhere we took our own developments, somewhere we broadcast PMBoK recommendations to our organizational environment. They wrote so that the document was sufficient to fulfill the role of the RP, and so that it could be used by a person without project management experience.

Then, supplementing the document with all the accompanying tinsel like templates, we conducted training and at the beginning of 2020 launched the process in pilot mode. The work has not been completed yet, there is still a lot to be done regarding the consistency of processes, but certain conclusions can already be drawn.

The positive dynamics is clearly seen in the example of the tasks of connecting new sources, the duration of which has been significantly reduced.

To the pluses the decision taken can be attributed to:

  1. First of all – the very approach to the issue, when a team of analysts develops a process taking into account the existing practice and best practices;

  2. We spend no more time on communication within the team than we did before;

  3. Task materials are easier to reuse, and timelines are generally more predictable.


  1. There are inconsistencies with operational processes, especially in atypical situations, but this is to be expected – we continue to polish;

  2. Analysts fill out more paperwork, keep project cards up to date, and keep minutes of meetings. Expected, but sometimes tiresome:

The preliminary conclusions are optimistic: for small but immersive tasks, combining the roles of the RP and the business

analytics provides more advantages than inconveniences.

Instead of an epilogue

“Wait a minute, task management… Have you discovered for yourself? a door the role of the project manager and hung on the business analyst? “. The short answer is “Yes”, the answer is essentially longer – “First, we evaluated everything we need from the role, simplified it according to the tasks and prepared everything necessary so that even a beginner RP could perform it.”

It is not the name of the role that is more important, but the content. You can call it as anyone is more familiar with – the Project Manager, those. lead or something else is a matter of convenience and the chosen glossary.

PS Not “miniRP”, please 🙂

Similar Posts

Leave a Reply