"Not Harmful Advice for the RP". How to Prepare for a Meeting with Voldemort and Protect Yourself from Dementors in the Project. Part 1

Dedicated to those few who crossed the fine line "go grey or become an alcoholic". Or as it can be called: "launched the project DESPITE, not because of". — Dedicated to those few who have overcome the fine line between “going grey or becoming an alcoholic”. Or as it can be called: “launched a project DESPITE, not because of”.

This is an anti-article for those who have encountered “pitfalls” and double standards in project management and for those who want to learn about it. Get tips on “hidden pitfalls” and traps in Voldemort's dark forest before entering it, and also prepare for a fight and be able to defend yourself.

This article is for those who are not looking for a “vanilla bravado” success story. And for those who will have to experience all the “delights” and hardships of launching “turnkey” projects on their own skin. To go through fire and water, so to speak. To overcome the barriers of interaction with inadequate customers, toxic stakeholders, “double standards” of management, “royal detachment” of security personnel and sabotage of key users. This article is for those who are immersed in the fascinating world of “project management” or have long been swimming in its wastewater.

A small remark. Yes, I have witnessed “vanilla” projects. These are the projects where there is full support from the management, there are clear project scopes, there is a good “semi-elastic” budget. And there is also a clear team of professional performers and equally clear and interested Customers. Where everyone works “as one team”. Where there are clear requirements (and the Customer really understands them in detail). Where there are professional developers and contractors (working for more than one year and able to understand at a glance what is expected of them). Where there are no “obstacles” and obstacles in matters of coordination with information security and in matters of transfer into operation and technical support. Where the project manager has a “real” control lever in the form of authority to influence (force, demand, escalate and fine) all project participants without exception. Yes, yes. Such projects also exist. This is the ideal world “in PMBOOK style”. This is a rosy world of “funny ponies and butterflies”. Many books and articles have been written about such a world. So, in this article we will not talk about them. And not about those project managers who were lucky enough to launch such projects (and they actually won’t understand what I’m talking about).

So, let's go in order, so to speak, from the very beginning…

Zen #1: “Understand who in the company's management needs this project and whether he is ready to give you Harry Potter's magic wand”

The very first thing you need to do is to understand who personally from the company's management needs this project. And to what extent is he ready to defend his project and defend you, as the head of this project.

Get real support from the company's management. It will definitely come in handy when you encounter your first problems.

And we are not talking about a formal answer “of course it is needed”. The questions need to be asked more broadly and specifically:

How strongly and why does the company's leader personally want to launch this project?
Is he ready to personally get involved in solving the project’s problems and not get irritated by your endless escalations?
Is he ready to increase the project budget if suddenly in the middle you realize that you forgot about some important requirements?
What will be the consequences for the manager and the company if the project is not launched?
What powers of influence on the team is he ready to give you personally, i.e. what power to bestow?
Is he willing to support you in a situation where your professional arguments diverge from the arguments of his subordinates?

Try by hook or by crook to get answers to these questions before you take on the project. This will be the “leverage” that you will use on the project.

Interest and real support of the management is half the success. And your powers are the very “magic wand of Harry Potter” that will allow you to influence the “dementors” and protect your unicorns. Your leverage should allow you to cast at least two spells: attack (Avada Kedabra) and defend (Expecto Patronnus).

Clearly understand what controls you have, whether you are able to withstand threats and protect yourself and the key project participants on whom its success will depend.

The most unpleasant thing is if you were unable to get the desired answer to one of these questions. For example, you were clearly not given confirmation of support or carte blanche from the company's management..

Zen #2: “Don't rush into a project if you haven't been given real control. Look around, immerse yourself in its details, buy time to evaluate before agreeing.”

This feeling will be similar to when someone shoved a sour lemon (project) into your mouth without sugar. Your face twisted, drooling, and you want to spit it out. But they are looking at you and you can't do it. So you start smiling crookedly, slowly chewing the lemon shoved into your mouth, and reassuring yourself with the thought that “this is good for you.” If this is the case, then you are entering Voldemort's dark forest.

So, you've encountered the first unpleasant moment: you've been given a project that is poorly supported by the company's management. Or you haven't been given effective leverage (the palisade of instructions and regulations on committees doesn't count). Or the project has a very vague scope of requirements and there's no way to increase the budget at the finish line. Especially when at the testing stage someone suddenly starts raving with the words: “I talked about this at the very beginning, but they didn't do it and without this the project can't be launched.”

Don't despair. You can successfully swim in this environment too. Try to find out why and for whom this project is being done. In practice, I have sometimes encountered projects “for show”. This is a very specific example, when a project is done, for example, for image or to close audit requirements.

Zen #3: “The most successful project is always the one that won't be used.”

In other words, you need to find out who will use the results of this project. Sometimes it turns out that projects are done “for show” for 2-3 users. If so, then you're lucky – catch your luck by the tail. Start actively communicating with them and immerse yourself in the requirements personally and deeply. Agree that communicating with a couple of people is much easier than organizing complex processes of collecting requirements among a dozen different departments. Feel free to take on this project, but adequately assess its risks, deadlines, volume and resources. Then everything is classic.

Why are these projects often the most successful? Because they are likely to have little or no negative feedback and can be resolved fairly easily.

But let's imagine that this option didn't work either and the “vanilla” scenario didn't happen again. Don't panic and don't make hasty decisions. Before taking on such a project, try to understand it as much as possible: where it came from, who is promoting it, who needs it, who you will have to work with, how professional the team is on the Customer's side, how professional the team is on the Contractor's side, etc. Collect as much information as possible. You can fairly say that “I need to collect more information.” Why is this necessary? To gain time to prepare and offer your terms.

If it becomes clear that this is not a project “for show”, that several departments are involved in it and many employees will use it, then you can safely say that you are launching the game in “Hard” mode. And considering that you were not given Harry Potter's wand, your level of magic, agility and strength is lower, and the enemy is stronger and bigger. And you can't deal with him with ordinary “skills”. You need to be smarter and think through a strategy. But first, understand – why do you want to enter this lair of professionals pumped up to the teeth? Is your character ready for an unequal fight and what bonus will he receive by completing this mission?

Before you take on a challenging project, clearly assess your strengths, potential challenges, and the expected reward for your courage. Assess your abilities and desire to overcome obstacles for the sake of this reward.

Zen #4: “Understand why you are taking on a project that can ruin your karma”

This advice, which seems simple at first glance, hides a deep meaning. Imagine that the project is “ON FIRE!!!” We are not able to deliver on time, the Customer is adding fuel to the fire, the Management is unhappy, demands “realistic deadlines”, and you (Project Manager – PM) do not understand how much more needs to be done and whether the budget will be enough. Sound familiar? Yes, yes – this is a typical project, where the “honeymoon period” has ended and “everyday life that kills love” has begun.

All these vanilla meetings of the category: project start, team formation, collection of initial requirements, approval of the charter with the sponsor, creation of a project plan, kick-off, etc. have passed. And then the “hardcore everyday life” began: deadlines, failure to meet deadlines, lack of resources, budget overruns, Customer's claims for lack of control, Management/Boss's (cross out as appropriate) claims for poor project planning, Sponsor's claims for poor budget planning, Management Committee's claims for poor risk and requirements management. In short, pre-wedding promises of “I will carry you in my arms all my life” did not come true and everything is going to hell, illuminated by the bright flames of the boiling cauldrons of hell.

And then everyone misses one simple question:
“And what is the motivation of the RP to continue to burn in this hellish flame and, in spite of everything, drag the project to success?” Be prepared for such an option, like a samurai who is always ready for death.

Play out a possible negative scenario in your head. A real project manager should always be prepared for it (like a samurai). Decide for yourself whether the future reward will motivate you even if the project fails?

From the outside, the motivation of the RP can be described as “a sadomasochist's pleasure in suffering.” And the desire not to let the project fall apart can be dictated either by fear (losing a job, losing a bonus, not paying a mortgage, losing a reputation) or an iron will (here I have serious doubts, since from a psychological point of view, “will” is the other side of fear, clothed in noble motives).

I myself, being a RP, found myself in a similar situation. And I will honestly say that only the project bonus, which was clearly defined for both positive and negative scenarios of project completion, kept me from the temptation to quit such a job. Other aspects and arguments work very poorly or weakly.

The project can be compared to an airplane that takes off in one city and must land in another. And the RP is the pilot and navigator. During the flight, the airplane may catch fire. Is it the pilot's fault or the weather conditions? It doesn't matter. The only important thing is that the airplane must land at its destination. Why do airlines reward pilots who managed to land a burning airplane?

Zen #5: “Agree on the size and rules for calculating your future project bonus “on the shore,” while you haven't yet entered the boat crossing the River Styx.”

Our world is subjective and people's attitude to your results is also subjective. You can toil like a “galley slave”, but the final result may be unsatisfactory for the management. This is a strong demotivator and it should be compensated by adequate benefits, which the RP is guaranteed to receive even when he lands a burning plane at the destination, albeit late, albeit over budget.

Demand guarantees and terms for payment of the project bonus. Make the bonus amount dependent on the amount of delay or budget overrun, but insist that it be there for both positive and negative outcomes. And it’s best to record this on paper or in the form of a letter of guarantee.

Agree on the amount of compensation before the project starts. At this point, you are still untainted as a RP "fuckups"and your negotiating position is the best. After the project is launched, it will inevitably weaken, and the probability of agreeing on a bonus will tend to zero. — Agree on the size of the reward before the project starts. At this point, you as a RP are not yet tainted by “fuck-ups”, and your negotiating position is the best. After the project starts, it will inevitably weaken, and the probability of agreeing on a bonus tends to zero.

Some are embarrassed to even ask for this (let alone fix it on paper). And in vain, because when the project starts to smell like burnt wiring, there will be no time for embarrassment. And the presence of this letter of guarantee will dampen the ardor of criticizing you too much – everyone will understand that the presence of direct financial motivation forces you to look for any possible way out, so as not to let the project go into a tailspin or explode in the air and not reach its destination.

Okay, let's go further into the roots of the dark forest. Let's say that you showed courage and really made an attempt to declare and negotiate a bonus. You may be refused or given a condition that the bonus will depend on how you show yourself. In other words, greed won in the negotiations and they did not listen to you. Do not despair. You can calmly answer that “you need a little more time to make a decision.” And start probing the stakeholders on whom the success of the project will depend.

Zen #6: “You need to know your enemy by sight: identify all possible blockers of your project before the start of the project.”

What am I talking about? That BLOCKERS can be not only Customers.

They could also be information security, which will wake up at the end of the project and, “like an ace out of the sleeve,” pull out such requirements that their implementation will require doubling the budget (which, as we remember, they refused to make elastic).

This could also be infrastructure maintenance, because additional investments will be required to ensure backup, fault tolerance, and additional server resources (I have even encountered statements that there is no more room in the server room for new servers, so the issue of purchasing a new rack, with the landlord for the allocation of new space, etc., etc.)

This could be technical support and operation of systems, which suddenly generates such a huge list of documents (regulations, provisions, all possible instructions) that were simply not included in the budget and their preparation requires another X weeks and an indecently large amount of money.

Understand stakeholder requirements and potential blockers before the project begins. You need to identify all the dementors and understand what requirements they will have for the project. Build a strategy for going through their requirements in advance

Show healthy initiative. Go to other project managers and ask them what blockers they have encountered. Ask for friendly advice, maybe they will suggest something valuable and useful. “Take note” and write it down – this will be a list of the people you will go to first.

Can you already guess why? To tell them about your project (which you are preparing to lead) in advance and ask them to formulate a list of requirements without which the project cannot be skipped. Make sure that these are written responses, which you will carefully put in the “Dementors” folder and you will understand in advance what to prepare for. And if one of them then formulates new blockages in the form of their new requirements for your project, then just get their letter and, apologizing, say that the project assessment was based on the previously received requirements. You would be glad to change everything, but the requirements were recorded and included in the assessment, and there is no budget for new requirements. If something else needs to be done on top, then this is exceeding the scope of the project and you need to go to Dumbledore (company management) together and justify these new requirements. As a rule, after this, half of the requirements often evaporate.

Now it's time to take on the project. You've already found out a lot and know a lot. Everyone is waiting for you to announce that you're taking on this project (well, of course, since you took the time to “analyze the data and make a decision” twice). How do you do it right?

Zen #7: “Record all goals, restrictions, powers, levers of influence, requirements, participants, risks and agreements in the Project Charter. Only then announce that you are ready to launch it.”

The Project Charter will be your insurance against unpleasant accidents. Show maximum respect for this point and maximum effort in its preparation. Try to move away from the classic templates of the Charter. They are useful at the beginning, but this is “C” knowledge. Real excellent students should skillfully insert additional points into the Project Charter that insure them against “fuck-ups”. As well as points that clearly record the requirements of all dementors (blockers) and set the correct route through the dark forest of Voldemort.

Turn on your imagination. You are preparing your insurance. Insert into the Charter all your available opportunities to influence the project participants: write down all the spells available to you that you HAVE THE RIGHT to use with the magic wand given to you. And also note the consequences and boundaries that the dementors cannot go beyond in their inexhaustible desire to attack you at the finish line, when you are exhausted, with low karma, surrounded by the best enemies, half-dead, dragging your project to the finish line.

Reflect in the Project Charter all the points that protect you, your project and your team from failures

Get the Project Charter signed by everyone, absolutely everyone, who can be related to it in one way or another. From the company management to the technical support, who will have to support your product later. Signatures on the charter are the last and most important spell you will have to get. It will save your RP skin in a difficult hour.

Make the Charter the “Bible” by which the “Flock” of your project will live. Become a preacher who will constantly quote lines from this Bible, guiding lost souls to the true path.

The more often you appeal to the Project Charter, the better. Do it every day at every opportunity. And even if the project fails (and we all hope for the best, of course), you will have a very cool ace up your sleeve.

The Project Charter must be signed by the Company Management interested in the project.

I tried to describe the minimum that needs to be done to start a project, so that in any, even the worst-case scenario of its development, you, as a project manager, feel confident and do not lose motivation to drag your project further.

Even if it is a burning plane, it still needs to be brought to its destination and landed on an equally burning runway.

Good luck to you, my friend!

And if I get a lot of likes, I'll make the next part…. To be continued……..