How many PMs do you need?

PM Clinic: Week 20 discussion summary

Compiled: 3/16/2005

The Question:

On many projects, the estimation for how much time development and testing require are based on clear requirements and some kind of process. But how should an organization decide how many project managers are needed for a given project? Should there be some kind ratio to the number of developers/testers? Are there different flavors of project managers that are needed in different ratios (E.g. "project manager" vs "program manager" vs something else)?


(Note: Currently about 30% of the pm clinic list are Microsoft employees. Microsoft has a strong project management and leadership role called Program manager, often referred to as PM. Large projects at Microsoft can have 20 or 30 people in this role each driving a single feature area of a product, with a group program manager managing all of their work. Some of the advice on this thread assumes a similar PM type role).

David Gorbet made the point that most projects can ship without PMs. The question is how much time or quality is lost without a dedicated leader / coordinator / manager.

Most people agreed there are many factors involved: the kind of work, the strengths/weaknesses of the programming team, and the culture of the organization. We also agreed that ratios were the easiest rule of thumb to work from.

  • Neil offered: 1:2:4 (PM/Dev/Test) as the ideal ratio.
  • David: 1:3 (PM/ Dev).
  • Edwin: 1 PM to 3 Tech Leads / 20 Developers, to 3 Test leads / Testers.

You can not manage what you can not measure

The difficulty of measuring the effort of leaders/managers came up several times. PMs focus on the tasks that are harder to estimate: convincing people of things, keeping people in sync, putting out various kinds of fires, fighting for resources, coming up with ideas, and making tough tradeoff decisions.

Mark pointed out that if you want to estimate how many PMs you need, you have to carefully outline what you expect them to do. Even if you can't measure it, you can estimate how much time per day they'll spend on given tasks. And once you have one PM, you can gauge how close those estimates are to reality and know what to expect from a second or third PM (Assuming of course that first PM adds value and doesn't just get in the way).

The Howell formula for estimating PM time:

PM time = (number of features * (design/spec/project manage + non-feature requirements + communicate and clarify + industry/government engagement – strong engineering lead design/spec/project manage + customer engagement*number of customers)) * 4 (if cross group dependencies) + process improvements + schedule management + time spend ‘just being an employee’ (answering email, etc.)

How to estimate project management type work

Here's a checklist (mostly from Gareth) for helping estimate how much project management type work a project has:

  • How ambiguous are the requirements? The more ambiguous, the more PM type work required to clarify them. Who will initiate, drive, document, and negotiate requirements?
  • Who drives the design? Who will initiate, drive, document and negotiate the design?
  • How much customer engagement is required? Does marketing hand you a marketing requirements doc? If not who will be the primary point of communication between the team and the customer? Is this a good use of programmers time?
  • What beyond product requirements need to be met (e.g. compliance/participation in industry standards, company mandates, etc.)? The more complicated these non-feature requirements, the more PM work there will be.
  • How self-sufficient is your engineering team? Are developers proficient at managing their time, staying in sync with each other, dealing with politics and non-technological essentials? Negotiating with marketing, customers, management and other teams? Same questions apply to the test or documentation team.
  • How much cross-group work is required? If you have a feature that has dependencies from multiple internal or external teams, you’ll need more PM help. My rough rule of them is to multiply any estimates for feature development and PM work by 4x if it involves a dependency who is developing in parallel.
  • How many important customers do you have? Are all customer requirements aligned? Multiple customers with conflicting requirements and priorities will generate more PM type work.
  • Do you have to keep to a schedule out of your control? (E.g. your team is part of a larger product group). PM time is needed to manage this an ensure that you meet the externally imposed lock down dates, etc.
  • What quality do design/specs need to be at? If you’re speccing for external consumption more PM resources are required.
  • Are there dedicated resources for marketing, market research, UI design, accessibility? If not who will lead these efforts?

Remember: it's hard to estimate how many programmers, testers or any role

Berkun mentioned that every conversation he's heard about estimating the number of testers or programmers needed were just as fuzzy. It's important to realize that for any kind of skilled work a good worker will be 5 or 10 times as productive as an average worker (Weinberg documented this for software programmers in his book Psychology of Computer Progamming). For fun, get several lead programmers or lead testers in a room and ask how they estimate their staff needs for a new project.


Neil Enns, Edwin Marin, David Gorbet, Tim Bishop, Mark Colburn, Gareth Howell, J Kremer, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Anyone can join as long as they follow the simple rules.


All content copyright 2005. Scott Berkun. RSS Feed