To start this discussion off, let me cut and paste a recent post I sent to a PM-centered email discussion list that I participate in...
.
Project Managers are responsible for planning, tracking, monitoring, and managing individual (or a small number of) projects.
.
To the extent that a program is an interconnection of subprojects that result in really only one significant deliverable of value, I don't consider that a program, but a project.
.
A program is a set of projects that need to be managed in a coordinated manner in order to achieve results that would not otherwise be attained. I would suggest that any organization that tries to deliver multiple (individual, unrelated) projects with a shared set of resources should be considered a program. The results of the organization require that the separate projects (and their resources) be managed in a coordinated manner. (If I haven't already mentioned it too many times, you might want to check out my PMI paper on "Program Management - Turning Many Projects into Few Priorities" at www.focusedperformance.com/articles/multipm.html.
.
(FLAME ON -- By the way, does anyone else have a problem with Gantthead's refusal to recognize URLs in postings? When I typed the previous refererence in with the "http", the whole URL disappeared in the post. The purpose of the internet is to allow such cross reference. Trying to set up an insular system that keeps you in its borders doesn't really help the knowledge process, IMHO. -- FLAME OFF)
.
That being said, I agree with Bob Wallace's suggestion of the role of Program Manager to that of the PMO, at least in looking at the narrow technical PM responsibilities. In the case of the multi-project organization I describe above, management of the program must be the responsibility of management -- the combined team of project and resource owners. A Program Manager/PMO must guide individual Project Managers in the appropriate (AND COMMON) planning, scheduling, tracking,and reporting processes. They must also help the management team interpret the combined reporting, preferably up-front through education, and in an on-going manner as well, helping project managers, resource managers, and project owners make appropriate decisions for the benefit not of individual projects but for the goals of the organization related to those projects. An additional Program Manager role would be to facilitate the management team in prioritizing projects that make up the program, and identifying organizational/system constraints (including resources) that are needed to be understood if the individual projects are to be scheduled and promised in a rational manner. (Without this last understanding, the organization runs the all too common risk of trying to put 10 pounds of projects through a 5 pound pipe.)
.
In an offshoot of this line of thought, IMHO, there is entirely too much emphasis on Project Management as a profession. The technical aspects of the PM processes do not have to be that all difficult, if thought through and presented in a straightforward and holistic manner. Project management, and especially Program Management, or at least the ability to interpret the outputs of PM processes needs to be a skill -- an arrow in the quiver of all levels of management. After all, running a business is nothing more than a combination of operations (day-to-day, repeated and repeatable stuff) and multi-project (program) management (to accomplish improvements, changes, new stuff, etc.). There is no more intense multi-project environment than a small-to-mid-size, growing business with a lean management team. In that case, a program manager can be invaluable to help management figure out what they need to pay attention to today to meet the goals they have set for themselves.
The PMO is the nerve center where top level managers can be told, with a single voice, the status of a project or major program that has been placed into logical subsets or building blocks of smaller projects to achieve the end objective. The PMO spans across the horizontal of the organization in support of specific business unit projects. Project teams are built from the resources from each business unit as required to accomplish the objective. I have seen the implementation of the PM role by the assignment of PMs to each businesses unit and a small PMO that provides nothing more than oversight management. This is not in the best interest of the firm by denying the benefits of building best practices, PM mentoring, and standards for reporting project status. The exception maybe is a BU that is self-contained like the development of software applications. This person is totally focused on the delivery of a product to support the overall delivery to an external customer. But this PM is the software development member of the larger project team.
The PMO orientation is the "now" and the management and reporting of how a product or service is being delivered. It is not a strategic planning office. The PMO may provide input to the planning effort for resources but not in setting long range direction. I also believe the PMO provides the sales team an asset to help close the deal by providing to the customer how the product or service will be delivered and the management of that process.
Lastly, the PMO is staffed with those with a management orientation and ability to understand the technical aspects of the program/project they are managing.
A couple of questions for others: Does the PMO have a role in the discovery phase of defining customer requirements? Who should the PMO report to in an organization? What level of detail should the PMO have in project fiscal and human resource utilization and management? Saving Changes...
Anonymous
I have just completed an assignment to get the supply and distribution division of an Oil company to change their approach to IT system implementation project planning by the implementation of a central PMO.
The problem they had was a history of isolated local planning and subsequent delays and unnoticed dependancies on key staff until it was too late to do anything. There was no collection of lessons learned from previous projects as there was no central programme office function to collect such information and share it.
Local project managers business deadlines drove their system implementation projects. This meant that the central shared team from head office had minor control on their diaries. Third party suppliers who supplied installation and training services were in effect able to dictate what was done and when according to their availability.
All of the symptoms above were recognised in isolation and the will was there to improve but it took someone acting in a Program Coordinator role to get to the bottom of the problems and the Program Management Office that was implemented was a one step cure to all of their previous difficulties.
The minor price to pay is that now when new implementations are identified the local Project Manager has to have a meeting with the Programme Manager to clarify roles and responsibilities and the operation of the PMO. There are benefits to the local Project Managers also, however, such as a central set of core template implementation plans based upon previous experience which they can use and access to lessons learned.
I offer this as an example of where a PMO offers problem solving benefits and the central collection of lessons learned from previous projects as an often overlooked function of the PMO as a knowledge management service also.
As an answer to previous questions re. reporting the PMO in the case I describe reported to a business information manager who sat between the business and the IT services sides of the division. That person had responsibility for the fiscal and staffing issues. The PMO should not (I feel) have direct responsibility for staff and fiscal control although they should be responsible for collection, monitoring and reporting on such issues. The reponsibility should remain with the various personnel and financial functions. People have to trust the PMO to be neutral on these issues as mistrust may lead to barriers being formed. Saving Changes...
Craig PrindleSenior Director Enterprise Performance Management| BRMiOak Hill, Va, United States
I often find initial difficulty discussing the topic of 'Program Management' since there are several flavors of 'Program Office' and no one definition does or should fit them all. Some of the 'flavors' and an example of name variations to distinguish amongst them:
a. Project Management Office (PMO): one office overseeing an entire organization's portfolio of projects; providing Project Management training and best practices, monitoring portfolio Dashboard Status, etc.;
b. Program Office: one office overseeing several related projects (e.g. Y2K Program Offices);
c. Program Management Team (PMT): one office overseeing a single, very large program/project (e.g. an office overseeing the work of a Systems Integrator for a very large implementation; perhaps involving another vendor who performs Independent Verification and Validation (IV&V));
d. Project Office: Project and Process Mgmt experts and tools (e.g. Computer Associate's Process Continuum or Primavera's Team Play and associated methodologies, templates, and scheduling tools) for an entire organization or very large department. Saving Changes...
RAJESH K LProject Manager, PMP| Bharat Electronics, Bengaluru, IndiaBengaluru, Karnataka, India
