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
1st 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.