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.