What is the rule-of-thumb ratio of Project Manager/Engagement Manager time to overall project time (e.g. man-hours for work products) in a project? I'm especially interested in an answer within the context of a Professional Services engagement, though I presume there would also be a general answer.

For example, let's say we have a 1,000-hour project with two full-time team members working on it. How many hours should be expected from the Project/Engagement Manager on the project? 1/10, 1/20, 1/5?

Is there such a typical ratio? Does it scale/change based on the number of project members? For example, does it change if the project is 2,000 hours with four FT people over the same 500 calendar hours (~3 months)?

  • 2
    Depends on the framework. Scrum imposes ~20% process overhead, with a minimum expectation of ~25% engagement of the Scrum Master (although 100% is better).
    – Todd A. Jacobs
    Jan 24, 2013 at 18:49
  • @CodeGnome - that would imply (at the 100% level, at least) that you have one PM per project ... and one project per PM. In most organizations I've ever seen and worked with, any given PM has many projects they are involved with.
    – warren
    Jan 24, 2013 at 19:14
  • Scrum is different. :) The heavy engagement of the Product Owner and Scrum Master with the team is just one of the differentiators. The framework advocates full engagement, but people obviously can and do deviate from the framework.
    – Todd A. Jacobs
    Jan 24, 2013 at 19:20
  • @CodeGnome - not familiar with Scrum techniques, personally :)
    – warren
    Jan 25, 2013 at 14:54
  • You will be now. :) Longer answer below, with more detailed arithmetic.
    – Todd A. Jacobs
    Jan 25, 2013 at 19:40

4 Answers 4


Framework Overhead

All frameworks entail some amount of process overhead. Some of that overhead is in the form of hours worked by the project manager, but some of it is a byproduct of delivering on framework controls and artifacts. The latter form of overhead is often significantly larger, since it tends to impact everyone on the project rather than being allocated towards a single role.

For example, Scrum is described as a lightweight process, but it carries significant process overhead that increases as cycle time contracts. A typical calculation for Scrum overhead when using two-week sprints might look like this:

  • 4 hours of Sprint Planning per iteration. (32 hours per team)
  • 2 hours of Sprint Review per iteration. (16 hours per team)
  • 2 hours of Sprint Retrospective per iteration. (16 hours per team)
  • 15 minutes per day for daily stand-ups. (2.5 hours per team)
  • 2 hours of Backlog Grooming per iteration. (4 hours per Scrum Master/Product Owner pair)
  • 1 hour per day (minimum) for reporting, or generating artifacts like burn-down charts, or communicating impediments to the parent organization. (10 hours per Scrum Master)

So, the typical two-week sprint with six Scrum team members, a Scrum Master, and a Product Owner will consume 98 man-hours in overhead. This covers just the framework-mandated meetings, and as such is a reasonable baseline for some additional calculations.

An 8-man team averages 320 man-hours in a two-week sprint, of which we'd be expecting 84 hours to be consumed in framework overhead, with an additional 14 man-hours allocated against the Scrum Master and Product Owner. That's 30.63% for the project as a whole.

A full-time Scrum Master averages 80 man-hours in a two-week sprint, of which 22.5 hours would be considered a minimum level of Scrum Master engagement with each team when using the expectations defined above. That represents 28.13% of the Scrum Master's available man-hours for each iteration.

Obviously, the calculations can change based on sprint length (longer sprints trade cycle time for lower process overhead), team size, or meeting length. However, it is certainly a reasonable baseline for understanding the level of engagement required by a Scrum Master.

Level of Engagement

The calculations above represent a bare minimum engagement level for Scrum, and excludes participation in other organizational activities such as Scrum-of-Scrums meetings, stakeholder meetings, team "hallway meetings," and other daily tasks that are essential to the Scrum Master's core responsibilities for coaching and process refereeing.

With mature teams and process in place, a Scrum Master might be able to directly participate in 3-4 projects at a time, but the risks of "drive-by management" and process failure increase exponentially as per-team participation trends towards the minimum.

From a practical point of view, a Scrum Master should be an intrinsic part of the team rather than a part-time outsider in order to make the most of the framework. However, that's a decision each organization must make for themselves based on their own unique circumstances.

Generalizing for Other Frameworks

Most of the foregoing calculations were based specifically on Scrum. However, all healthy projects need to allocate similar blocks of time for attending meetings, collecting/disseminating status, and generating framework artifacts.

Some methodologies trade face-time overhead (a la Scrum) for reporting or artifact management. Other methodologies trade team overhead (e.g. fewer team meetings) for project manager overhead (e.g. more metrics analysis or more reporting artifacts). However, in my personal experience this does not actually result in lower overhead for the project as a whole.

Your mileage may vary, but you can at least estimate it by running similar calculations for your chosen framework.

See Also

  • why do you have 2 hours of refinement per sprint? I would expect a Development Team to spend up to 10% (or 8 hours in a typical 2 week sprint). May 9, 2017 at 19:55
  • @MrHinsh The current formal guidance is that when refinement is an ongoing activity, it should consume no more than 10% of team capacity. In a mature, smoothly-running process it's often much less. Using the numbers above, 10% would be 32 man-hours of refinement. That certainly seems excessive to me, but your mileage may vary. If you want a more expansive answer, please open a separate question.
    – Todd A. Jacobs
    May 9, 2017 at 20:38
  • I asked as the question above does not lend itself to the assumption that this is an efficient and well running team. May 10, 2017 at 8:23

I don't think you'll find a useful standard that cuts across industries and types of projects. The range would likely be too broad to be of any real use in your specific industry and types of projects.

In IT, I have read from several sources, including the CHAOS Report and Capers Jones, that the PM effort is roughly 12% to 18% of total effort. That happens to be consistent with what I have found during estimating for various systems integration projects where I work; however, I have also seen the effort to drop as low as 8% when the sales-incented people get their hands on it to get the price competitive. Our organization unwritten rule is to be around 12% to 15% when we do our initial estimates.


We use following rule-of-thumb ratio in our company: PM needs about 10% of total team hours per week. For example, if you have 6 developers and 4 QA in your team (10 team members total), then PM will need (6 + 4) * 40 * 0.1 = 40 hrs/week on average.

Please, take into account that it's average -- PM should spend much more in the beginning of his project, when he needs to setup all agreements "on shore". And in the end of project, when he needs to "close" all the agreements and make sure everyone is happy.

Also, the time amount depends very much on complexity of your project. I distinguish 3 types of projects (from PM complexity point of view):

  1. Fixed Price projects -- most complex, the ratio of 10% is ok for it.
  2. T&M projects -- less complex, because you are not committing on whole scope in the beginning of project. Ratio should be less here -- about 5% is usually pretty enough.
  3. Staff Augmentation projects (body shop) -- least complex, because customer just "buys hours" of team member, and most of project management is on his side. Such projects usually need about 2-4% of the ratio just to keep team built and perform people-management.

The Project Management Institute published a report that equates PM time vs project size. In this the smallest projects are defined as having a total installed cost (TIC) of $100, 000 or less; medium-sized projects range from $100,000 to $1 million; and the largest projects are in the range of $1- $10 million TIC. Generally speaking, the larger the project is, the smaller the project management costs will be as a percentage of the total. Based on the size estimates given, the article notes that project management costs for all phases of a project generally total somewhere between 7-11 percent of the project’s TIC. If project controls support is added, project management costs will be in the 9-15 percent range--estimates that fall in line with noted authorities such as Kerzner (Project Management: A Systems Approach to Planning, Scheduling, and Controlling. 1998). .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.