Does a Project Office or Progam Managment Office apply to Consul
Anonymous
Does a Project Office or Progam Managment Office apply to Consulting Models? I've read several articles here on program management and project offices, etc. I typically view these as applicable to "non-consulting" organizations, ie., as a consultant, that is more characteristic of what my client would need. In the case of Program management, does it make sense to have a "program" to manage resources that are working on projects that have no business/technical relation to each other? For example, if I own a consulting firm with 100 developers, and they are spread out over 15 different projects for 15 different customers (and therefore 15 different IT solutions), the only common denominators among them might be the need to multi-task, as well as consulting revenue for my company. That is, each and every one of the projects is independent of each other, except when it comes to managing utilization for maximum profit. Saving Changes...
Michael BrownProject Manager| JPMorganChaseDeerfield, Il, United States
I think where it is most applicable, is in situations where you are short staffed or have a scarce resource who is being shifted from project to project. The way in which you sequence and schedule the projects could very well result in more or less revenue. If your interested in looking into an interesting model, you might want to read a bit about Critical Chain project management and its applications for multi-projects with resource constraints. Saving Changes...
Anonymous
I guess that setting up a PMO to overview your projects and resources, enables you to get more synergies between projects amongst each other. The PM methods can be applied to stimulate Knowledge Sharing & increase the overall knowledge of all your employees.
It would them be more of a KMO, or Knowledge Management Office, instead of a PMO ;-)
It could also result into improved focus om the development of competencies as a whole in your resource pool.
Great challenge to think about .... Saving Changes...
I agree wholeheartedly with Michael Wood. To me the best use of a Project Office is to assist PMs and the organization in meeting it's critical commitments. As a practitioner in the area of the Theory of Constraints, I'll also second Mr. Wood's suggestion of looking into the Critical Chain approach, and especially it's application to the multiple environment, where resources are (and should be) shared across projects. You can find an article on the topic at Program Management - Turning Many Projects into Few Priorities with TOC.
The PMI PMBOK Guide defines a program more or less as any set of projects that will benefit from coordinated management. Assuming most organizations rely on a limited set of resources, those resources and their priorities need to be "coordinated" if the organization's goals are going to be met. Hence, a program.
There are benefits in terms of resource scheduling, time recording and client risk management that can accrue to the consulting organisation from a project office in terms of these areas.
A Program Office is directed at managing multiple projects that are related, and serve a common purpose, and it is unlikely that this model will work in a consulting firm (unless the firm is using it for internal projects, or directing a program on behalf of a client).
Incidentaly, TOC based Critical Chain Scheduling requires 'Through Put Accounting' to work properly, which excludes concepts like hourly rate charges. The paradigm shift required by the financial management of the company is quite severe - be real careful how you approach this.
My feeling on the TOC topic (I support it quite strongly) is that one has to first feel the pain of the classical matrix organisation, and have a functioning matrix system before one can appreciate the evolutionary benefits that TOC brings.
(I have recently implemented a software package called Resonance for the purpose of Critical Chain Scheduling, in a Program Office that I managed). Saving Changes...
There are definitely aspects of the Project Office / Program Office concept that would apply. One is the "Center of Excellence" model, in which the PO serves as a resource for whatever the PMs need to do their job better (and more profitably), disseminating best practices, lessons learned, etc. You also have internal policies, PM training, mentoring, etc. I would expect in a consulting organization, you could also gather a lot of data about overhead costs (and thus minimize same, or at least account for them in estimates).
Whether the 15 or 15 x 15 projects have anything to do with one another does not eliminate the need for a Project Office. Saving Changes...
Stuart wrote..."Incidentaly, TOC based Critical Chain Scheduling requires 'Through Put Accounting' to work properly, which excludes concepts like hourly rate charges. The paradigm shift required by the financial management of the company is quite severe - be real careful how you approach this."
Untrue.
There are plenty of successful Critical Chain and TOC multi-project management implementations in organizations who have otherwise not heard of TOC or applied "throughput accounting." It would be safe to say the most of the most TOC-savvy organizations out there have yet to fully apply "throughput accounting." It'll help in the long run, but it's not necessary to get considerable benefit.
In essence, I agree with you. What attracts me to TOC is the use of probability and behaivior patterns with the resulting resource, feeding and project buffers, and 'no multitasking' policy. These concepts need no throughput accounting to work.
Remember though that I said: 'to work properly' - if one does not apply the whole theory, then organisational conflicts arise, that are difficult to deal with (Perhaps they are no more difficult than EVM problems though).
I have two questions for you, and I would appreciate the benefit of your knowledge of this topic:
1. Production management theory (throughput theory) requires that the 'bottle neck' feed has a higher capacity then the 'bottle neck' to maximise the throughput - can one use this spare capacity and at what rate should it be costed?
[Clearly any 'non production line' work taken on by these 'multi skilled', 'non-multi tasking' resources carries priority 2 and must be dropped when the 'production line' demands their attention.]
2. At what rate should a buffer (feeding and/or project buffer) be costed, for budgeting purposes?
[This question is important when using Critical Chain and TOC for project management in a 'bid and contract' scenario, where a proposal must be put forward with a cost price]
Stuart asked two questions. I'll address the second first . . .
2. At what rate should a buffer (feeding and/or project buffer) be costed, for budgeting purposes? [This question is important when using Critical Chain and TOC for project management in a 'bid and contract' scenario, where a proposal must be put forward with a cost price]
When cost estimation and tracking is important, as in the situation you mention, there is a corollary to the basic buffer management for schedule purposes that is referred to as the "budget buffer." In this approach, the total project budget is are calculated as follows . . .
Total task time x highest resource rate
+ Half of total buffer time x highest rate
+ Half of total buffer time x highest rate * 1.5
Single task expenditures (typically specific material or capital spending which are not ususally particularly variable) are added.
This is the simplified, good enough approach for most circumstances. If one wishes to refine it, you might look into detailing out the "task time" portion to a finer degree. In any event, since any resource (including the most expensive) can be the consumer of buffer, and since deep buffer consumption could require extraordinary efforts (OT, or expediting charges) to address, the "buffer cost" calculation blends the two "worst cases."
In the same way that the CC schedule (with the behaviors that it both supports and counts on) provides a total project leadtime promise that is considerably shorter than a traditional CP schedule with similar probability of on-time delivery, this budget calculation also results in a similarly smaller budget. Smaller budgets that can be met are good, especially in a bidding situation.
