Why Project Management?
One of my biggest challenges as Product Management Director is to dispel the negative mojo behind the Billable PM Hour. Project Management and Product Management can be a contentious line item on our invoices. Based on the varied and inconsistent way PM hours are handled in our industry, I’m guessing most of our partner agencies have similar issues — it’s a % of the total, it’s a flat-fee per week, it’s a set number of hours per project, it’s baked into the development cost…and on and on. It’s almost never as straightforward as a time-and-materials billable role.
On the one hand, of course I understand where the client is coming from. These hours often can’t be associated with specific deliverables. The client may be providing directives and objectives and it seems like having an intermediary is inefficient (spoilers: it isn’t). Running meetings and creating status reports should be part of our overhead… “we can do our own QA, we shouldn’t have so many meetings, we don’t need a status report…except what are you guys doing and have you tested this?”
I get it. I was a client once, too.
But let me let you in on a little secret: the PM is your best and most valuable ally on any project.
The Product Manager has one main directive: Get the project done in the best way possible. All the while considering business value and priority, functional direction, resource allocation, stakeholder feedback, emerging requirements, and the good old standards: budget and timeline.
And here’s another little secret: when developers or designers are doing what they love to do they’re probably not thinking about how long it will take, how much work somebody else is doing, or whether they need to let you know how it’s going. They’re not supposed to, they’re supposed to be focused on building an amazing product.
Trust me, you don’t want to rely on developers or designers to manage a project any more than you would rely on a manager to write code.
The PM knows, at all times, what the project objectives are and who is doing what to meet those objectives. The PM may not know the details of the technology being used, but they can usually spout from memory everything it’s supposed to do, what business processes it solves for the client, how we are going to test it, how it works with the other parts of the team, and which team is responsible for getting it done.
A Product Manager is responsible for coordination of the team members, but also for holding them accountable. The PM knows if someone is struggling to meet goals or if someone else is losing momentum waiting for feedback. They are the ones willing to risk the wrath of interrupting a developer at work in order to make sure the rest of the team has the answers they need.
Aside from meetings and documentation, the PM’s role usually involves reigning in big ideas or pushing the team to stretch the concept farther, acting as a sounding board for problems or settling strategic differences in approach. The PM is the gatekeeper to the scope and requirements of the project, both on the agency side and on the client side. You want someone in your corner to tell you honestly when the things you want are going to cost a lot more, and what the developer means when they say “not a big deal” (Hint: that phrase represents a range from 3 hrs to 6 weeks, depending on the developer and the project).
You want someone to be paying attention so that you know in advance if the scope or approach needs to be adjusted, and you want that person to take the time they need to work it out in the best way possible for you.
Honestly, if I were a client again I wouldn’t be asking my agency why there were so many PM hours.
I would be asking if they needed more.
Originally published at www.highseas.com.
