Starting a Project Management Office

Companies today are constantly seeking new methods for increasing the reliability, quality and cost effectiveness of IT projects.  Although the concept of the Project Management Office (PMO) is not new, it has recently become one of the latest crazes among CIOs of major corporations.

CIOs instituting PMOs are doing so very carefully.  The investment in a PMO is not small and there isn’t an immediate payback.  PMOs require retraining of staff or bringing on additional staff, office space, equipment and setting up of new policies and procedures.

Why a PMO?

Companies have been struggling with poorly planned IT projects since the beginning of the computer era.  They are continuously over budget, and most are late or don’t deliver the planned requirements.  The leaders of most IT projects tend to be technical and have little or no background in business issues and the importance of conserving project money and time.  By instituting a PMO, the CIO hopes to save money, improve estimates of delivery, utilize staff more efficiently, and ultimately have happier corporate customers.

Don Narup, CEO of CRA Information Services, a software development company in the banking industry, says “doing large projects is hard enough.  We don’t want to approach each of our projects as if it is our first.”  Learning from your mistakes, and the mistakes of others is a powerful motivation for implementing a PMO.

When is a PMO a good idea?  This depends on your culture.  If you have IT projects that come in on time and on budget, then read no further.  There is little to gain by putting in a PMO.  If your IT group is struggling and chronically late and/or over budget, or seems to have too many failed projects, then a PMO may be right for you.

A PMO is overhead, and is expensive.  Make sure that the benefits out-weight the costs.  In order to justify a PMO you must be doing a lot of projects.  A good rule of thumb is 25 or more projects in the medium to large project size per year indicate you should have a project office.  If you have less than 25, look closely at whether you want to proceed with a PMO, it may not be worth your while. 

Initial Goals of a PMO

When companies are first exploring the PMO concept, some of the most common motivations are:

• Increase ROI of IT investments.
• Lower costs.
• Instill a project management discipline in IT projects. 
• Improve delivery estimations
• Develop better quality
• Implement standards
• Increase utilization of staff
• Eliminate failed projects.
• Reduce and control the number of projects.

As it turns out, these goals often change over time.   Lowering costs and increasing ROI is nearly always at the top of the list of goals for PMO instituting companies, but isn’t generally considered a major goal three years after initial implementation.  In fact, a survey conducted by the Project Management Institute (PMI) shows that 74 percent said that a PMO did not produce a clearly traceable cost benefit.  However, the survey did show that over half the companies responding had noticeable improvements in the success rates of their project.  The rest either didn’t see the reduced failed rate or didn’t track this metric (26%).   Despite this, in my estimation, if you are increasing the success rate of projects, then that has to be increasing your project personnel productivity and this can translate into indirect overall savings.  Most of the respondents to the survey also found that improved ROI was elusive to demonstrate.

What are the top benefits of companies that have solid PMOs?  The top benefits are:

• Improved project success rates
• Instilling Project Management Disciple.
• Better on-time and on-budget delivery.

Implementing a PMO

There is no uniform recipe for success.  Every company has a different corporate culture and each will institute a PMO differently.  It is very important for a company to closely align their PMO structure to their corporate culture.

The basic models of PMOs vary by company, but can be summed up in two major categories.  These are the centralized and consultative.

The features of the centralized model include:

• Professional project managers in centralized pool. 
• The project managers are responsible for running projects successfully.
• Project Managers typically run one large project at a time, or several smaller ones in different life cycle stages.
• A Vice President (or Director) of Project Management runs the PMO.
• Project managers have dotted lines to their project’s sponsor and the IT group responsible for the project. 
• The project managers generally have lots of decision making power on their projects.
• There are clearly defined methodologies for running projects. 
• Project management tools are standardized.
• The Corporate project portfolio is managed by the PMO.

The features of a consultative model include:

• The PMO has few project managers, if any, compared to the centralized model.
• The PMO has consultants who advise the IT department and their sponsors on running projects.
• The project managers are members of the IT department or the sponsor department.
• Typically the projects are lead by someone who is technical with the advice of a PMO consultant.
• Project management tools are recommended.
• Project methodologies are recommended.
• PMO consultants will have many projects that they are consulting.
• The PMO consultants have little direct control on projects. They can only influence.

There are combinations of the two models.  Some companies will have their smaller projects led by technical leaders using the PMO as consultants, but when it’s time to put in a new manufacturing system or upgrade the accounting system, they opt to have a professional project manager run the show.  Every company is different in the size of the projects that go to the PMO for managing.

Structure of a Centralized PMO

PMOs typically consist of a PMO VP or Director, a project coordinator, Business Analysts, and project managers.  Subject Matter Experts (called SMEs) may also be assigned temporarily to the PMO.  They each have their roles for improving project performance.

The PMO VP/Director is the leadership of the PMO.  S/He is responsible for all the projects that they are managing.  Their duties include:

• Provide management oversight and leadership to the PMO.
• Organizational control of projects and resources.
• Manages and reports to the CIO and executive management on the portfolio of projects.
• Manages the prioritization of projects with upper management.
• Ties projects to company’s strategic and operational plans.
• Leads periodic project reviews with project managers, sponsors and IT management.

The project coordinator duties are:

• Maintains projects history
• Generates project reports
• Maintains the portfolio of projects and their respective priority
• Assists in planning meetings, training and other administrative duties.

The Subject Matter Expert’s duties are:

• Work with the Project Manager and Business Analyst in their area of expertise.
• Knowledgeable about industry best practices and standards.
• Act as development auditors.
• Support QA processes.
• Support usability planning and testing.
• Development of end user documentation.
• End user advocate.

The Business Analysts duties are:

• Expert in the collection of requirements, use case development and process definitions.
• Assist with training and selection of project specific tools.
• Develop specifications that are handed off to programmers.
• Work with QA to develop test cases.
• Provide guidance and training to SMEs.

The Project Managers duties include:

• Organizes the project plan.
• Oversees project goals and priorities.
• Responsible for budgets and schedules.
• Monitors and reports status to PMO Director, project owners and stakeholders.
• Manages project staffing and resources.
• Continuously evaluates project for scope creep, unidentified risks, and other problems that may show up.
• Typically performs formal reviews with the PMO managment.  This is often done biweekly or monthly depending on the project and whether it is in “trouble”.

What a PMO Can Do

Although PMOs vary from company to company, there are several areas that generally are considered to be in their domain.  These include:

• Project Support.  Provide advice to business units as well as IT departments.  This is both pre- and post- project startup.
• Project Management Methodology.  They are the keepers of the standardized and PMO supported “way” of doing projects.  There is a lot of time and efforts put into making sure that projects are consistent in their approach, use the same project management tools, and report to management in the same formats.
• Training.  This is one of the most important tools in the PMO arsenal.  Training all project managers in a consistent reproducible manner is an important step in implementation of best project management practices. 
• Business Unit Training.  PMO works with the business units teaching them the best way of approaching a reengineering project, roll outs, new application development, etc.
• Resource Allocation.  Keeps the best people, equipment and space allocations for the most important projects with the greatest need or return.  This also includes protecting staff from switching or supporting old projects that distract from their new project.  This can be one of the biggest components of late and over budget projects.
• Providing a home department for project managers.
• Defining and Refining best practices.  Looking carefully at how your company does projects.  Taking the best practices from the successes and analyzing the failures for practices to avoid. 
• Keeping the projects history.  This becomes a resource and baseline for analysis of how well the PMO is performing.
• Project management software tools.  The selection of project management tools is important for the consistency of project executions.  All project managers are trained on the same tools and use the same tools.
• Portfolio management.  The PMO is a central location for the management of the corporate projects portfolio.  The ability to see the projects all in one place leads to the ability to cancel, scale back or delay low priority projects.
• Portfolio prioritization: If there are limited resources available for projects, as is the case in most IT shops, then having a centrally controlled project portfolio allows management to prioritize the projects based on whatever measurements management wants to apply.
• Portfolio criteria. The criteria for setting priorities on projects can be anything from “Return on Investment” (ROI) to a government mandated regulatory requirements.  Be sure that your criteria are aligned with the company strategic plan.
• Consulting Services.  Often a business unit will want to bounce some ideas around on proposed automation projects.  The PMO will often be brought in early to help determine whether the project is worth going forward with.

The true value of a PMO is in its strategic value.  By strategically managing your portfolio and only executing the best projects, making sure that staff is working on the best possible position for their skills and experience, and reducing the number of failed projects can all lead to cost benefits, even if they aren’t easily quantifiable. 

PMO Metrics

There are many metrics that can be applied to a PMO’s effectiveness. We are going to discuss the three most obvious:

• Projects cost estimate accuracy.
• Schedule estimate accuracy.
• Stakeholder satisfaction. 

These metrics seem fairly simple at first, the projects cost estimate accuracy is an aggregate that is compared to last year’s aggregate average.  The same with schedule estimate accuracy and stakeholder satisfaction.  The problem is, most companies implementing a PMO don’t know how projects have performed in the past.  They typically record what the project cost and schedule was at the beginning but don’t accurately record the change orders once the project is underway.  This means that at the end of the first year of a PMO, you don’t really have a solid pre-PMO comparison base.  After 3 or 4 years, you can compare with prior years to determine if the PMO is improving.

It is possible to compare to industry averages, but this is filled with inconsistencies.   There are just too many variables that you can’t be aware of.  For example, where do these numbers come from?  Is there wishful thinking involved?  Have cancelled projects been included in the stats? Most companies don’t report internal financial information on a project level to outside sources, so these numbers are generally off-hand estimates by someone filling out a survey.

The best metric of a PMO can be seen when handing the CIO the financial status of the portfolio of projects with a reasonably good assurance that it is an accurate representation of the projects that are being executed.

Getting Started

Getting started can be more difficult than any other phase.  Here are a few pointers to take a look at before digging in.

Most companies starting a PMO look at the culture of the corporation to determine which variation of the two models to implement.  To some extent, you have to look at the internal politics and figure out how much resistance you are going to get versus how much heat you are willing to take and how much support top management is giving you. Some pointers are, if you are looking for low risk and small gains or your IT group already is performing at high levels, the consultative approach may be best.  If you are willing to take greater risks and demand the larger returns or if your IT group is troubled, then move toward the centralized approach.  Remember, every PMO is different, so you may want a system that is somewhere between consultative and centralized.

Middle management resists change, especially if they feel their territory is being encroached upon.   There will undoubtedly be managers that are resisting the changes needed for a successful PMO.  The advice on this is to get the backing of top management.  Sell them first and make sure they understand that they are going to have to stand behind you.  A solid front of top level management goes a long way toward reducing outright resistance.

Look at what other companies in your industry are doing and how they implemented a PMO.  This can be important because you will be learning from their mistakes.  Talk to anyone involved that you can.  Also look at sister companies that have implemented a PMO, they might be able to give you advice.

Look at best practices and industry standards as described in professional organizations.  This can be a good source for getting started.  Remember, no two companies are the same, and no two PMOs are exactly the same.

Be flexible.  Sometimes you won’t be able to get everything you want, so be willing to have a give and take on some issues.

Once you have the initial plan in place, start with small pilot projects.  Take your best project managers and plan not only the project, but how you want to run projects in the future.  This process will create the first draft of your policies and procedures.   Part of the PMO process is to refine these policies and procedures over time.

Get some outside help.  If you haven’t a clue as to how a PMO works or what it should do, then bring in a consultant to help you.  They are expensive, but will save a lot of time and money in the long run.

Don’t try to institute an authoritarian PMO centered on approving or disapproving projects.  The stakeholders must be involved with the decision making process.  Watch out for “big brother is watching” syndrome. .  Make the PMO as collaborative as possible.

Some items to consider in your new PMO include:

• Get top management squarely on board before starting.  This alone can make the difference between a successful PMO and a failed attempt.
• Create a standard methodology for managing projects.  Make sure that everyone possible is on board with the process.
• Responsibility needs to be squarely on the project manager’s shoulders.  They must take responsibility for following the PMO outlined processes, producing the required management reports and tracking their projects closely.
• Categorize your projects.  A software development project doesn’t necessarily need to be run exactly the same way as a software upgrade, or hardware replacement projects.  However, make sure that similar projects are performed in pretty much the same way. 
• Review what information you are going to want from a project.  This may include different reporting at different points in the process.  For example, you may require an ROI analysis before the project kicks off and cost and schedule performance reports during the project.
• Have a procedure in place for resource allocations.  Know the rules and make sure that everyone else does too.  Resources are often the most contentious issue when coordinating multiple projects.
• When evaluating projects, always review the company’s strategic plans.  Make sure that projects are in alignment with the company strategy.  This will help drive making the proper project decisions.

Conclusion

When planning a PMO, always remember its role is mentoring, supporting, coordinating and supervising.  The PMO:

·         Works at bringing up the level of understanding on how projects are run. 

·         May be in a supervising role and manages the corporate portfolio of projects.

·         Is an interface between the business units and IT and understands both of worlds.  

·         Standardizes the way projects are run applying best practices and standards. 

·         Promotes optimal utilization of resources.

 Author Bio:

Lawrence (Lance) Geeck is managing partner of Geeck Consulting Services (www.geeck.net.)  He has 30 years experience in managing software and hardware integration operations in roles such as CIO, CTO, Director of Development, Director of Project Office and as a strategic consultant. Lance can be reached at lance@Geeck.net.