Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

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)?

share|improve this question
    
Depends on the framework. Scrum imposes ~20% process overhead, with a minimum expectation of ~25% engagement of the Scrum Master (although 100% is better). –  CodeGnome Jan 24 '13 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 '13 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. –  CodeGnome Jan 24 '13 at 19:20
    
@CodeGnome - not familiar with Scrum techniques, personally :) –  warren Jan 25 '13 at 14:54
    
You will be now. :) Longer answer below, with more detailed arithmetic. –  CodeGnome Jan 25 '13 at 19:40

2 Answers 2

up vote 5 down vote accepted

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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