The Agile PMO

If you’re building a PMO and have a 3 year plan – drop it now! It probably will not work. If you’ve got portfolio management scheduled for introduction in September look out. If you’re two years into your PMO build and can’t figure out why you have no traction and support is slipping, then I may just have the answer. Or I might not, but here are some thoughts.

As you’ve guessed by the article title I am going to suggest that we steal a technique from the software development industry. While I am not an agile expert by any means, there are some very successful practices that you can employ while building and growing your PMO. For you Agile gurus out there, I am about to butcher the technique so you may want to look away. Here are some of the tenets of an Agile methodology that we can adopt.

Iterations: Agile methodologies have a focus on short cycles that produce demonstrable deliverables. In software the deliverable is working code. In a PMO it would be one report, process, form, method, class, etc. For example, you might have a plan to deliver a project pipeline governance process in 3 months. Under a non-agile approach you would plan out the methodology, the forms, and the activities. After three months of analysis you would demonstrate your new procedures. And then everyone would want changes.

In an Agile methodology, you might plan to develop the pipeline report first. In two weeks you would develop the report and show that to your stakeholders. At that time you would get direct feedback which may cause you to change direction. Because you have done only a small amount of work, you can easily redirect future work with only a small adjustment. As you progress through the project, you can make incremental course corrections creating only what is needed and creating that sooner.

Product Owners: The product owner is like a sponsor on steroids. Where a project manager might report to the project owner once a week and give status updates, the product owner is an integral part of the development team. The product owner is involved in the day to day decisions and activities. Using the example of a 3-month pipeline governance project again, you might visit with your sponsor weekly and give updates on progress against the plan. At the end of three months the sponsor will view the completed product.

Using an Agile approach the product owner is part of the daily decisions that make up the final product(s). When the product owner sees something they want to change, they do it immediately. They add or remove components as they are being built. This ensures that the final product meets the goals and expectations. There are no surprises after 3 months of hard work. The product owner has seen everything as it was being created, and has made adjustments wherever needed. Imaging following your new car down the assembly line and picking out what you wanted all along the way, as opposed to waiting until the car showed up at the dealer.

Product Focus: In many projects today, we tend to discuss and focus on the progress the project is making against the plan. We report on risks of not completing the work on time. We have red/yellow/green status reports on scope, schedule and cost. All of these are great, but the do not tell anything about that which is being created. It is vital to understand our costs, but not sufficient.

Agile focuses on the end result or product. The goal of agile software development is “working code.” The primary goal is to create something that works. In building a PMO, a concentration on costs or schedule can divert focus from the actual product(s) being built. Keep your attention first on quickly building something of value. Show your working product frequently and get feedback.

Communications: Agile is very clear on the importance of face-to-face, direct and frequent communications between all team members. This may not be as big a problem with PMOs as it is with software. Unfortunately when we get into “project” mode, we tend to formalize communications into such things as status reports, weekly meetings or presentations. We schedule our weekly status meeting and our monthly presentations. Often the reports are not read, and the meetings are missed by key stakeholders. We produce our information and it is often not received. Unfortunately, the project still proceeds since no response is considered acceptance and approval.

Agile advocates face-to-face discussions. It is difficult to ignore someone standing in your office. Further, you are talking about the work itself and not about the progress made. Show your stakeholders incomplete deliverables and ask them questions, get their ideas. Do this constantly and not on a scheduled basis. Granted you may need to schedule time here or there, but make it more informal and much shorter – 15 minutes on one topic rather than a one-hour review of the project. Whenever possible, work towards a face-to-face conversation. I know virtual is in and there are many advantages to diverse, global teams. The truth is that mankind has been doing face-to-face communication far longer than video conferencing. We are better at it and we communicate more information more accurately that way.

As always, I hope there is something you can use here. Some of this may be useful for you, some may not. I'm not presenting this as an all-or-nothing or comprehensive solution. Pick what makes sense for you and throw the rest away, or save it for later. It is YOUR PMO.

Planview's PMO 2.0 Survey

If you have not read Planview's "2008 PMO 2.0 Survey Report" or watched the webcast, do so now.

I've now read the report for the second time - yes, it is that interesting. I also wanted to make some notes. Let me first compliment Planview. This is an excellent work and continues to reinforce their leadership in the PMO space. Terry Doerscher is their Chief Process Architect and driving force behind the PMO 2.0 initiative, and the chief contributor to Planview's thought leadership. No, I am not getting paid, and no I do not have a Planview system. I ran a PMO that had one and liked it very much, but no kickbacks (yet anyway). On to the survey.

The survey was given to over 1000 PMO directors, managers, staff and sponsors. Thirty-three percent of the respondents were directors with PMO staff and Project managers being the next highest groups. Both the target audience and the number of respondents make the information in this survey particularly relevent to those of us running PMOs. The industry breakdown was also healthy with no single industry making up more than 14% of the total (government was at 14%).

The overall message of the survey is that the PMO is growing and changing into something more effective, strategic and has a broader range of influence than ever before. Here are a few quotes from the survey report that really hit home with me.

"PMO performance, process maturity and the presence and impact of operational challenges ... showed little sensitivity to differences in organizational size.."
I love this one because it says that you do not have to be in a big company to have a big impact! The Fortune 100 does not have a monopoly on great PMOs!

"The PMO has historically be considered to be limited to supporting projects, or groups of projects arranged in programs or as project portfolios. ... survey data indicates this commonly accepted definition of PMO scope is now in the minority."
WOW - PMOs are truly evolving into the mainstream of corporate management. Twenty-eight percent of the responders say that thier PMO is involved in "all planned work and resources INCLUDING Operations."

"Over half of the PMOs participating the survey (55%) report to a C-level executive (CIO/CTO included)..."
About time I say! This also speaks to the value of the PMO and how so many companies now recognize this. Look for this number to continue to climb.

"An average of 15 functions were being provided per PMO." Again - wow. Figure 7 on Page 8 lists 37 PMO functions performed by responding PMOs. Thirty-seven, we are proviing more valuable services to the organization than ever before. No more are we the project reporting center.

While not a quote, Figure 20 on page 19 is very powerful. The figure cross references process maturity and operational challenges. It clearly illustrates how even the most basic maturity improvements can make a huge difference. Each rise in maturity reduces the impact and severity of operational challenges. Even going from level 1 (informal or undefined processes) to level 2 (defined processes but not well adopted) shows large benefits.

There are some great pieces of information in the summary as well - even practical recommendations. There is a quasi-definition of the PMO that I think better defines where we are now and how we will continue to evolve. I'll leave you with that:

"... the unique objective of the PMO is to provide a group dedicated to supporting and integrating operational solutions across organizational boundaries."

Book Review - "The Handbook of Program Management"

I just finished The Handbook of Program Management by James T. Brown.

If you are a program manager, or thinking of becoming one, you will want this book. Dr. Brown shares his wisdom on the program management without overburdening you with methodology. In reading the book, I often felt like I was having a discussion about program management with a knowledgeable and experienced colleague.

Dr. Brown clearly knows what he is talking about. His time at NASA seems to have been a large influence on his perspective of programs. There is probably no better place to learn and experience a program management culture. Dr. Brown seeds the book with "scenarios" from his extensive experience to tie a real life event to the topic under discussion.

A couple of things I really liked about the book:

• Dr. Brown is very well-read, and not just on program management topics. He sites authors such as Dale Carnage and Robert Cialdini. He understands the broad set of skills that are needed by a program manager, and he also consistently returns to the importance of people. He has a lot of charts and "tips", but the management of the people is always in the forefront.
• The book is very well laid out - 10 chapters covering the fundamentals. Each chapter contains advice, tips, and useful tools. Dr. Brown does not stress the tools, rather he uses them as examples or methods of achieving the goals. In the risk chapter he has an example of a 5x5 risk matrix, but goes on to say that a 3x3 or 4x4 will work just as well. He stresses that important point is to perform the risk analysis and management, not get caught up in the details of the tools.
• There are several quotes that really hit home. Early in the book he talks about program management being the place where "operations and project management collide." EXACTLY - we've all faced the challenge of trying to explain that a program is not a project to the project managers, and trying to convince operations that it's not a department.
  
• Another favorite that I will freely steal is "kill what's ugly while it's young" - AMEN!!! This brings to mind the practice of Spartans to take their "ugly" children out into the wilderness - well maybe not exactly the same thing, but I've seen a few ugly projects that never should have been allowed to grow.
  

So - great book - it is on my shelf, now dog eared and full of highlights. It will make me a better program manager, and I know it will help anyone else who reads it.

Two Types of PMOs - Yours and NOT yours

That’s my premise; there are only two types of PMOs - Yours and not yours.

Why do I say this - Well, I have some ideas that have been percolating for a while. Not original ideas by any means, maybe it’s just me catching up. Here are some observations that have led me to this thinking.

There is NO clear model or template for a PMO.
Try as we might with the innumerable descriptions of PMOs we can’t seem to come to an consensus – a quick web search shows these:

• General PMO
• Supportive PMO
• Controlling PMO
• Directive PMO
• Insider PMO
• Assisted PMO
• Virtual PMO
• Excellence PMO (center of Excellence)
• Administrative PMO
• Strategic PMO
• Project Specific PMO
• Organizational PMO
• Special-purpose PMO

Well, you get the idea. Some overlap there.

Everyone is doing something different
Don’t’ take my word for it; look at Dr. Hobbs study here. We’re bi-polar and all over the map.

So why is this?? Are we all confused? Are we stupid? Perhaps we are looking at this wrong? I’m going with the latter.

At the PMO SIG Symposium in November, I was leading the Accord session, and the ideas and comments from the participants really made this gel for me.

First – There isn’t a “right” PMO or a “perfect” PMO – the only type of PMO is YOUR PMO. By that I mean simply that PMOs are unique - similar certainly, but unique none the less. That means that we can apply a framework, but not a template. We’ve been trying to apply a template and not a framework.

Second – The consensus of the participants at the Symposium was that you can build a PMO from basic building blocks, but you can’t pre-define the entire organization. We need to look at PMO capabilities and services as separate entities and not as components of a whole.

PMOs are modular structures, not pre-fabs.

What we need is a framework or skeleton that tells us how to put these components together in a way that works best for one and only one PMO - YOURS.

So, there are really only two types of PMOs – Yours – and not yours.

the PMO in 2009

So a question for all of you.

Where do you think the PMO (your PMO in specific) will go in 2009? Will the global economic situation cause a rise in the use of PMOs to gain efficiencies, or will PMOs be seen as administrative overhead and mercilessly cut? Let us know how you are fareing and your thoughts on how best to take advantage of the challenges we face in 2009.

Thanks!

PMBOK 4th Edition poll

The Fourth Edition of the PMBOK(R) Guide comes out today. Rich Maltzman is taking a poll of PMs and would like to know if you *care* about this, and your reasons for caring or not. Using the following scale:
1. Exhilarated, Overjoyed
2. Excited, Very Interested
3. Mildly interested
4. Passing interest
5. Doesn't mean anything to me

...please provide your rating number and a very quick rationale as to why you chose that number. Do you refer to the PMBOK Guide often? Are you using it to study for the PMP Exam and wonder how the test changes?

The Bi-Polar PMO

In a recent special edition of the Project Management, I readan article titled “An Empirically Grounded Search for a Typology of Project Management Offices.” Now normally I stay away from articles with words like typology and empirically, but it sounded like someone had figured out why PMOs are so different. That got my interest.

Well, short story – they haven’t figured out, but they can point out some factors that result in different types of PMOs. I won’t go into everything and steal the fun, but there are a few things that just hit home and I had that “AH HA!” moment. PMOs aren’t normal we’re bi-polar.

We are not individually bi-polar (although I have had my moments). Rather the universe of PMOs trends towards an all or nothing distribution. For those of you lucky enough to have wiped statistics from your mind, a bi-polar distribution looks like a “U” with the peaks at the ends while a normal distribution is like an upside down U – aka bell curve.

Well we are not a bell-curve group. And that was really my moment of realization. I’ve worked in PMOs that had authority, control of projects, project managers and ones that had none of the above. This has been a source of personal frustration. Knowing that an empowered PMO can truly help an organization and being stuck with producing status reports is unpleasant.

The writers talk about what factors lead to placing a PMO on one end of the spectrum or the other. It’s very helpful if you are looking for a PMO manager job as these are very good predictors. Some of the factors are the size of the organization, the maturity (CMM and Project Management), and matrixed v. non-matrixed. As for the poles, they are what you would think.

I would refer to one pole as the “emasculated” pole. Here the PMO has no PMs, no authority and is relegated to producing status reports and bugging everyone else. Did that sound biased? On the other pole we have the PMO that owns responsibility for the projects; has decision-making authority and contains the PMs who are running the projects. This is the “partner” pole.

Unfortunately, the authors do not tell us how a PMO manager can change this on an individual level or how we can bring this distribution back to normal. Or even why it is like this. I think that we have still not arrived where the PMO is a recognized and appreciated part of an organization. Each of us is responsible for this whether we run a reporting PMO or a participating PMO. Those of us at the reporting pole have a challenge to excel and push the envelope. Those on the other pole are challenged to constantly improve.

I see our future as a normal distribution with the average PMO being fully engaged and participating in organization management. Project management is management, and the PMO can become the center of management excellence. No other organization is better suited to this role than we are.