Tag Archives: pmo

A Tale of Two PMOs

I recently came across a statistic that states that 50% of all Project Management Offices (PMOs) fail. It seemed high to me. But when I reflected on my own personal experience in setting up two different PMO’s I can tell you that my experience supports that statistic. One PMO was successful and one PMO was not. Of course two experiences is hardly a solid scientific sampling. None the less it has prompted me to bring you a tale of two PMOs.

The first PMO I was involved in had support from the very top. Our Executive Vice President was very much on board with the idea of the PMO. She could see that projects were floundering and she could see that each project was being managed differently and that this was leading to confusion. And so she tasked one of her directors with the creation of a project management office or PMO. In turn he brought in an expert in project management and an expert in PMO organization.  He selected some of the top project managers from the department and brought them into the PMO. Together they conducted research and went to seminars and hired the best consultants. Everything looked good.

The Vice President told all of her directors what was happening and how she expected their full support. They all enthusiastically declared that they couldn’t wait for the results. They were all very happy to know there was going to be a group of people who was going to help them run their projects more efficiently. At least that’s what they said in public. Behind the scenes the PMO team was having a different experience with those same executives. It seemed that most of those executives were too busy to meet with them to discuss plans and processes. It seemed that those executives didn’t have any resources available to meet with the members of the PMO. And when members of the PMO invited people to discussion sessions and training on project management methodology nobody showed up. When asked about their participation, every executive denied that they were refusing to participate with the PMO. They blamed schedules and resource constraints and said that the PMO was being unreasonable and so it went back-and-forth with no real progress or solution. Out of desperation the members of the PMO started working around the executives. They started going to some of the people who were running projects and who were new to running projects. They offered help. They offered mentoring and support.

By working directly with those who could benefit immediately with what they had to offer, the PMO began to experience some success. But alas it was too late. The bickering back and forth at the top level and the lack of progress lead to the dissolution of the PMO. The members of the PMO all learned an important lesson. We learned that company culture played such an important part in the success of a PMO. What we experienced was our own company culture. Our culture was nobody ever said no to something in public. Nobody said they wouldn’t do something or support something. They just did not do it. And if someone decided not to do something, nobody not even the Executive Vice President would make them do it.

Grassroots was the way in which we experienced some success. By grassroots I mean going directly to the people who are going to use what you’re creating and engaging with them and helping them and having them help create your processes and your methodology. And that leads to the tale of PMO number two.

A few years later at the same company a few of us who had worked on that first PMO found ourselves working together in another division. This division had a small PMO and they wanted it to grow. Surprisingly those of us who have participated in the first PMO were called upon to help. It was surprising because they knew our previous attempt had not been a success. We were called upon because we had the battle scars or lessons learned from the other PMO. We knew the company and we knew the culture. And use those lessons learned we did. We really socialized our PMO. We had an open house with games and suggestion boxes and of course fun food. We invited people to planning sessions, we walked around and spoke to all of the executives in informal and formal settings. We asked for their opinion, we asked for their feedback, and we did not announce or create any new policy without the involvement of the majority of the group. Was it a lot of work? You bet. Was it slower? Absolutely. But the time we spent doing this was time well spent.
It was part of the plan and part of the process. We didn’t make unrealistic deadlines for the growth of the PMO.

We created deadlines that assumed input from all concerned parties. We created drafts expecting people to come and tell us what they hated and what they loved. We assumed an attitude of “We are the PMO how can we help YOU succeed. Did we make everyone happy? Absolutely not. There were definitely some people who still did not trust us or the idea of a PMO and wanted to do things their way. Some of them came around, some did not. But in the end by working within our culture we were able to support projects and bring about positive change. And that was really the point.

If you are curious about PMOs and you are looking for ideas on how to move forward with a PMO (and also Project Portfolio Management), check out this free eBook from Keyed In Projects on Why PMOs Fail, http://www.keyedin.com/keyedinprojects/resources/ebook-why-pmos-fail

There is no reason for you to experience anything but success!

Who values the PMP?

Wish me luck
Image by _Pixelmaniac_ via Flickr

Guest post by Ian Bond

I’m confused.? As a job-seeker, I read posted job openings carefully, trying to figure out what they really want.? Repeatedly, I read that Project Managers need x-years of experience, certain technical skills, and a PM track record.

But buried at the bottom is the cryptic “PMP Certified” comment.? Half the time it’s not clear if it’s required or preferred…or if it’s just a cut & paste mistake.? Do they want it, need it, require it, or just fear it?

If they want it, I’ve got a shot.? I’m studying, and used PM skills and strategies right out of the PMBOK.? My results speak for themselves – running projects since the 90s that smoothly took our mid-sized company from Novell to NT to Windows to Active Directory without a hiccup.? So bring it on!

But what if they need it?? What if they’re contracting with a government or some other savvy source who knows the value of a PMP, but doesn’t have any on staff?? That’s a clever way to get top-notch results and pass the costs on to the poor contractor who didn’t see it coming.? If they need a PMP certified IT guy, then I need to let them know I’m working on it.? Is that enough?? Will I ever hear back from them to know for sure?

Then there’s the mixed blessing of a required PMP certification.? There at least I can know where I stand.? At that point, I can try to negotiate, but know that it’s a buttoned up company with high standards and sharp leadership.? Not much chance they’re going to lower their expectations for me.

So who would fear the PMP certification?? My old employer perhaps, who tried setting up a PMO with a strong leader, only to find that executives found her annoying and demanding.? They wanted to keep their 70’s style processes in place, protecting the cash cow and letting every deadline slide to keep the profit numbers high every quarter.? So if it’s fear keeping the PMP out of the meeting room, the company or org is sliding down, getting pummeled by the recession.? Or maybe it’s a government agency that just can’t be bothered with too much discipline.? In any case, it’s a black hole for projects, “doomed” as Dilbert says.

Trouble with the fearful managers, is that you can’t tell until you’re deep into the interviews.? I need a job, I’m good at it,? but there are hundreds of others like me, circling, fighting to get some attention.? Maybe the black hole isn’t so bad, if there’s a paycheck in it…

Meanwhile, I’m keeping on the PMP track.? It’s clearly the future.pmp

Avoid the Same Old Mistakes by Focusing on Lessons Learned

Lessons Learned

Lessons Learned

It’s said there are no new project management sins, just old ones repeated. It’s also said that we don’t learn the lessons from past projects and this must be true, otherwise why would we keep making the same old mistakes.

In his article, “Lessons Learned: Why Don’t we Learn From Them?” Derry Simmel, board member of PMI’s PMO SIG, identifies two common problems preventing us learning valuable lessons from past projects:

  1. We think the lessons don’t apply to us.
  2. We want to get things done

“The sad truth is that these lessons learned are useful. That time spent in doing the work better is time well spent. That getting it right the first time is cheaper and easier than doing it now and fixing it later,” Derry says.

So if we accept that lessons from past projects are indeed useful and can prevent problems later down the line; how can organisations create a lessons learned culture where people not only take the trouble to learn from past projects, but actually want to learn. A culture where we apply best practices and discard bad ones.


For new initiatives to succeed it’s usually best to take a top down approach. The organisation’s senior leadership need to foster and support a lessons learned culture. This is likely to be more successful and long lasting than a bottom up approach, although this could have limited success if project managers promote it strongly themselves.

Given top level support, enough time and buy-in from project managers, lessons learned will become part of the organisation’s culture and part of its continuous improvement process.

Process for Capturing Lessons Learned

If project managers are going to actively contribute to the project management knowledge within an organisation and make use of it, then we have to make it easy for them. Nobody is going to go out of their way to do it. So it’s important to have a well defined and simple process for collecting, collating, analysing and disseminating lessons learned. It could be along the lines of discover – recommend – document – share – review – store – retrieve.


Project teams should learn to identify lessons during projects and record them for inclusion in a lessons learned report at the end of the project. This might be done as part of their regular team meetings.

A sign that a project may be having a “lessons learned moment,” is when the resources or customers are unhappy and discussing problems between themselves outside team and other project meetings. Lessons may also crop up during a project when team members identify areas for improvement.

Arrange regular brainstorming sessions with the project team, with an independent facilitator, to unearth valuable lessons. Don’t leave it until the end of the project when memories have faded.

Lessons can be discovered by asking these three questions:

  1. What went right?
  2. What went wrong?
  3. What could have been better?

Use the facilitator to document the lessons, keep the meeting focussed on key issues, and steer the discussion in the right direction.


Project managers and their teams should make recommendations. What would they do differently if they could go back and start over again?

This needs a degree of honesty that some team members may find uncomfortable. The feedback needs to be constructive and avoid getting personal. We are not looking to play the blame game here; we need to understand how things could be done better in the future.

For this to work effectively the organisation’s leadership needs to reward this honesty, and demonstrate it will not have a negative impact on individual careers.

Document and Share

It is important to document and share findings. The best way to do this is by creating a standard lessons learned report and a repository with good meta-data to help with identification. This should be kept updated with lessons from the most recent projects in order to take account of the current working environment, structures and constraints.

Standard format reports and meta-data will make it easier when reviewing multiple documents and searching the repository using keywords and phrases.


It is the job of the Project Management Office (PMO) to review lessons learned reports and pull out issues that arise multiple times. Recurring issues can be surfaced and presented in a general “read this first” list of lessons.

The PMO must look at what makes projects succeed and what makes them fail, and give recommendations that sit along side those of the project teams.


Lessons learned must be stored in a central repository with general access. Create a system for storage and retrieval of lessons. Online systems are ideal for this, giving easy access to the lessons. Most organisations have portals and Intranets that can be used for this purpose.


Retrieving lessons learned on a regular basis must be part of the organisation’s culture. Project managers should be expected to retrieve and review lessons prior to commencing a project. They should have this as part of their annual performance objectives and be able to demonstrate they have retrieved, reviewed and applied lessons wherever applicable.


Creation of a successful lessons learned culture needs leadership support as well as time and buy-in from project managers. Implementation of a simple process for collecting, collating, analysing and disseminating lessons learned is essential if it’s to be adopted.

Once lessons have been captured, they need to be made available to all project teams to help them avoid repeating problems of the past. It is important that these teams understand what past projects have to tell them and act upon that information.

History has a strange way of repeating itself. If we don’t take time to learn the lessons of the past, and moreover act upon them, we will continue to commit the same project management sins again and again. And don’t think it won’t happen to you, it will.

Remember, in the words of Derry Simmel, “…time spent in doing the work better is time well spent.”

Read more about Lessons Learned