PM: Project Manager


PM: Project Manager

"The customer is completely understood, and kept happy. We are climbing the correct 'mountain graph', and we stick to our budgets".

  • Understand the difference between Activity Lead vs PM.

  • Ensure that we are using an appropriate management style for the customer. Don't force something upon the customer that they are not happy with. Also don't allow the customer to force something upon us that we are not happy with.

  • Afford Engineers the opportunity to participate in customer facing meetings.

  • Ensure that Engineers and Designers are afforded the opportunity to give buy-in into major project decisions (e.g. during kickoffs, feature planning, etc.). This is especially important when discussing cross-discipline decisions that may touch several areas like Design, Backend, Web, Android, iOS, etc.--in which case at least one representative of each group needs to take part, ideally everyone involved. This is one type of meeting that is definitely worth having.

  • Involve QA at appropriate times to ensure high quality, efficiently.

  • Ensure that the customer is happy. Track this regularly and proactively. Report this to the HoP weekly. You can gauge this yourself based on how they behave. And you should also regularly ask the customer (once a month). Use NPS as the metric for recording happiness. When you report the happiness score to the HoP, indicate whether it's customer-reported vs self-reported.

  • You are responsible that the project gets delivered on time. And renegotiating with the customer as soon as you feel that this might not happen. The earlier the better.

  • Ensure that the Squad morale is high and that everyone stays happy.

  • Ensure that the whole Squad is aware of project budget and overall health (health = are we on track to finish on time and on budget).

  • Resist the urge for wishful thinking when reality doesn't look good.

  • Ensure project budget is not exceeded. You will get the planned budget from the HoP when a project starts. Report weekly to the HoP how we're spending budget, and making progress. Track this from day 1.

  • Demand estimates from the Squad so that you can track overall progress.

  • Provide estimates, but don't estimate past the "uncertainty horizon".

  • It's up to you to accurately track progress in a project. Progress can be loosely defined as: "do we have enough budget left to finish the project?". Take course corrections when necessary. Escalate to the HoP as needed.

  • Ensure that we deliver to the customer to their correct level of expectations along the various dimensions (performance, design, security, budget, etc.), i.e. Luka's "mountain graph". Simply staying within the gross profit margin is not a goal, and should not be a guiding principle. Think of the profit margin like the guardrails on a highway road, they're useful as a last resort to prevent you from dying, but they're not so helpful for steering the car. It's the same with projects, there are many variables, and the goal is to ensure that we spend budget effectively so that we can deliver the highest satisfaction to the customer within the constraints. To some customers that's design, to others that analytics. Don't overdeliver on things that the customer doesn't appreciate, and conversely don't underdeliver on what he does. It's your responsibility to correctly a) understand the customer, and b) steer the project to achieve this.

  • Shield the Squad from difficult customers.

  • Educate the customer about our processes and software development in general.

  • Fight against Squad member swaps. This can kill projects.

  • Set a pace so that the Squad has a relatively steady level of pressure throughout the project. You don't want a 6 week vacation, followed by 1 week of hell. You want 7 steady weeks of intermediate pressure.

  • Expect the unexpected and build slack into your plans. You will never regret building in at least 30% buffer into your timeline.

  • Don't lie to your Squad. Don't give the customer one date and your Squad another date. Be transparent. All our engineers are aware how the unexpected is expected, and everyone will appreciate knowing that there is some buffer.

  • Never prescribe timelines to the Squad. Instead, ask them when the work can be completed and plan around that.

  • Hold feature freezes, and enforce them.

  • Always test, before sending something to the customer. Less working features is so much better than more non-working ones. We at 9Y understand that software is complicated and that there will always be bugs in the first version. Our customers however will misinterpret this as poor quality and it will destroy trust. It's better to be late than to deliver buggy software. If the circumstances demand sending a build that you know has bugs, inform the customer about these "known issues" at the same time as when you send the build–this will a) help them plan and not get frustrated and b) prevent you from loosing too much trust.

  • Hold the Squad accountable for the timelines that they commit to. When there are good reasons for delays, then accept them and adjust your plans. Never force feed plans to the Squad.

  • Practice good risk management:

    • anticipate and try to avoid or minimise risks before they become problems

    • analyse risk:

      • what's the cause

      • determine potential impact on budget, timeline and quality

      • what are we doing to mitigate it or minimise impact

      • what are we doing to learn from this as an organisation so that it doesn't happen again (extract lessons learnt)

      • what are we offering as reparation to the customer for the damage we're causing

      • keep the customer informed of all the above and afford them the opportunity to steer the project, or at least to prepare. Even if the risk is small. Rule: "if it can impact the project timeline, budget or deliverables, then the customer must be involved". This is important.

  • Be fast. Don't let emails sit. You should always be checking your inbox, and always answering calls from customers (during working hours, politely remind the customer when they forget this). Responsiveness is a huge driver of customer satisfaction, keep it as high as you possible can. When you cannot properly answer immediately, answer with an acknowledgement that you received the message and will get back to them. If you cannot answer a call, send a quick SMS saying "I will call you back". Never leave them hanging, it sends bad signals, and you need to be on the ball here to get the high NPS scores.

  • When customer satisfaction dips, take corrective action immediately. Also notify the HoP. Expect this, it's expected to happen a few times during each project.

  • When customer satisfaction suddenly falls, add a short entry into our knowledge base along with a short interpretation of why it happened. Ask the HoP if you need to know where to put these.

  • Evangelise to the customer when the Squad goes above and beyond. Just doing it doesn't count, you have to do but also tell.

  • Resist the pressure for scope creep from the customer. It's fine for the customer to change their mind and want something else, if this impacts scope and budget then talk about it openly with them. Maybe they know it's not in scope and they're happy to pay more. Maybe they don't want it that bad after all and we can save ourselves the trouble. Maybe they think it's in scope and we don't. Whichever case it is, we should find out. Ask for help from the HoP if needed.

  • Maintain pragmatism and resist the pressure of "academic solutions" that may be pushed by the Squad. Know when it's good enough.

  • Know when it's not good enough, and ask the Squad to give more. You are responsible for making sure that the customer gets something that they are happy with.

  • Follow the Customer Invoicing Protocol.

  • Follow the Incoming Invoices Protocol.

  • Regularly evaluate how Squad members performed, including whether they met their goals along with timeliness and quality of work. Report your impressions regularly to the HoP, with a summary at the end of each project.

  • Understand the difference between the maker-schedule vs manager-schedule. You are likely the odd one out on the Squad, that is on the manager schedule. Don't impose that on the rest of the Squad. In simple terms: allow the Squad to have long chunks of interruption free work, and try to cluster meetings together in batches.

  • Look for natural opportunities to increase revenue. Offer the customer support with things that might make sense. They hired us to help them with something, if you think of further ways that we can help, suggest it. You can get support from Sales or HoP with pricing, but it's up to you to identify opportunities and convert them.

  • You are almost always also the Activity Lead, so you assume all those responsibilities in addition to all of the above.