Last week I attended the 5th annual 2017 Digital PM Summit with three co-workers, all of whom are Atomic Object Delivery Leads. The Summit made me reflect on the role of a project manager and the challenges that go along with it.
Being a project manager is hard. As I attended talks, breakout sessions and had impromptu conversations with other attendees, and four common patterns of frustration and stress emerged:
- Project managers often need to give bad news to clients/stakeholders.
- Project managers feel disempowered, but responsible for project success.
- Project managers don’t feel valued by their technical team.
- Agile hasn’t won over PMs yet.
These problems are real, but there are ways to mitigate or eliminate them.
1. Giving Bad News
No one likes delivering bad news. As a PM, or Delivery Lead at Atomic, the most common “bad news” pattern is that the team is behind.
At the Summit, Meghan McInerny reminded us that bad news doesn’t get better with age: “it is not a fine wine or aged cheese.” The longer you wait to discuss it with your client, boss or key stakeholder the worse that conversation will be. You will be stressed and anxious about it. The best remedy for anxiety is action– so don’t wait longer than you have to to have the hard conversation.
When giving bad news in a meeting, start by laying the cards on the table. Just get it out there: “The team is behind and we’ll need to cut scope.”, “Feature X was more complex that we thought.”, “Our original approach to this technical problem isn’t working and will need to be re-done.” There. You said it. I promise you will feel better, and now it’s no longer your scary secret. You can move on to discussing options knowing that everyone understands the problem.
Be ready with options. The worst thing you can do after giving the bad news is to look expectantly at your client as if to say “now this is YOUR problem, tell me what to do”. Successful outcomes from hard conversations rely on carefully thought-out options: “The the team is behind and we’ll need to cut scope. We have prepared several scenarios to identify MVP features and simplify some non-essential items in the backlog …” When confronted with bad news followed-up by smart options, I have found that people are gracious and relieved you have their back.
Custom software development is hard, and every sufficiently complex project will have challenges along the way. You prove your value in how you handle those issues.
2. Responsibility without Empowerment
Being responsible for project success while not being empowered to make decisions is a recipe for PM burn-out and failed projects.
In a breakout session a PM at another agency shared her frustration that a director in her organization consistently sat in on stand-up meetings (without asking), then billed the time at his (incredibly high) hourly rate. She was responsible for staying within the budget, but her superior officer was actively working against this by eating into that budget and providing no value. She was upset and burnt out. Leaders need to be aware that the PM position is a leadership role and must be given the power to find success or they will lose their most valuable asset: people.
3. Project Management is Essential
Some project managers I spoke to had an “us vs. them” attitude towards their technical team members, especially developers. At Atomic, we’ve largely avoided that problem by promoting former makers to delivery leads. We’ve also hired a very talented non-maker who has done a fantastic job in the role in Ann Arbor. Company leadership, and especially senior makers, need to communicate the value of project management to the whole team.
As a developer, I never saw a project fail due to technical mistakes, but I have seen project failures due to misaligned expectations and poor communication. Having a talented PM that can focus full-time on managing the project helps avoid common mistakes made by developers or designers that are also pulling double duty as a project manager.
Leaders, remind your developers and designers that someone has to take on this role, and wouldn’t they rather it be a professional PM instead of themselves?
4. Agile Has Many Doubters
Coming from a development industry that has largely embraced Agile I was surprised to hear so many PMs tell me they either didn’t believe Agile was a good approach or had tried it without success. I asked why this was and heard two common complaints.
First, that teams lacked continuity and the people working on them were always changing. This is a business decision that agencies make to simplify capacity planning. It doesn’t have to be this way! At Atomic, we keep project teams continuously engaged with their project until the project ends or the Atoms on the project have been on it long enough that we can responsibly rotate the team. Usually a year is about as long as we’d like to keep people on a single project before making a change.
Second, many PMs felt their projects were too short to support Agile. I believe this comes from the mistaken idea that Agile is a rigid process that demands rituals at a certain cadence (e.g., two week sprints). A PM attending an Agile presentation that recommends two week sprints can wrongly dismiss Agile out-of-hand. Agile is a framework where you can continue to assess and adjust how the team should work. That may mean shorter sprints or a looser backlog (e.g., kanban style). Agile, when done correctly, does not rely on dogmatic adherence to a specific process.