PMO’s are not delivering the expected benefits

Posted by Kevin Brady on Wed 20th September 2006 at 05:42 PM, Filed in PMO

For those newbie’s to Project Management – What is meant by the term “PMO”?

PMO is an abbreviation /stands for “Project Management Office” and is an office or department responsible for establishing, maintaining and enforcing project management processes, procedures, and standards. It provides services, support, and certification for project managers.

image

The set-up of PMOs has become very fashionable recently, with rapidly increasing numbers of PMOs set-up each year. This is evidenced by salaries of PMO related staff almost doubling in the last 18 months.

So why are PMOs becoming so popular? Many of my consultant friends believe they can sell to clients the following organisational and financial benefits of a PMO:-

  • Improved visibility of project status
  • Tighter change control
  • Higher ROI
  • Fewer failures
  • More projects completed on time and within budget
  • More effective risk management
  • Reduced TCO ?
  • Better management of external partners

Furthermore, if these benefits are achievable, then clients are told that they can be implemented with little organisational or political pain. All the PMOs I have set-up myself over the years have been achieved with minimal need for change management and virtually no impact on general business processes. As a consultancy proposition, selling PMO solutions is great because they offer clients “High gain low pain solutions”. This kind of solution, sold properly, can lead to a short sales cycle with immediate low risk fee generation and the long term possibility of repeatable fees from follow-up Project /PMO audits.

The only problem with this win win solution for ailing IT departments is that a number of important surveys are starting to show that PMOs are failing to deliver the benefits advertised and listed above. For example, a research study by the Forrester group is showing that PMO’s spend too much of their time compiling reports for senior management & not enough on ensuring that projects are delivered on time and within scope. I have seen this all too often for myself.

“Its no surprise that the presence of a PMO didn’t have much effect on project failure rates”, said Tom Pohlmann an analyst at Forrester and the author of the report “How Companies Govern Their IT Spending” which was based on telephone interviews with 704 North American IT decision makers.

Why are PMOs failing to deliver the promised benefits?

Forrester offers up the following answers:-

  • PMO’s serve as “process cops & report compilers”
  • They lose sight of what they’re supposed to be doing i.e making sure projects deliver effectively

I have a few more of my own:-

  • Many PMOs employ staff who have ZERO gravitas and credibility within the project management teams they are supposed to be leading /steering towards success. Rarely have I seen heavyweight project /programme managers running PMOs and using them as a central point of project management excellence and drive behind the successful delivery of IT projects. No Project Manager is going to be steered by someone who has never been at the coal face of project management. Furthermore, I have never seen a concerted attempt by organisations to rotate experienced project management resource in and out of PMO roles in order to rectify this credibility /gravitas issue.
  • Many projects fail due to structural & cultural issues of the organisation outside of the control and influence of the PMO. Examples of this are ineffectual sponsorship, lack of user input into requirements, lack of understanding by business people of how high risk IT projects are and how difficult they are to deliver under the best conditions. These problems can rarely be changed by the presence of a PMO.
  • Many Project Managers are spin managers (please see my post Anti-Spin Management Checklist) which, in many organisations, is the only way to survive i.e by appearing to conform to the service department model which involves NEVER SAYING NO to the customer. PMOs are not going to turn spin managers into “Jedi” overnight, or change the corporate culture to accommodate them whatever the benefits.
  • Many PMOs deliberately pick staff with low integrity who are willing to participate in massaging of reports and budgets. People with these characteristics are often the antithesis of what is required to be a leader and gain the respect of others. Once a project team knows that the PMO is a “spin shop” it is the beginning of the end for a PMO as a centre of excellence and a catalyst for delivery success.
  • PMOs often fail to vary process requirements from project to project in accordance with project size and budget. Obviously a project with a peak resource load of 3 people and another project with a peak resource load of say 15 people should have differing levels of process rigor applied. Excessive management overhead on small project teams is expensive and de-motivating for project managers and their project teams.  In this respect PMOs can actually worsen project success rates.

It is clear in my mind that PMOs are not working as advertised and are certainly no magic bullet. However, I do believe well run PMOs as part of a more broad based transformational alteration of an organisations approach to IT delivery, can bring significant reductions in IT project failure rates.

 

This entry has been viewed 3218 times.

READER COMMENTS:

Hi Kevin,

I’ve read your Deming versus Taylor posting, and to be honest I was disapointed. Apart from reproducing what is publically available material (wikipedia), your only orginal statement,namely that Taylor and Deming ideas aplly only to manufacturing is factually wrong.

The Toyota Production System has applied Deming ideas to New Product Development for decades. New Product Development is the Design and Development of new ,b.Products</b> (Cars in the case of Toyota) and is a one off exercise just like Software Development.

I have some suggested reading for you: Lean Software Development, Mary Poppendiek. I also suggest that you take a look at the work of Jim Highsmith. In particular: Agile Project Management.

Your main criticism of Agile as I understand it is that it lacks Management discipline, responsibility and control. I belief this to be a mis-understanding on your part. The grand farther of “Agile” processes is Scrum and it’s central theme is mamgement process control. The difference in the approach suggested by Scrum is the use of Emperical feedback, rather then relying soley on an open loop deterministic approache (other wise known as a big upfront guess/estimate that then becomes a prediction that the Management hold the team to for the duration of the project, leading to hours of overtime, stress, corner cutting, poor quality etc).

Emperical Process Control is a scientific and tested aproach to complex system control well known to anyone with an Electronics or thermodynamics background. I suggest that you read up on the subject (Finding out how your central heating system regulates the tempersture of your home would be a good start :^).

I like your insurance example, but this has nothing to do with Deming or Scrum, (or Taylor actually), it is merely another example of poor management. An illustration of the effects of a lack of management control and oversight as you point out.

A discussion over emperical versus deterministic system control (Closed Loop versus Open loop )is an interesting one in itself, and IMO it is scientific fact, that closed loop control is more effective when controlling complex non-deterministic processes (in contrast to a big upfront project plan that after the first week everyone knows is a ‘big lie’, but carries on following anyway). Software Development IMO is a complex, non-deterministic process which cannot be accurately predicted open-loop.

Kevin, I really do believe that you are mis-guided. If you are interested in knowledge and understanding then I suggest that you take a good look at this video to gain a real insight into what lays behind Scrum:

http://www.infoq.com/presentations/The-Roots-of-Scrum

On the other hand, if your sole interest is to promote your Consultancy, then your mis-information is no better or worst then the “Agile” consultanties that you have chosen to rebuke.

The problem with our industry is that anyone can set themselves up as an expert and in the end it is up to the Buyer to Beware!

Paul.

Posted by Paul Beckford  on Mon 2nd October 2006 at 12:31 PM | #

Commenting is not available in this section entry.