Where to start in a new place (memo for the Project Manager)
It looks like a RP starting a new job is like a passenger who is trying to jump onto a train while it is moving, so that he can then get to the head of the train and begin to control it. And the faster the train flies, the more difficult it is to jump on it. Well, you have about 2 weeks to do everything. 4 at most, if the place is vanilla and the train has not yet accelerated.
How not to break your neck and not get run over on this glorious path – step by step below (pay attention to the sequence, it is important. Changing it can lead to unnecessary risks).
Steps
Zero and most important: don't promise anything to anyone for two weeks. If you are under a lot of pressure – a week. We just say: “I'm just getting into it, I can take a look, but I can't promise” In the first week or two, you can say this to anyone, even your GM: this is reasonable and careful, you don’t interfere where you don’t know.
If they put pressure on you and demand a quick solution in the first week, this is a reason to seriously think about the adequacy of those who are putting pressure on you, and whether you need to stay here at all?
There is also no need to wait longer than 2 weeks: a normal manager should not be slow-witted. 2 weeks should be enough for you to understand the base of the project.Talk to your immediate supervisor. What does he expect from you, what is priority, etc. If he tells you terms and deadlines within the next 1-3 weeks, don’t dare confirm them: just listen. It was not you who promised this, it is not your responsibility. But you are an experienced RP and remember that “NO, it's impossible“we don't say, we say”ok, got it, I'll go see what's there“
I highly recommend writing out all your manager’s expectations separately. They are important; he will use them to evaluate you based on the results of the probationary period. If you achieve them, great. If something doesn’t work out, you will need to come up and ask for help. It's not good to forget about this.
Study internal regulationsif they exist. As a rule, a day should be enough at the RP level. If you spend more, you are slow or the regulations are impossible to meet. If there are a lot of regulations, you should only read what is relevant to your work. If there are still a lot of them, don’t hesitate to ask your manager – why are there so many of them, and what should you read from this?
Next we need stick into the project plan/projects or product backlog and technical specifications. This way you will see for yourself the dates, deadlines, stages, tasks, prioritized and delve into the basic functions that need to be done. At this stage, it’s too early to go into the tracker and look at the details. You just need to understand the terms, deadlines and plans for the next three months and the functionality “diagonally” in order to go to the contractor.
After that you are ready for step 3 below.Talk to the performers. This is either your in-house team or a contractor. The purpose of the meeting is to collect information about the progress of things and what problems there are.
At the meeting/meetings, check whether their words correspond to the plan. If something doesn’t match, ask questions right away. Firstly, you will immediately show that you have your bearings, secondly, you will show that you want to understand all the murky topics, and thirdly, you will check the team’s readiness to meet you (otherwise anything can happen).
Collect their pains and problems. Relationships with the team or contractors are almost always a pain point, it is very important to listen to everyone. You come with a clean reputation and can use this credit of trust – they will tell you a lot of things. We also write everything down, nod our heads, and don’t promise anything. But don’t forget: if you just listen and put down the bolt, all the trust between you will collapse before it even begins.
Read the contract. Many project managers forget this point, and it is key. During the meetings, everyone will tell you their deadlines and needs. This needs to be listened to, this is their expectation. But then all this must be settled on contractual obligations. No one will remember your contracts except you. At the end of the day, when the contractor or your client pokes you into the contract, you will be in a lot of pain. For me, such a mistake by a manager is a Yellow Card. Two such flights – the test is not passed, goodbye.
If you are on the integrator side – You must know your contract by heart in terms of functionality, stages, money and penalties.
If you are on the internal IT or product side:
Examine all the suppliers' obligations to you, no matter what they told you in point 3 above.
Review all commitments that have been made to your business in accordance with the processes in step 2 above. Functional requirements, memos, agreed roadmaps – but only those that were agreed upon formally “by law”.
This is your base. You must deliver everything that is formally promised or write it down as problems/risks for change.
Talk to the customer. The main customer is the last one you need to meet. You need to go there prepared, having behind you the results on all points above. Moreover, there may be several responsible persons from the customer; you need to talk to everyone in turn:
RP of the customer, if there is one. It is better to meet with him in person. If he is in the same city, don’t be lazy to get there. He is your main customer, it is extremely important to establish the right contact and understand all his pains and expectations. Same thing – we collect feedback, write it down, don’t promise anything.
Business. Here you don’t need to hold a separate meeting, the business, in theory, doesn’t care about you – well, it changed and changed, “they are new there every time, the main thing is to give the result.” Here you can simply come to the next meeting (collection of requirements, status) to get acquainted. If a business is angry with the IT team, you will see everything yourself, and what you don’t see, they will tell you everything.
Next take a break and process the information received:
The emotional mood of all participants.
Compliance of deadlines in the plan and tasks in the backlog with the expectations of all parties.
Compliance of deadlines in the plan and backlog with contractual and other obligations.
Compliance between the company’s processes and real work (if everything goes beyond the processes, it’s a sign of a managerial mess).
In this place, as a rule, many amazing discoveries await you. For example, it happened to me that the whole team forgot about the contract and worked “by convention.” And the business customer was waiting for the work to be performed exactly according to the contract and the technical specifications in it. The discrepancy discovered in time was corrected.
Next is talk to the previous RPif such an option is available and he was not fired before you. The previous RP is usually a very valuable source of information to ask questions from point 6 above. But it must be filtered very carefully: you do not know the reasons for the divorce, and how dissatisfied the parties are with each other. Maybe the RP did not have enough experience to pull off the project, or maybe he sees all the problems in advance and does not want to participate in this farce. In any case, his opinion must also be listened to and taken into account.
Ugh. All the steps indicated above should take you at least a week:
Manager and regulations
Technical specifications and backlog “diagonally”
Team and contractors
Read the contract
Customer
Processing results, questions
Old RP
In between these meetings you need to:
Formulate questions and prepare for meetings.
Read the technical specifications, study the backlog – to understand what you actually need to do?
If it took less, then one of three things: you were lucky and the project is in perfect condition, you took steps poorly, the project is small.
Then you can get into the details of the project: JIRA, Youtrack, B24, Trello, ClickUp, I-tracker or wherever your team works. Here you will need your analyst (if there is no analyst, then it is you (here we put a tick: RP can be an analyst, but only on small projects (what is a small one – see the footnote below***)
If you are on the contractor’s side, check the presence of features reflected in the technical specifications and the progress on features (I’ll write separately on how to view progress on my channel, and there are a lot of articles on this topic). The task is to understand whether you really have time or not.
If you are a RP on the customer’s side, you climb into your backlog and delve into the feasibility of its deadlines for the next 3 months, pulling your performers.
In this place you can look at burndown, team performance, sprint convergence and other metrics. Well, or understand that there is none of this and write it down as problems/risks – it will have to be corrected.
Next you need articulate the problems and risks you see. There is no need to offer solutions, just a list of problems, a list of risks. With this, you go to the manager and talk through what he considers important and why, and what is not and what to do about it (How to work with Risks, see here).
If the Manager does not have time for this, there is reason to think that there is no onboarding in the company, and you will have to work with a Manager who cannot find time for important issues, substituting himself (do you need it?)
You create a real list of problems and risks with a solution plan and an understanding of where to go next.
Always ASK!! Don’t be afraid to ask, on the contrary: everyone knows that the person who pesters everyone with questions really wants to figure it out. The fool is not the one who asks, but the one who is afraid to ask. Your manager knows that if a new employee doesn’t ask questions, he probably doesn’t understand anything and is afraid. This is a bad characteristic for you. So ask, ask and ask.
That's all in the database. It will take you from a week to three.
Why exactly this sequence is important: because the input to each new step will be information from the previous one. There is no point in going to the customer if you do not understand either the project or the deadlines. It’s stupid to go to the team if you haven’t looked at the terms of reference/backlog and roughly understood what it’s about. You can’t go to the customer’s RP until you talk to your team, otherwise you might accidentally blurt out something not that. Separately, by arranging the steps exactly this way, you will be as prepared as possible for each meeting, which means you will receive the maximum information. This will save time on entering the project (you won’t have to run to everyone a hundred times) and will seem like a professional: everything is clear, concise, and to the point.
What do we get as a result?
With high-quality execution of the steps above, you:
You know the essence of the project: goals, why it is needed, who needs it, expectations from it, main functions and technical solutions, justification of the budget and deadlines.
You see the main problems and risks of the project: technical debt, unfulfilled promises, unfulfilled promises and discrepancy between plans and expectations.
You understand what needs to be done to align plans and expectations.
You understand the pain of performers and what you need to do to make them succeed.
Obviously you understand how realistic the deadlines and planned budget of the project are.
And this is what you need to sail into a bright future without fear with a ready-made plan to eliminate problems and risks (well, or go to the test with the words: “Are you all crazy here?!”).
*** – a small project where the RP can act as an analyst – up to 10-15 people. This can be one project for 15 people. or three times 5, but more – almost certainly not.
Good luck to everyone on new projects!
