In a software development firm that I work for, contracts are billed based on 3 items: Design, Development, and PM.

Example: A simple software project could take 200 hours and would be broken down into the following hours: 90/90/20 (Design/Development/PM)

I can imagine the profitability of the project being affected if Design and Development exceed the allocated 90 hours each. However, should it be a concern if the PM time exceeds the 20 hour mark? I mean, is the PM even considered a billable resource?

Traditionally, the companies I used to work with practice the philosophy that a PM must spend as many hours as it takes to make the project successful.

But how is this viewed from a PMBOK/Prince 2 methodology? Please note that I am not asking for a personal opinion or a poll. I would like a response that is based on some formal methodology (if possible as I'd like to make this as objective as possible).

I found a very similar question here: Should a PM also be a resource on the project? Why? From the answers there, I liked Mark Phillips' answer the best (being a 'no') as impartiality is required from the PM's perspective. However, I don't feel that that question is as specific as mine as it doesn't address the billable aspect.

  • Tough to answer within the constraints you provide. The question asks for us to evaluate the practices of your organization against a formal methodology. I think those are two different frames of reference. Strictly speaking, if your company conducts business this way, then that is part of their Organizational Process Assets (PMBOK term). But that's not what you're asking. Can you relax the constraints?
    – MCW
    Commented Oct 11, 2012 at 17:49

4 Answers 4


I agree with Doug and Kent -- the question of whether the PM should be considered a billable resource depends on the organization and the contract.

I will add this: ask whether the PM can impact the critical path? For example, if the project manager were ill for 3 weeks, would it jeopardize the end date? If the answer is 'yes', then the project manager should be tracked as a resource on the schedule. Like any other resource, you would want to know what the impact of that illness would be on the finish date.

Similarly, if the project manager is being paid funds that Finance is tracking to this project, then yes, they are a billable resource. In some organizations, the PMO (project management office) provides project management resources and is considered a fixed expense unrelated to the project.

A common practice in the Aerospace & Defense industry is to categorize project management activities as LOE (Level of Effort). In some reports, they remove LOE activities so they can quickly see the numbers without the PM overhead.

  • Very nice! +1 for bringing up the part about affecting the Critical path - that's a really good perspective. Thank you, Brian.
    – JTech
    Commented Nov 1, 2012 at 15:52

I don't think PM methodology is relevant, more what your company's accounting practices are. I have worked with companies that do consider PM as a billable resource and track hours etc to pass those costs on to the client transparently. I have also dealt with subcontractors where PM effort is rolled into overhead so it isn't as transparent. I have also worked with companies where PM effort is not tracked because projects are internal (e.g. business changes).

What is shared by all the companies I've worked for/dealt with is that the PM is considered to be a "resource" even if hours/costs aren't tracked or billed on a per-project basis. I think this is appropriate from a methodological point of view and best practices point of view.

  • Thanks, Doug. +1 for providing all 3 scenarios you've worked with.
    – JTech
    Commented Oct 11, 2012 at 18:19

You are trying to force an answer to this by asking for any methodology that gives an answer. I'm not an encyclopedia of methodologies, but I don't think you are approaching this correctly. You should not be looking to a methodology for the answer. You should be looking to your contracts. If your contracts allow you to bill for PM, then bill for it. If your contracts don't allow to you bill, then don't.

Let's say you are using a methodology called "PM-Billable" (PB)(it's like scrum but it has an additional rule that says you must bill your clients for PM services). You write up a contract that clearly states what you are going to charge for. Your client reads the contract and comes back to you and says "This contract is fine except there's no way I'm paying for PM." Now what do you do? He doesn't care about PB methodology.

Now let's say you are using scrum. Scrum doesn't dictate PM billability You write up a contract that says you are going to bill for PM time. The client signs the contract. There you are.

  • 1
    In other words, don't worry about methodologies, just make money and be happy.. do we need a QA site for this at all?
    – yegor256
    Commented Oct 17, 2012 at 6:38

Disclaimer: I'm not a PMP, so apologies if my comments below aren't correct / accurate. Feel free to correct it as much as you want.

I believe the word to bind your question with PM's best practices (more specifically, the PMBOK) is 'tailoring'.

The PMBOK mentions that "the organizational culture, style and structure influence how projects are performed." (2.4, organizational influences on project management).

Also, on Organizational Process Assets, is mentioned that one of PM duties is to "tailor the organization's set of standard processes to satisfy specific needs of the project."

So, it boils down to what's been already told: you need to fit your projects / contracts to their needs, taking into account the company culture and structure.


  • I'm not a PMP yet, so thanks for the disclaimer. But I think it's great for me to delve into the Tailoring concept ...thanks!
    – JTech
    Commented Nov 9, 2012 at 12:54

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.