The Project Manager’s Hardest Task: Learning to Say No
Having led a team of market research analysts at OpenView Labs for the last three years and worked closely with OpenView’s portfolio companies on implementing the Scrum development methodology, I have seen projects and project teams of all shapes and forms. I have seen spectacular successes, heart-breaking failures, and countless near-misses and near-wins in those projects.
Requirements of Exceptional Product Managers
Over the years, I have thought a lot about the evolving job requirements of a project manager in a fast growing, entrepreneurial organization like OpenView, or in our own portfolio companies. Technical and market expertise requirements aside, a really good project manager needs to have a dizzying range of organizational, people, and analytical skills in order to be truly successful.
Having the right “lean” and “agile” mindset is also extremely important because without agility and a true sense of urgency, project teams will never be able to complete what they are asked to do, and risk forever falling behind fast-moving markets and customers requirements.
In previous posts, I have offered tips to improving Scrum product ownership, dealing with the prioritization problem, retaining a true sense of urgency in expansion-stage companies, and maintaining the culture of innovation in your organization, and all of those are issues that great product and project managers are able to effectively deal with everyday.
But there is really a much harder problem that hits before all of these organizational, people, and resources issues kick in. It is the problem that vexes Project Managers the most, yet typically receives the least attention. It is the problem of not saying, ‘No’.
The Biggest Problem for Product Managers
I am sure every project manager out there has been involved in a project where, after hundred of hours of work, the team is exhausted — burned out from project creep, missed deadlines, communication breakdowns, and worst of all, the realization that they should have said no to the very idea of the project in the first place.
It really falls on the project manager to be that resolute voice of reason – but alas, it is also the hardest thing to do.
How do teams get going on projects they shouldn’t have started in the first place? Hindsight is 20/20, but achieving that type of clarity is difficult when the project is first presented.
Here are six reasons why product managers have a hard time saying no, and why that often lands their projects in trouble:
- Most projects are proposed with the best intentions in mind: The majority of proposed projects will be valuable as long as they are done right. Sometimes, even standard cost/benefits analysis will also fail because they typically underestimate costs (by both underestimating project cost and opportunity costs).
- Project managers are expected to produce “completed projects” and “outputs”: Therefore, it is hard for them to refuse to take on more projects.
- It is always tempting to say ‘Yes’ to projects that appear simple, resource-light and easy to do: In reality, the ”no brainers” often tend to be the ones most likely to run away because the project team is overconfident.
- Projects that appear to be a quick simple hit often aren’t: They tend to consume more resources than you expected, because project work begets more project work and scope creep is impossible to avoid.
- Projects tend to have inertia: It is hard to stop working on a series of project once you start going down a particular path. It takes a very alert project manager to detect this tendency and strive to stop the flow. When a project is part of a master plan, it is even harder to say no and change course, because inertia grows with mass.
- Project managers sometimes have trouble seeing the big picture: They are often too deep into their own projects, their methodologies, and their obsession with efficiency to see how their outputs fit or fail to fit together in a grand plan.
It is hard to do, but leaders need to learn to do it better. Failing to say ‘no’ to the wrong or inappropriate projects will cause major drag on the company’s precious resources, demoralize the team, cause employee attrition, and can crush an expansion-stage company on the brink of breaking out into the mainstream.
In my next post in this series, I will discuss the types of “wrong” projects that should be rejected, and how project managers can say ‘no’ to those projects better.
Do you agree saying “no” is a project manager’s most difficult challenge?