One model to manage IT projects and our long way to it
Greeting! My name is Oleksandr Apazidi, I manage digitalization of head office processes at SIBUR. Today I will tell how we brought IT projects in a huge oil and gas chemical holding to a single model, tried to reconcile Agile and Waterfall, and in general, speed up the implementation of projects. It’s a bumpy topic, so buckle up and let’s go!
Few numbers: from 2021 to 2022, the number of our IT projects increased from 70 to 200. With such volumes, we cannot do without portfolio project management, so we started with a single project management methodology and implemented a single gate model with 5 steps: Idea-Verification-Hypotheses -Design-Implementation-Monitoring (we call them L1-L5). They we partially copied the P3.Express approach.
I will make a caveat just in case: there is no “correct” project methodology that is guaranteed to lead to its success, because projects always go beyond standard models. At the same time, there are some techniques that help improve the project. One of them is cyclicality, which is clearly presented in P3.Express. Its essence is that if you make some tasks of the project manager regular (and cyclic, yes), then most mistakes can be avoided.
We applied this technique in transformation projects – introduced regular synchronizations, meetings with the team and single responsible persons, invented a role model of the project.
In general, instead of fully implementing any framework, it is productive to test individual steps. For example, another postulate of P3.Express says that the whole team should plan the project, not one project manager.
After the first such planning in one of the projects, the results really impressed us, so we decided to do it constantly. Now, once a quarter, the distributed team of this project conducts field planning, plans the next quarter in detail, conducts a retrospective and mini team building.
Thanks to this, everyone has an understanding of what the team is doing in general, and why such deadlines have been set. This, of course, costs travel expenses – but the costs are repaid by the effects of project acceleration. In the mentioned project, applying one of these practices allowed us to pull the project from the maroon zone to the bright green one (I haven’t mentioned our color coding yet, but it’s kind of self-explanatory :)).
Now we return to the level of hundreds of projects. Since they desperately need competent management, we came up with the idea of applying some kind of soft power, in which there is no active pressure on the project managers, but at the same time they understand that there is no less control, and they try not to stretch the deadlines.
Thanks to this idea, our main metric – the percentage of projects closed on time – is holding a strong mark. The mechanics are surprisingly simple: when project managers realize they’re running out of time to complete a project, they need to get confirmation of a deadline extension. Such a practice had not happened before, and the effect exceeded expectations.
Then we started to connect technical means to the soft power that collects project statuses. Thanks to the implementation of a unified system of storing knowledge about projects, we can combine all important metrics and draw conclusions about the implementation of the project without unnecessary questions to managers.
And yet, deadlines are an eternal pain in any project. Therefore, I will tell you more about them.
How we dealt with the terms
First, we looked at how and why deviations occur. We set the task not to control the deadlines at the last moment, but to understand the problems and risks of the projects. We looked at the departments with which typical problems arise, gathered the heads of these departments and began to conduct a review with project managers every week. These roars were checked in detail by status.
In a month, they had time to examine the entire portfolio, and then they started a new cycle of the month. After applying this practice, we realized that there was a lack of more accurate and objective information, so we decided to extract from each project-related process any data that could be used to suggest where the problem arose. For example, if we are talking about procurement, then the metric is the timeliness of submitting a procurement application. So we went through all the regions, and we have eleven of them.
The data allows you to make a “health map”, and the map – to monitor only projects that have problems in some areas. Moreover, problems will be seen not only by project managers, but also by heads of departments. For example, if there are frequent failures on the part of information security, the head of this department will need to be informed about what is happening. So we not only look at information about the portfolio in general, but also help colleagues assess the health of the process.
It’s a good approach and our colleagues in related functions liked it, but it was extremely time-consuming. Therefore, they began to think about how to simplify the process so that it does not become another formality. We agreed on a target vision, when the project manager reports on a specific metric or a specific action, and we highlight problem areas.
It is important to emphasize that we do not get into the organization of work within the project. Usually, we only offer the project manager a set of tools with which he can build internal processes. We dive into it only when the project falls into the red zone. Then we include daily meetings, weekly statuses for all stakeholders and other practices with P3.Express.
In the red zone, the project manager often reports that he is not doing well at the last moment. For such projects, we have identified eleven metrics that cover all areas related to the project – this is our predictive diagnostics.
For example, if the project manager planned the work of five people for the next week, and in fact twenty hours were written off instead of two hundred, then this will be immediately visible in the “Writing off” metric, and the manager will have to explain the discrepancy. Thus, every manager knows that any mismatches will be visible and tries to minimize them.
Our key metric is the percentage of projects that close on time. It can be called artificial, because it is not aimed at business value, but so far so. We managed to raise this metric from 61% in 2020 to more than 90% last year.
It would be logical to move away from this metric at the next evolutionary turn, because we need to measure the value that the project brings to the business. But we also have projects that do not bring direct quantitative effects, so the calculation of metrics should also be adjusted. It can be a set of indicators: on-time performance, effects, employee NPS, customer NPS, and others.
How zealously we went to all this
So that everything described above does not look like an easy achievement of mega-successful superheroes, I will tell you honestly how we arrived at a single gate model of project management after years and many obstacles.
Lean approaches began to be implemented at our enterprises in 2016, and in 2017 a digital transformation program began, for which a separate function was created in the company. Then we encountered an internal cultural contradiction: colleagues from “old IT” with competences in 1C, SAP, MES and other enterprise solutions were with a separate legal entity from “new IT” with in-house development on .Net, Java, Python, etc. Even the dress code rules were different – some IT specialists wore suits, others wore hoodies and beanies.
These cultural differences, of course, made it a bit difficult to work in digitization projects. In addition, by 2020, these projects began to produce attractive effects, the company moved from point initiatives to the digitization of end-to-end processes, and the total number of projects with an IT component increased to 70. To be honest, we did not really invest in deadlines then.
But at the same time, in 2020, all IT was united in one SIBUR Digital. And, surprisingly, this quickly “reconciled” the cultures – the united teams began to exchange experience, and it turned out that the javaist was interested in communicating with ABAPers and learning about their best practices (at the same time, it became easier to make integrations). So, the problem with the contradiction of cultures was partially solved, but it was still necessary to work and work with project approaches.
With the appearance of SIBUR Digital, we began to combine the product and project environment, to create a single project office for everyone, regardless of the methodology. We even saw it as a project service that any team and any pain could come to for help.
That is, before the teams had either Waterfall or Agile. The third is not given. You come to the product team, and they tell you: “Listen, we are True Agile, we work according to the standards adopted in the industry. Here we have sprints, this is the only way to work. You come to another team (in suits), and they tell you: “Listen, we’ve been working on long functional and technical requirements all our lives, let’s do it like that.”
kick the impetus for changes was provided by the increase in the number of projects – in 2021 there were already 140, twice as many. Therefore, we divided all projects into portfolios that belonged to business areas and introduced common goals for project initiators from the business side and the IT team. Since the bonus depends on it, the teams got an incentive to interact productively instead of throwing the hot potato of tasks. And it began to bear fruit!
In parallel, we were experimenting with the P3.Express methodology and it was not bad, so we scaled it to solve the problem. In the process, of course, we had a million discussions, but as a result, everyone came to the same opinion: why argue, IT is standard work in sprints. Sprints also worked well in Waterfall projects, and even better than in classic products.
But by 2022, the number of projects increased again, and a backlog unexpectedly accumulated over the years with 2,500 change requests from users for various systems (primarily production ones), which we call ZNI (change requests), surfaced.
We had to redesign the entire process of these requests and abandon them in favor of organizational projects with proven effects, limited deadlines and budgets. Such projects are validated by managers from business areas, so they are definitely needed by the company, unlike most ZNI, which after implementation were not used by the user or were opened 1-2 times (although during idle time they were, of course, needed very urgently).
All in all, by this point we’ve learned how to manage project portfolios and even deliver them on time, and that could be the end of the story and digress, but there’s always, ahem, room for improvement in project management.
This required decisive action and implemented a new organizational model, inspired by Spotify’s experience. We formed unified teams in functional directions, so that IT specialists who most often worked on projects and products for the digitization of procurement, for example, or corporate processes, stopped switching to other directions. This facilitated the prioritization of tasks and projects within each direction.
What can be concluded from this, if we limit ourselves to one? Do not be afraid of evolutionary development, even if you are in a large corporation!
All the practices we implemented are widely known, but if we tried to implement everything at once, it would resemble a caricatured “agile revolution”, which often ends in disappointment (and memes). We implement improvements step by step, and in 3 years the level of project management has risen, albeit gradually, but surely.
I hope our experience was useful! I also invite you to share your recipes for managing IT projects in large companies in the comments – I’m sure there will be a lot of interesting things 🙂