A Junior Project Manager (PM) is one of the most controversial positions in IT. It is believed that if you put a person in charge of a project, they must be experienced managers who have grown from Middle to Senior developers and know technical nuances inside out. The thing is that programmers are rather introverts than extroverts, and when there are 10 Seniors in a team, someone must hear them and make a balanced decision. Besides, developers prefer to get promoted to team leaders and CTOs rather than PMs.
As for basic technical knowledge, like an understanding of the Software Development Lyfe Cycle, it’s really a must. We even have a specific course designed for PMs, helping them speak one language with developers. But it is a huge mistake to think that a person who lacks IT experience could be a lame manager. Like in any other career, there are always some flops waiting for newbies.
Guys with different backgrounds come to our DAO PM course and later get their first job, which will be full of ups and fuckups. Meet our IAMPM friends, who are experienced project managers now and ready to share with you their failures in Junior positions.
So, the bravest PMs opened the bonnet doors with their skeletons for us, and we sorted and categorized them into bones to make the reading exciting and instructive. Watch out: fuckups are not always funny, but we aren’t here just for fun, are we?
Part 1. Fuckups while working with clients
Customers are also humans, no matter what they say. And humans are all different: trusting and suspicious, honest and prejudiced, generous and not really. Also, clients come with specific requirements that go beyond good and evil. This is exactly the kind of character that opens our list of challenges for a Junior PM.
Episode 1. When nothing depends on PMs
A young lady from this story is a quite successful IT project manager now, but at the very beginning of her career, one extraordinary customer from Singapore refused to cooperate, not because of her lack of experience in project management, but simply because she was a girl. And here you could say that we are living in the men’s world, if it were not for one little detail — the customer was a woman herself.
Conclusion: Let’s face it, when it comes to the IT market, ageism and gender discrimination sometimes take place. Just get over it.
On the other hand, it’s better to give up on cooperation right away than to work with the client from the next story.
Episode 2. A morality tale
During his junior PM days, one of our friends lost an email where his client had approved a month’s volume of work. The client turned out to be a ruthless businessman who started denying his consent right after a month of working on the project.
Conclusion: Keep records of any step a customer takes on the financial side, as well as the changes and clarifications of requirements. Sometimes it is helpful to keep an onboard log of the project, where you can quickly find information about significant changes and attach screenshots or links. By the way, voice and video call recordings are also great tools for proving your rightness. Just warn the customer that you are doing this in advance, not post facto.
Not all customers are bad. However, sometimes they just can’t clearly communicate their final vision of the product. This is what the third episode tells us about.
Episode 3. When a Project Manager is also in charge of Product Management
This is a story about a brave PM who headed the development team on their challenging adventure in financial service engineering. The customer wanted the product to be able to do everything (or almost everything). While the team developed the functionality, he came up with new improvements and asked to implement them.
— What about adding an accounting module? — The customer suggested.
— Of course! — the PM had already begun to decompose the task into milestones.
As soon as the team added the accounting module, the customer rushed in with a new request:
— I want a module to calculate KPIs for company employees!
— I know who to assign it to! — The brave PM liked this approach — precise tasks, everything clear, and no chances to fail.
Both guys were getting a mutual understanding from module to module, until one day, the customer decided that the world was ready to see his little financial masterpiece. Unfortunately, at this very moment, the project faced the brutal realities of the market: no one wanted to buy such a solution. The product offered a plethora of features but did not solve the problems of its potential users. As a result, the solution died without getting even a hundred customers.
Conclusion: Of course, a project manager does not always have to perform the duties of a product manager. Sometimes outsourcing companies even benefit from the client doing “something important” and paying systematically. But if you haven’t clarified the manager’s role in the process beforehand, it could affect the manager’s and the company’s reputation later.
Therefore, it is better not to tolerate development for development’s sake. Instead, set the primary goal for which the project will be considered successful, a kind of acceptance criteria for the whole project. Then, while performing milestones, you can adjust actions according to the final goal. It is better to fail the plan and make a new one than to fail the project and utilize it.
Episode 4. Lost in Communication
Just re-read the text you have written. At least once.
The PM talked to himself and confused the customer even more.
Conclusion: You’d better ask one question and get an answer than mix a case description with a list of clarifications that could puzzle your client. When replying to such a letter, they may miss some questions, and you will have to ask them again, which is really annoying.
Suppose, in the course of the correspondence, the customer agrees to another solution. In that case, it’s a good idea to save all of their appeals. Unfortunately, even the fact of having the approved requirements specification may not be taken as an argument in favor of the development team.
This is what the following case is about.
Episode 5. A hysterical customer
This time our friend was lucky: a soulful client with a small project who quickly approved the requirements specification and design, did not delay payments, and timely sent the content to work on. Finally, after three months, the team met the deadline and landed the app on Google Play. It seemed like a happy ending — you wish! Exactly 2 hours after the release, the client was already ringing off the phone and moaning that his grandmother’s 2005 Xiaomi didn’t run the app.
The customer was sure that the software would work on any device, ignoring the argument that the requirements specification mentioned the lowest supported version of the operating system. The customer’s temper tantrum lasted for 3-4 months and spoiled the mood of the executive team and the project manager. They seemed to have done everything right but wrong.
Conclusion: Always discuss with your client which hardware and software the product will work on. It wouldn’t hurt if you agreed on the expected support for software versions. Since your client is not an expert and may not know the underwater stones, the value of the team is to elaborate on what difficulties and limitations may arise.
Episode 6. What if the client finds me annoying?
All outsourcing managers are known to be reluctant to bother their clients with minor issues. But at the same time, if the implementation of the product depends on the client’s answers, you have to pull yourself together and write / call / get to the poor clients, putting some extra tasks on their plate.
Isn’t that weird? No answer. Maybe because PM wrote to the client a week ago?
Conclusion: if a client does not respond, don’t wait for a week to get back to them, do it immediately. Also, put a plugin on your email, for example, Mailtrack – it will help you understand when the email has been read. This is a perfect way to prove the fact that your client not only saw the email but also opened it several times.
It works in cases where email is still the main channel of communication.
Of course, you’d better approve with the client a script specifying the order of the team’s actions in advance.
For example:
— The team stops the project and starts another one until the circumstances are clarified.
— The decision is left to the client’s assistant (contact information) or PM, and should not be challenged afterwards.
This scenario allows the company to insure against unforeseen downtime.
Part 2. Fuckups when working with a team
The guys from the development team also have something to say about the PMs’ fuckups that caused maximum sadness and grief to them.
Pain Point 1. Overtime work
It’s 3:45 p.m., and it’s exactly 15 minutes until the meeting with the company’s management. The PM gets a message from the client: «Guys, you need to fix these bugs today because I am showing the product to investors tomorrow morning.» The PM, at a glance, decides that the fixes will take at most 2 hours, so he writes to the customer “Ok” and goes to the meeting. At the meeting, the PM learns about the new tasks and KPIs, so in an hour, he completely forgets about the promised changes, just until the following message from the customer.
At 20:00, the client turns up with a message: «How are you doing? Can we already test the updates?» The PM starts panicking (no one has even started to do anything), apologizes to the client, and says that everything is getting done, but the task turned out to be more complicated than it seemed initially.
After that, the whole team spends the entire evening fixing the bugs. At the same time, the manager tells the team that the customer has just shown up with his edits and will not pay unless they quickly fix the bugs.
Conclusion: set the alarm, put a sticker on your laptop, and create a two-word task with a deadline in an hour, but do not force the team to work overtime if there is even the slightest opportunity not to do so. Also, don’t lie. This story was told not by the PM, but by a developer, who accidentally found out the truth while talking to the client.
Pain Point 2. How about accepting a little more responsibility?
The next sad story happened to a PM who had obviously just started to get into the details of the project and didn’t fully understand what was going on around him.
Conclusion: the PM of a project should remember their duties and not forget to get the application back to life.
Everyone in the team has a role, and everyone expects each other to behave accordingly. But suppose the management has decided not to show the PM the ropes about the company’s processes, and the manager himself is too young and shy to ask unnecessary questions. In that case, the situation described above may occur. A couple of such chats will help the PM to get used to a new project, but it is better to know your duties beforehand.
Pain Point 3. When Project Manager lives in his imaginary world
The team will be more loyal to a PM if he calls a spade a spade. Otherwise, messages of the following kind may become the norm:
Conclusion: be on the same page with the team, so the tasks become clearer and the feedback more meaningful. Selling mockups for design is the expertise of a completely different area (for example, the sales department), but that’s not what we’re talking about today.
Part 3. How to avoid making mistakes
There’s no way to do it. Even if you absorb the experience of all project managers in the world, you might come across a customer with unique, unprecedented screw-ups. However, by learning from other people’s fuckups, you can get a general idea of project management and decide whether it is suitable or not for those who want to «get into IT». Together with experienced Project Managers, we created a special project with valuable tips for dummies. It is developed by experts who have something to share — if you have an idea for a new chapter — jump in!
Managers, remember, you are not alone!