Is it true that PM does something useful and what it takes to become

An interesting observation: we hold seminars for project managers inside the company and periodically invite key technical specialists there - architects, designers, team leads. At first they come rather reluctantly, sit for about an hour and suddenly begin to write down and ask questions. At the end of the day, something like: “And I thought you were idlers and ghouls, but it turns out you have a hard and responsible job.” Such training helps team members to understand each other better.

For more than 10 years in various positions I have been involved in project management. He worked in four major integrators and is now heading a department of 100 people. During the time of work, which projects did not have to be managed: they implemented SAP, automated the activities of enterprises, developed ISs for state customers, designed and built unique data centers, made military ROCs, carried out complex migrations of IP ... even built turnkey power plants in Belarus and coal boiler houses Chersky (2000 km from Yakutsk). The main difficulty then was the delivery of equipment and materials - the river was passable only 5 months a year. Got out for deadline or just caught a cold year - lost 7 months. Or an expensive helicopter. All projects are different, and each is unique in its own way.
')
Your team wrote a curve code, dropped the server at unloading, the equipment did not come on time, the customer delays acceptance, technical requirements change greatly, and the time and budget are not ... All this is PMA headache, and this is only part of his work.
But the main thing is personal responsibility for the final result!

What levels does the project manager work on?

For ease of understanding, I use a simplified "technological pyramid." The division is rather conditional, but it helps to explain many complex things on the fingers.

1. Business goals are the top of the pyramid. The level where specific business goals are formed. For example, “the loan from the time of application by the client must be approved and issued by the bank within 15 minutes”.
2. Process level - how to build / restructure processes within an organization in order to achieve business goals.
3. Application layer - automation, software and its architecture.
4. The level of infrastructure - architecture VC, storage, database management system-wide software.
5. The PDS layer is the architecture of the data transmission network, including the SCS.
6. Engineering level - electrical, ventilation, water supply, access control, video surveillance, air conditioning, etc.
7. Construction, or "level of concrete" - which building, where, what breakdown by premises, etc.
8. Security - passes through all levels. At the bottom of the pyramid is physical, at the top is informational (regulations, regulations, policies, etc.).

This is a model by which absolutely any complex project can be expanded with some assumptions. Management of implementation at each of the levels described above has its own organizational and technological specificity, which requires certain skills and knowledge from the PM.

For example, the construction of a power plant and the development of software are radically different projects. Different management methodologies (PMI, Agile, Scrum ...), different role models of the project team, organization of communications, guaranteed different financing models, etc. Each project has its own personal approach. Universal knowledge does not happen, but there is a universality of the approaches used.

There are projects that cover only 1 or 2 levels (for example, upgrading a corporate data network, developing small software). And there are those that cover all 7 (for example, "Safe City"). They include consulting, software development, building construction with engineering systems, and, of course, IT. Such projects require special training and accumulated experience from PMA. One of the key tasks of PMA on such projects is always a set of key specialists and the proper organization of the work of a large team.

Knowledge of the specifics and the ability of PMA to work at each of these levels make it universal and determine the degree of professionalism.

What controls the PM on the project to achieve its goal?

First, the answer to this question does not cause much difficulty, and many quickly recall that there is a budget, time and quality. Then, after some thought, people remember that there is a team and risks. This fantasy quickly ends. But the main stupor occurs when you ask to describe: “How do you do it? How do you manage this all? ”

As practice shows, even the most seemingly simple categories of project management, which we often use in everyday life, cause difficulties not only among the key members of the project team, but also among the PMs themselves.

Budget management (cost)

As the classic said, “any problem can be solved if there is enough money and time.” In part, this is true, but in the current market conditions there are nuances. The market is shrinking, budgets of customers are being cut, competition is growing ... In the struggle for survival, the market forces IT companies to act aggressively, to participate in projects that were previously considered a high-risk area, for example, when a company does not have enough experience and resources.

Increasingly, you can find situations when a competitor enters the competition who has never been an expert in such projects, and gives a price lower or close to your cost price!

What is it: total planning mistakes, clear calculations and deliberate dumping or death agony ?!

The role of the PMA and the management group on the presale has increased dramatically. Quality work at this stage is half the success of the project. Clearly determine the cost and optimize costs, assess the availability of resources and the availability of the necessary competencies, choose the right implementation strategy and develop a financial model of the transaction, assess the risks and financial strength in the event of a competitive struggle - and all this in a short period of time. It is extremely difficult to organize such training in a short time, but this is the main task of the PMA at the pre-sale stage so that further implementation will be successful.

Time management

The beginning of the project is the highest point of uncertainty. You can reach the end in different ways, but the task of the RP is to choose the best route and pace of movement. There are a lot of nuances that need to be taken into account on the way.

Why is the shortest path not always optimal?

For example, I can work 12 hours a day, seven days a week, and I can incline all other project participants to it - but they will simply not be ready for this, especially the customer. I need access to the site or to the systems at certain hours, and the customer has a special procedure for this. Downtime is needed, and the customer has a business-critical system - and he is ready to agree to a shutdown, but only on the first Saturday of the month at 22:00.

In general, quite often the customer is not ready for the chosen tempo of the performer. This is because the implementation of a project for customer specialists is often not the main functional activity, but an additional burden on behalf of the management. To discuss technical requirements, analyze documentation, test the code, make the necessary system settings faster than the main activity allows it, the customer will not be able to. And if you even succeed in forcing him to do this, then the negative and mistakes simply cannot be avoided. And there are also nuances in the work of contractors and vendors. But the most difficult and unpredictable is the interaction with government agencies, especially for security officials and regulators. It is simply impossible to make them work quickly, and they are most often on the drum for your project. But this is a separate story, there are some nuances, not in this article about them :).
It does not make sense to “overclock” the project only for the sake of the soonest possible completion.
Ditch your team, allocate a lot of "heat" and spoil the relationship with the customer.

All this is called "assumptions and limitations." At the start of the project there are most of them, since the degree of uncertainty is higher.

And the work plan is a living quantity, and the process itself is creative. Somewhere did not meet the deadlines, the delivery did not come on time, made a mistake in choosing a solution, the customer changed the requirements - all this requires a revision of the schedule and budget of the project.

Quality control

One of the parameters that causes the most controversy in the professional community. On the one hand, everything looks quite simple: quality is compliance with the specified parameters / requirements. When there is a technical task and all requirements are closed, it is possible to consider the implementation quality. But is it?

And what to do when, at the first meeting with the customer, you suddenly found out that his expectations are very different from what you were going to realize? Are requirements and expectations the same? And why did they suddenly become different: want one, demand another? I often ask these questions at interviews, and, oddly enough, even experienced PMs float on them. It doubly saddens when you have a PM, leading the development.

For illustration at the trainings, I give an example. At the dawn of my IT career, I made a website for my spouse. I found a designer / developer, reviewed a million sites and, it seemed to me, clearly understood what I wanted. When asked about the requirements, he confidently announced: beautiful, modern, convenient, scalable - and a lot of things like that. The developer listened and said: “This is all cool. And what are the requirements? Which engine, which admin panel, integration with payment systems, structure, etc.? ”Naturally, I couldn’t answer - it was my first experience and the first site. Now I can, but only because it has passed more than once.

I exaggerate, of course, but with similar requirements the customer often enters the competition. And at the first meeting, it turns out that he did not want what he wrote in the TK. And if nothing is done with this, at the end of the project everyone will have a big “surprise”, swearing, long and dreary acceptance. Constructed according to TK, but not in the way the customer wanted; the system works, but does not meet its expectations; current needs are met, but not laid stock for scaling, growth, integration. And there is nothing to show: as written and built. Nobody knows what to do next, especially when there is no longer any budget for revision. Dead end, upset, damaged relationships with the customer ...

Experienced PM knows how to work with such situations. They most often occur in the upper part of the pyramid, especially when the customer introduces something for the first time or creates a product, on which developed characteristics there is no user feedback yet.
One of the main objectives of PMA in such projects is to make expectations and requirements converge in the course of the project.

In projects with software development help modern and increasingly popular methodologies Agile, scrum, etc., implying a deep involvement of the customer in the project, as well as short sprints with the demonstration of working functionality. The contractor with the customer are in constant dialogue in the spirit of “Are we going there? Is that what you wanted? ” This allows you to always move in a given direction and minimize errors. Contrary to popular belief that the same agile is good always and everywhere, I simply note that there is not much that is better for a military ROC or a civil engineering project cooler than the classic "waterfall". This is how the system works. Each methodology has its own scope. This is not a religion, it is tools that allow you to effectively manage the parameters of the project.

For example, when the requirements on a project are not sufficiently detailed (their interpretation allows for greater variability) or their refinement is implied in the course of the project, the “prototyping and sprint” methods are very good.

When the requirements are clearly defined, there are strict requirements of regulators and control authorities on the phasing of implementation, the implementation involves the use of GOSTs and legal documents - classical models work well, such as waterfall.

Management of risks

With risks, too, everything is not easy at all. Despite the fact that many books and articles have been written on risk management, managing them effectively is not a trivial task. In fact, we are trying to predict and evaluate events that are purely probabilistic in nature and specifically in your project may never happen at all. And they need to be identified, classified, qualitatively and quantitatively evaluated, a response strategy developed, monitored, revised ...

In fact, this is a complex and multifaceted process, in which the participation of PMA alone is not enough, we have to call on the help of colleagues. Despite the fact that various methodologies of categories and subcategories of risk classification offer countless methodologies, in practice most companies use the most intuitive and simple to evaluate. Rarely, among IT companies, the risk management process is brought to a fundamentally different - advanced - level.

The key participants of the project team and the services of the company attracted by the PM usually take part in the risk assessment. In practice, the separation usually looks like this:

1. Organizational and methodological - risks associated with the organization of work and areas of knowledge managed by the PM. Area of ​​responsibility of PMA and project office. Technological - risks associated with the solution architecture being developed, technologies used, etc. Area of ​​responsibility of the architect and key technical specialists of the team.
2. Financial - everything related to accounting, meeting the requirements of regulators, used financial models, etc. The area of ​​responsibility of accounting and treasury.
3. Legal - risks associated with the current legislation, regulations, the requirements of the clauses of the contract, the rules of coordination with supervisory authorities, etc. The area of ​​responsibility of lawyers.
4. Specific risks are usually those associated with industry specifics or requiring highly specialized knowledge. Here, depending on the project, from time to time it is necessary to resort to the help of outside experts.

If the assessment is made qualitatively, then such a division is usually sufficient to avoid the most critical risks.

The easiest is with risks that we know about in advance. We know it, because some of them lie on the surface, and in part there is accumulated experience from previously implemented projects. They are commonly called "known risks." Such risks are easy to analyze and you can pre-plan the response (response strategy). More difficult when the project, for example, is implemented for the first time. There is no accumulated experience, and their competencies are not always enough. In such projects, we may not even be aware of the presence of certain risks, and if we assume their presence, we are not able to assess correctly. In such situations, only the reserve for unforeseen expenses and the expert assessment of the team saves.

The “maximum task” in risk management is to ensure that no event occurs that could adversely affect the goals and indicators of your project. But it is almost impossible. Part of the risks will always be external to you, and your influence on them is extremely limited. And the larger and more complex the project, the greater the likelihood of one of these events. Therefore, the main task of PMA will be to minimize the consequences of their occurrence.

Risk management is a continuous process throughout the project. A big mistake when it starts simultaneously with the project itself. The time for evaluation and the “place for maneuver” are sharply reduced. I saw situations when planning mistakes and triggered risks not only devoured the project margin, but also heated the project together with the company. It is right to start this process at the stage of deep pre-sale, in advance of the decision to enter the project. This is especially true in the current market situation, which I wrote about above, when the company enters new, unfamiliar projects with stringent requirements from customers and regulators. The result of the pre-sale risk assessment in such projects may be the decision of the management group not to go into this competition at all.

Such a decision within any company is always difficult, because there is an internal conflict of interest within the team. This is the very edge when the “greed” of sales divisions struggles with conservatism and “fear” of production. In companies with mature management and business processes, such a conflict is even useful, because the truth in a given dispute is always somewhere in the middle. The main thing in such disputes is the presence of an arbitrator, so that in cases of heated debate not to cross the line, when a measured and conscious risk turns into adventurism and a lottery.

PM professionalism

Unfortunately, many are sincerely convinced that the professionalism of the PMA is measured by the amount of time spent in the profession. I think differently: experience, knowledge and skills. The more of them - the more professional PM. Practical experience gained in real “combat” projects is invaluable and is a competitive advantage. Of course, no one is immune from mistakes, but, as they say, "for one beaten, two give no beaten." Having collected all the rakes in our garden with your forehead, you are unlikely to step on them again.

Choosing PMA for a specific project, I draw attention to several parameters and use the same “technological pyramid”. For example, if you need to build a building and get an engineer there, I will give preference to an experienced builder, and if you upgrade IT, to an experienced infrastructure worker. Knowledge of the technological and industry specifics, contractors, pitfalls, a well-established team helps to avoid unnecessary mistakes, save budget and time.

To my team I try to take the most versatile and independent PMs. Able to work effectively at all levels of the pyramid, as well as in conditions of high uncertainty. Much attention must be paid to the personal qualities of the PMA and its intrinsic motivation. It is important that a person quickly join the team, get comfortable and be “comfortable” for the team. Good specialists in the market - a big shortage.

If interested - ask questions, I will answer them with pleasure. I will try on examples of specific projects to tell about different non-standard situations and how we got out of them.

The text was prepared by Yuri Korchukov, a project manager and deputy director of the Technoserv engineering competence center.