The last installment in my series about IT Organization will discuss the PMO. What does that stand for? Most often, Project Management Office, but some call it Program, others Portfolio, and though the words have different meanings which affect the focus, they all boil down to one thing: Understanding what the business needs, prioritizing it, and getting the organization’s resources behind getting it done.

The PMO’s first task is to understand what the business needs. Portfolio management is the best starting point. The portfolio managers are linked to lines of business and understand their roadmaps. This can be done by pairing portfolio managers with product managers in the business units, if they have them. Since the business units have more work than can be done at once, the portfolio manager also provides prioritization of strategic portfolio work as well as projects and maintenance work (where the line of business has reported bugs or requested minor enhancements not sufficient to group into a project). The portfolio manager must understand all work streams for their line of business and organize the work streams to fit the amount of time IT management allocates to that line of business.

Program managers are typically assigned one-to-a-program where the scope of work is strategic and large – to the point that the program manager may have a project manager or two working for them. Project managers will typically work on more than one project at a time, providing project management shared services to the enterprise. Project and Program managers should be certified by the Project Management Institute (PMI). Of all the certifications I have taken or seen, this is the most meaningful. It requires the candidate not only to be able to recite their taxonomy, but also to demonstrate several years of experience actually doing the job.

The second segment of the PMO is the Systems Analysts and Business Analysts. This group is the font of knowledge of what capabilities the business has. These analysts elicit requirements from the business users and translate them into specifications for the developers. They become the experts on the details of what must be done, and work in conjunction with the subject matter experts and architects to figure out the ‘how.’ The strength of the analysis group allows the development group to become centers of excellence for their technologies rather than silos aligned to the business units.

The head of the PMO is the natural leader for the Project Governance group, but a key characteristic that must be sought in this position is the balance between delivering when needed and following the process. It is too easy for the leader to get caught up in making the process king and becoming a bottleneck in achieving the business’ strategic goals.

I watched an organization struggle trying to make their PMO fit this vision, but left before it was implemented. The difficulty they had was getting sufficient knowledge of the business in their Business/Systems analysts, when starting from the ground up. Does anyone have any suggestions for how to accomplish this?