Is the concept of the PMO obsolete? PMO discussion continues.

PMOs will focus on proving their worth and driving innovation

Continued poor project performance in many organisations will result in more PMOs being terminated.

These are 2 out of top10 trends 2013 for project management, which were identified by a global panel of ESI International senior executives and subject matter experts.

“Gone are the days when just implementing a methodology and creating a project dashboard convinced corporate executives that the PMO was pulling its weight. More organisations are conducting PMO “audits” to identify areas where the PMO can accelerate its evolution and provide higher levels of value to the organisation

ESI research shows that the average life span of the PMO is about four years.That number is likely to drop if project performance continues to underwhelm executives and stakeholders. PMOs are created to improve project performance; yet, few organisations give the PMO enough resources and authority to do the job”

After my interview with Peter Taylor on successful PMOs I asked this question to my colleagues from Thomson Reuters and here are some answers.

If you want to learn more on: “Leading Successful PMOs. How to build the best PMO for your business and keep it relevant” join PMI Gdansk Branch workshop on 1^st February 2013, Sopot, Poland. More details on the workshop can be found on PMI website. To sign up for the workshop please follow the link.

Ian Whittingham, Program Manager

“I have been holding an on-going conversation on this topic with one of the external guests who attended the London PM Unconference back in September.  He has just posted a blog that is timely to this discussion. You can read that blog posting here.

What sparked our conversation was a mutual recognition that there is a necessary tension in applying project management techniques to solve business problems that demands both a common framework of concepts, processes and activities that need to be adhered to in order for teams to work in a concerted and competent way BUT there also needs to be enough 'give' in the framework to allow teams to improvise and depart from standards and procedures if it is appropriate to the circumstance of the project to do so.

Thus, a PMO needs to define and enforce the common framework so that we don't fall into an anarchy of fragmented and incompatible project management processes and practices BUT it also needs to permit departure from that framework if it is in the best interests of the project (= business problem successfully solved) to do so. As accountable owners for how projects are performed, it is intrinsic to the functioning of PMOs that they enforce policies and standards. Acting in a way that signals permission to depart from the framework invites the danger of undermining the value of mandated policies and standards and weakens the authority of the PMO. This is why PMOs can sometimes feel like your big brother, stopping you from doing what you want to do simply because he's bigger than you.

The trick here is to find the balance between 'just enough process' to enable everyone to play the same game but 'loose enough' to facilitate and encourage inspired improvisation, because that's where some of the biggest payoffs in project success often come from. The evolution of Agile as a means of creating successful software illustrates just how this balance can be achieved. Perhaps the solution is to help PMOs find a similar way to evolve in the same way that Agile did?”

Anthony Allinson, Head of Customer Support

“I have just read a great book, No Straight Lines, by Alan Moore. I say great because it really made me think about collaboration outside the hierarchy, the power of connecting people, the speed at which we can get things done in big conversations and how much we can enjoy ourselves and each other if we do things differently. It is also scandalously badly edited and repetitive. It is also dogmatic, even a little cultish. This made me angry at times as I felt it undermined the powerful ideas in the book by asserting that we could get rid of all linear control. What? All of it?

Strict adherence to the No Straight lines philosophy would declare the PMO to be obsolete. We can certainly rely on it less. But not at all? Replacing one dogma with another (which is what really made me angry about this book, despite the fact that I read it all, scribbled all over it, agreed with 90% of it and then put it in the post to friend) strikes me as a little dangerous.

The PMO challenge is always to balance throughput, efficiency and reliability. The Goldilocks PMO (the one that is just right) will vary from day to day, company to company, portfolio to portfolio, project to project.  We have the luxury of being paid to think for a living. It's never dull is it.”

James MacManus, contractor

“What would I expect a PMO to actually do?

·         Set standards for how projects are run, ensure they are followed and provide guidance for project managers.

·         Maintain project management resources: standards and guidelines, templates, check-lists, project review outcomes, lessons learned etc.

·         Collect project data (progress, status, RICs) and collate it for consumption by management.

·         Assist in prioritising requirements, forecasting demand and producing scheduling and resource planning information.

·         Oversee or facilitate project reviews and appraisals.

A bad PMO will have a single set of templates (one size fits all) that it expects every project manager to complete, no matter what the size of their project. A good PMO will offer different formats, engage with the project manager and guide them to the most appropriate data capture mechanism. A failing PMO will have probably tried the first option, failed to get compliance and then given up trying. The key to a good PMO is knowing what is appropriate and striking a balance between necessary constraints and oversight and unnecessary paper-work and restrictions. To do this they must engage with their PMs, understand what it is they are trying to achieve and be conversant with their methods - Agile or otherwise. If there is no PMO, then who will take responsibility for the activities I've listed?”

Nicholas Whitford, Business Analyst / Agile Product Owner

“Good description James, and I think describes why PMO value gets questioned.

They effectively provide processes and tools to make sure projects are "run properly" - but what does that mean? Well, in the simplest form, they are to provide support to make sure projects are delivered on-time, in budget and satisfy a set of requirements.

This assumes the projects require support - processes and tools. I suppose the study has proven that perhaps many professionals, when made more accountable (rather than diluting the accountability) rise the occasion and make sure the right processes are in place in order to deliver the right outcomes, which is what we're all about. Delivery is always more important than how you got there.

Reflection is the tool to make sure you make delivery more efficient each time - and perhaps that's what the PMO should be tasked with, making sure that over time, projects become more efficiently run (less deviation on time and budget).”

Ken Lamparter, Global Program Manager

“There are a number of good comments here.  I have seen some very good PMO's (and one very bad example of a PMO which was a bureaucratic nightmare). Some thoughts of mine on the subject.....

1) PMO's should have senior sponsorship - they must be guided with a purpose on what they are trying to achieve.  Peter Taylor's points therefore are very valid that senior managers know who the PMO are. PMO's should be guided by the CTO / CIO etc and have clear objectives that are aligned to the CIO/CTO's objectives.

2) The purpose of a PMO I believe can be summed up as "ensuring that the key projects keep to the guidelines set, but that the guidelines can and should change depending on the project". I totally agree with others in other discussions who have said that a good set of project guidelines get people up and running very quickly, but we should always look to challenge and then improve them.  We should also allow some flexibility. PMO's should be able to be challenged about why a particular process or guideline is there, and if the Project Team can identify a modified process that meets the project teams needs while also meeting the end result expected by the PMO then that flexibility should at least be discussed.

 3) The PMO should not be seen in an ivory tower dictating project process to the project managers. It should be engaging in a dialogue with the project management teams about what is working and what is not, and then championing the good practices and fixing the bad. The PMO must ensure that there is a mechanism to make change to the overall process and also to ensure that the reasons for specific ways of doings things are understood. Never underestimate the amount of "education" a PMO should be doing.

 4) PMO should be challenged to make improvements each year. Ideally this should be as a tangible benefit... example .... save some money in the project lifecycle by eliminating or streamlining a process, or maybe to better define the project funding process so that project selection is better optimised. If you show you are contributing to the bottom line, then there is rarely a discussion on the value of any team to the organisation.”

So, is the concept of the PMO obsolete? I do not think so.