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."

2 New projects

I've been overwhelmed lately with life things - new job, new house, moving, packing, packing, packing, moving - resting from about killing myself since I am clearly not 20-years old any longer - or even 30 0r - oh well you get the idea.

So, my two new great projects are: Building a PMO - yes again - I love this - this one is for a public sector multi-million / multi-year program and subsequently the software organization that results from this!!

The other one is with the PMOSIG. We are working on a PMO Accord that will document lessons learned and best practices from PMO SIG members. This will be fantastic as it will be a collection of the knowledge from those who have walked the walk. No theory, just tried and true experience. Also there will be multiple perspectives on the same topics, maybe even some healthy disagreement. My job on this is part editor, part contributor and part coordinator / project manager.

So stay tuned. I'll be updating the blog on the progress of both of these!

Derry

Quick thoughts on a PMI research paper on PMOs

I just finished my first reading of a great study titled: The Multi-Project PMO: A Global Analysis of the Current State of Practice. I recommend that you take the time to look this over. There are a lot of interesting findings. It will take a while to fully understand them all (at least for me). However, I did see two points that I think are vital. I am glad to see a study that reinforces them to some extent.

It’s about people. I know I harp on this – I think it is vital to a PMO. The study talks about 50% of PMOs being “questioned.” One key finding relates to the performance of a PMO and the expertise of the PMO staff (practitioners) – not the project managers, the PMO people. While not exactly an epiphany, the finding is “Expertise is critical to PMO performance.” If performance is being questioned, it follows that the greater the expertise – the greater the performance and then the less questioning.

It is about YOUR PMO. One thing that the study repeats throughout is the variability of the findings. There is not a lot of correlation between the variables (company size, number of projects, PMO organization…). There is some, and that’s important to look at. The lack of correlation tells us that what you do with your PMO in your company is really what matters the most. Don’t try to implement a cookie cutter PMO. Know your stakeholders – all of them. Understand what their pain points are. Know where they need help and attack that. If you fully customize your solution you can succeed.

Maybe we will get to the point where PMOs are implemented by the book. Where there is a checklist that everyone fills out and that determines how a PMO is built and run. I guess it is our job to move us there. (Personally, when we get there, I’ll be somewhere else.) Until that time, we can think of ourselves as craftsmen (craftspersons). We have tools and materials, but the work that we do for this one PMO, this one time, is what matters.

Week 27 - Change

This week I inherited the responsibility of rolling up all of the IT status reports into IT release level reports – which then in turn go into the Program level report (along with the Business status). Now, I have been doing the program level reports, and not sure how I got the IT ones – probably no one else wanted these – I think that I got them because (as any consultant will know) consultants are the “catch all” when a real employee doesn’t want to do something.

Anyway, the reports were a mess. I am getting 23 separate weekly reports in about 10 different formats. Some in word, some in excel. My job then is to cut and paste these babies into 4 different release level reports. Sound like fun???

Being the lazy, avoid-work-at-all-costs type of person that I am, I tried to find a better/easier way (after shamelessly trying to beg out). Well obviously, this would be a lot easier if everyone used the same format right? Well, why weren’t we doing that in the first place? Here is where it gets interesting – the answer I got when I posed that question to my predecessor was that they had tried to get everyone to use the same format, but they wouldn’t. AH HA – change resistance.

I have to admit a bit of disappointment that the only method attempted was to give the team leaders a template and ask them to use it. The follow up was to ask them several more times. When I asked what else, I was told that my predecessor did not have the authority to get them to change. Hence nothing was done. Another AH HA – responsibility without authority !

Given that I was in the same boat, needing people to change, but not having any authority to change them I had an idea. What was it that people didn’t want to change? Not the process, they were handing in weekly reports on schedule. So it was actually the format of the report – that seems like a small item, so why resist. Then it hit me – because it meant a good bit of upfront work, and these guys have “better things to do.”

So these busy people did not want to change because they were busy, and frankly the format of a report is not that big a deal – unless you are dealing with 23 of them a week. So – in essence, the problem and pain was mine, not theirs. Since I could not force them to make the change, I took a different route. I eliminated the work.

I simply took each of the 23 status reports and copied all the information into 23 new status reports under the new and consistent format. I then mailed these out asking that they start with these as the base. So far, everyone has been either accepting or thankful. I’ve gotten no resistance or complaints.

My lesson learned here is that by doing the initial change and creating a situation that is no more difficult for the person, we can speed change. Most of the time the hard part of changing is just that the change itself, after that we develop new routines that are usually less work than the original ones – that’s one reason for change – less work.

I learned a long time ago (the hard way) that there is only one thing any of us has the power to change – ourselves. By reframing my view (changing from the view of my predecessor) I changed and made it easier for others to do so. I think that whenever we find ourselves involved in helping someone else change, the first question should be “what can I do differently to make it easier for them to change?”

Often the answer will be that we have to do a little work that “is not our job” or falls outside of the box, but if PMOs are to be centers of change, shouldn’t we lead the way by changing ourselves rather than expecting it of others?

Week 25 (Building a PMO) - Lessons Learned? - Process

In project management, we generally group our processes under the heading of “methodology.” For some reason, I think methodology brings a more formal connotation than process. Either way you slice it, the way we do our work is what those of us in the profession are all about. The PMO is the corporate manifestation of the need to improve the way we work. So, what did we learn about how to work together on this particular project? I think five of the top 10 lessons were process related. The list and discussion follow.

1. We left management and planning unattended for too long.
Bet you never heard that one before! Without going into a rant, essentially we began the project with a boilerplate project schedule and methodology that was designed for small projects of this type. The schedule called for a 16 week step by step implementation. That went down the drain almost immediately and now 17 months later – TA DA! We go live. If you are going to plan – do it! Do it right, do it often, and don’t let convenience dictate how long you are going to plan. On my other project, we have a two-day planning session coming up this week. Guess how long we are going to plan? Not until we have a good plan, not until we have a shared understanding – two days – that is it for a 12 month multi-million dollar project the entire leadership team is getting together for exactly two days to plan! Boy, are we good! ---- ooops I’m ranting – suffice to say, my opinion is that planning may not always be perfect, but I’ve never been on a project where I didn’t see a lesson learned like the one above – and I’ve never even heard of a project where people said that they wish they hadn’t spent as much time planning.

2. We had the most success when we were all informed.
Communications! There is an interesting story here, and while it is not the only communication situation that helped us, it is one worth telling. Since about mid-December, the project has been hanging on by a thread with looming deadlines and a lot of nail-biting. We gave one of our weekly reports to the board, and someone suggested that we might benefit from a daily call – touch point, stand-up, type of thing. Well, that went over like you might expect – “I’m too busy to take time out every day for a call”, or “I know what I need to do” “That would just slow me down” and so on. We decided to adopt a method that I think I stole from scrum. First we scheduled the call for 15 minutes. During the call we went through the roster and each person said what they did yesterday, what they planned for today and any situation that might be keeping them from accomplishing their work. For the first week or two we had abysmal attendance, of about 15 invitees we were lucky to get 5. We persisted and elevated to the board asking that they “encourage” their team members to attend. That ultimately worked and for January and February we had great attendance. Some times the calls went long, some times we were less disciplined that we would have liked, but the #1 positive feedback I got for lessons learned was on how much the daily call helped. Almost every participant in the call mentioned it as one of the 3 things they would do again. It was really rewarding to see that popping up so often as I got the responses.

3. Once engaged and informed, management responded quickly and helpfully.
Yes, “once engaged and informed” are the key words here. We had a real problem being succinct and persistent about our needs. Of course without a schedule or a good understanding of the work, that was hard. However, every time we were able to say what we needed, for how long and when, we experienced great responsiveness. This then is the key. Don’t raise vague complaints – the team was working long hours and making little progress, but they were unable to clearly express the need. Once we sat down, thought about it and gave a clear definition - we needed an Access expert who had some product knowledge for about 3 – 4 weeks at least 50% of the time. The executives fell all over themselves getting the right person, and while it was a bit more than 4 weeks and quite a bit more than 50% of the time, everyone hung on and we got through it. Moral – know what you need before you ask.

4. We did things right, wrong, and mostly late
This is typical of every project. We made a lot of mistakes in how we approached the work, in how we solved some of the problems, but I think these were all exasperated by our lack of clear objectives. We did not have critical success factors or a good schedule initially, so we were not able to keep the project on target. Everyone had a sense that things were going bad, but we often waited or delayed either through optimism or ignorance. Then when it got really bad, it was too late to recover by any normal means and we had to call in the cavalry. Only long hours and additional people allowed us to pull though – the sign of bad planning and waiting too long to acknowledge (recognize?) a problem. There was a lot of good work late in the schedule that if done earlier would have been higher quality and easier on everyone.

5. A great customer relationship got us through many challenges
There are a lot of ways of looking at this. My favorite metaphor is the “open kimono” one. Doing business with full transparency in my book is the only way to go. That doesn’t mean giving up the company secrets, but it does mean keeping the customer informed and if at all possible making them a functioning part of the team. Too many managers try to censor the information that goes to the customer so that they are giving the customer a specific contrived view of the project. Everyone sees through this and it does little more than cause distrust. You may be able to control the information flow, but the customer will know that something is being held back. How they react to that differs among customers and people, but it is rarely a good reaction. In our case, we had weekly meetings and discussed any level of detail that the customer wanted. We discussed our process and schedule, and when we were late, we talked about that too. The customer knew that we has their best interests in mind and they trusted us – not blindly, but because we were open and honest. The customer team was exactly the same sharing their challenges – all this lead to better understanding. When we hit a rough spot we hit it together, and that is a partnership – no hype or glad-handing, mutual respect and trust.

There you go, only one left for next week – tools – maybe I’ll cover it now. We didn’t have the skills and tools needed. Make sure these are lined up and immediately available, or you will be left scrambling. My father in-law is a wonderful mechanic, electrician, plumber, you name it, and he ALWAYS has the right tools – and that makes all the difference. When you can’t seem to get things to work right, find an expert and ask – they will have the right tools – which reminds me that my new hand-built computer still refuses to power up – time to have granddaddy over to visit the grandkids and maybe take a look at my project :-)

Week 24 (Building a PMO) - Lessons Learned?

If I take the lessons learned from last week and look at them, I think we can logically divide them into 3 categories – People, Processes, and Tools. These are the building blocks of every organization or project. There is a lot of overlap in these lessons and some fall into all three categories, but the division works for my purposes here.

People: The people lessons were:

• The people we had were great; there just weren’t enough of them.
• Unclear roles and responsibilities led to confusion and loss of precious time.
• We were slowed by constant competition for resources.
• We did not have a clear understanding of the work when we estimated.
  

These issues paint a clear picture of our project and our main people-related challenges. We were consistently understaffed, competing for resources and often confused about who should do what. What is not mentioned here is that there were effectively 4 project managers for this one project and no one had full authority – so there’s the answer to the confusion problems.

As I look back, it is possible we did not get the people we needed due to political skill, combined with the lack of a single project manager. Let’s face it, obtaining needed resources within most organizations today has more to do with how good you are at asking than how much you need them. In our case, I think we might have allowed ourselves to be victims. When we did not have what we needed, we often rolled up our sleeves and gave it our best shot while half-heartedly asking for help. This tendency towards action meant that we tried first and then ended up pleading for people only after we had gone down the wrong road. Better to get the right people in the first place, or manage this as a risk with contingency and mitigation plans (longer timeframes, training classes).

The roles and responsibilities problems started from the beginning. The project initiated as if it was a typical, small installation project. These projects generally take 16 weeks; ours ended up at 17 months. This miss-categorization set unreasonable expectations and incorrect staffing. The roles assigned “project manager”, or “business analyst” have a completely different meaning for a 16 week boiler plate project than they do for a 17 month implementation. It took us a while to discover this, understand and adapt. Even as we end this, no one person speaks for the project, fortunately we all speak with one voice – more or less.

Lastly, competition for resources was a constant problem. Only one person was full time on the project up until about 3 months ago when the full-time staff doubled to two people! This excludes IT development staff who were often full time for short periods according to the development schedule. In most cases, we would get a statement of general support without specific date and effort commitments. Then, when needed the people were able to only dedicate a portion of their time, extending the deliverables. Fact is we did not account for that. Maybe that is more the problem than the unavailability. Seems we did not learn from this and plan accordingly. We didn’t do that. We didn’t because it was too hard to get everyone together and we were too busy “doing” the work to take time to plan it. OK – we knew that was wrong, but we accepted it as better than nothing. The error was that we did not add this as a risk and raise awareness to the “powers that be.” I’m starting to feel pretty stupid; I seem to have mistaken some progress for good progress. Isn’t any progress good? Isn’t there a quote that says something like: good is the enemy of great? I’m not feeling so great right now.

Week 23 (Building a PMO) - Lessons Learned?

Well, one of the major deliverables for one of our customers has arrived – we are going live on 3/1! As of this writing, it really looks like we will make it, and with quite a few reasons to be proud. We will be implementing a considerable part of what we planned, and in some cases, a little extra. Of course since we had no real success criteria, the idea of a successful implementation is not applicable. How can you succeed if you don’t know what success is? I’ll get to that another time… Today – lessons learned.

First, I am an advocate of learning lessons at all times during the project and recording them as they occur, something that I did with this one. My reasoning is that we tend to forget over time, so waiting until the end of the project may result in lost lessons. Also, after a project is completed, we all have a tendency to paint a slightly rosier than real picture of what happened. The aura of success (or even just getting the darn thing over with) can create a euphoria that makes things look - not so bad.

The reason I added the question mark to the title is reflective of my skepticism that we are actually learning here. I propose that a well-run project will have lessons learned that relate ONLY to the parts of the project that were new. The other parts, I expect we would have learned from already. Now, that is not to say that continuous improvement is not possible, but rather that the “lessons” from continuous improvement are a different order of magnitude than those from the newer parts of the project. That is – if you have been learning in the first place! I think we are learning a little, but not as well as we could. One of the jobs of a PMO is codify or ingrain these lessons into the culture and processes of the organization. This way we can collectively and consistently learn these lessons rather than learning them individually and unpredictably.

So here are some lessons learned form the most recent project in our current program – how many of these do you already know?

1. The people we had were great; there just weren’t enough of them.
2. We left management and planning unattended for too long.
3. Unclear roles and responsibilities led to confusion and loss of precious time.
4. We had the most success when we were all informed.
5. Once engaged and informed, management responded quickly and helpfully.
6. We did things right, wrong, and mostly late.
7. We were slowed by constant competition for resources.
8. A great customer relationship got us through many challenges
9. We often did not have the tools and skills needed to do the best job.
10. We did not have a clear understanding of the work when we estimated.

I am sure every one of you can relate to these lessons. These were not all the lessons, but these are the ones I think we already knew. Yet somehow we did not learn from them in the past. Why? I think I will break these down a little over the next few weeks and look at them – surely there is a reason, or reasons. Hmmmm.

Week 22 (Building a PMO) - POWER!!

Power – yes, power, it brings up all sorts of negative references – “Absolute power corrupts absolutely” being the most famous. Well power exists and it is used and misused every day, mostly misused or abused. I’ve recently been able to observe and better understand the workings of power. I’ve seen manipulation, abuse and absence. I want to talk about the absence of power as my current assignment has taught me a lot about that.

First, let me talk about the difference between power and influence. Influence is absolutely necessary and vital to everything we do. When you can use influence do so, use power only as a last resort. No matter what position you have, working jointly with someone and using your mutual respectful relationship to come to a decision is infinitely preferable to using power – EXCEPT – when you can’t agree, or there is not a relationship of mutual respect.

So therein lays the benefits (even necessity) of power. As hard as it is to believe, not every working relationship is one of mutual respect and cooperation – no news flash there! Now, I think the first job of all of us is to create that kind of relationship. Everyone benefits when these relationships exist, including the company and the stockholders. Therefore, it is inherent in your job as a manager to build and maintain these relationships and influence. But sometimes, things just have to get done. That is when power can be adeptly applied towards success. Where there is no power, there are problems.

Consultants have a unique perspective on power. We are ultimately powerless. Any perceived power is simply a very strong and widespread influence. Being the only expert in the room often gives the illusion of power but, as we have all seen, power trumps influence. Being powerless is a great motivator to learning about power – trust me on this one! One thing I am learning is that when power is not defined and understood by all, there is a level of chaos that is expensive and detrimental.

A project without ONE single project manager is a project at risk. The more project managers the more risk. This seems so obvious that you might wonder why I am saying this. Power and politics often create situations where there are multiple project managers. In my current assignment there are at least 3 projects managers on the two major projects. One could argue that there are as many as five on one of them. The organization started simply enough and the story goes something like this:

We have a project that will involve many different areas of the company – it’s important to all of us, so we want each area to assign one of their best people to the project (and part-time only, but that’s a later blog). Of course this usually means managers get assigned and usually some wrangling goes on where these people all end up being at the same organizational level (i.e. pay grade). So now we have 3 to 5 managers all with separate areas of control as the “appointed leaders” of their area. Here is where organizational culture comes in.

In most organizations territory is closely guarded, so each appointee has some mandate from their management to protect the interests of their group. There is also some tacit or actual agreement that each appointee will have “final say” or power over anything that impacts that area. See the problem? Makes you want to scream right. Believe it or not al this seems very logical from the point of view of those making these decisions. Well to my eyes, here is the 800 pound gorilla. THIS IS A PROJECT !!

This project must be impacting multiple organizations or we would not have involved them, so there will be many decisions that impact every organization involved and some of those will have to favor one over another. Since we now have a group of equals who are first dedicated to their organization, they will fight for the decision that is in their interest. This can lead to a plethora of wasteful activities. Imaging if these people are not working from a position of mutual respect and trust! That means a struggle at almost every decision – and projects have a lot of decisions!

One of the ideas of projects is to create something that is greater than the sum of its parts. With shared (and I use that term loosely) responsibility, each leader is looking out for their area and the picture of the project to them consists of “mine” and “not mine.” This creates several problems. Not everyone’s definitions of mine/not mine agree, so you have areas that several people feel they own (mine, mine); and those areas that no one owns (not mine, not mine). The only place where there is harmony is when something thinks they own something and everyone else considers that thing “not mine.”

Conflict arises when the views of the appointees do not agree. Obviously, if several of us think something is ours, a direct conflict over ownership and the power to decide ensues. If everyone thinks something is “not mine”, then we might all just drop it, or even better one of us might decide that that something is “yours” and YOU need to do something about it. Ah what fun that is! Try to get someone to work on something for which they have no sense of ownership! So begins the joyous practice of finger pointing and CYA that we all enjoy.

What a load of crap – all this because some people were more interested in having some power than in getting the work done for the company. Here a single, responsible person with power can save huge amounts of money and time and achieve success for everyone. Seems too many of us would rather lead in hell than be part of a winning team which I guess explains a lot of the working environments out there today.

I need to think of some way of creating a scenario or game that shows how ineffective this is … hmm.

Week 21 (Building a PMO) - Reporting part 2

So, last week I talked about Just in time reporting – getting the information to the right people while it’s “hot.” This week, I want to talk about getting the right information there. This can be tricky! There are some serious pitfalls. There are problems with giving useless information, presenting the information incorrectly, giving too much, too little and so on. Let’s start with the quantity of information.

You will rarely hear your stakeholders ask that you give them less information; because of this it is your job to start with a little as possible without giving so little as to be meaningless. Ha – that was easy to say! It has been my experience that every time I present information I get good comments about how the information can be used, and am asked if I could include “a breakdown by month”, or “a list of projects over $1million”, or…. This means that if you start with a lot, you will end up with too much information and the associated excess of work. So what is enough?

Let’s look at it this way; you are usually producing reports for some level of management. So what do they want to know? In my experience both as a provider and recipient of these reports, the primary questions are: How are my resources being spent (time, people, money)? Will we do what we said we would do? What can I do / what do you need of me? Although these are all closely linked, let me address them individually.

How are my resources being spent? Any project is an investment by your stakeholders and they want to know how their investment is doing. Did they spend the right amount? Are the resources the right ones? Will the investment pay off? In order to answer these questions, you will focus on the past and the present. These metrics or measures are often seen in dashboards. So some examples would be milestones, earned value, budget, time spent, adherence to schedule, utilization and other similar measures. The purpose here is to say – you (the stakeholder) have invested this (money, people, and time) in the project and we have created this (value, product, service).

Will we do what we said we would do? This relates to commitment and promises. Each project is a promise to meet a need or want of a stakeholder. Those who are receiving the end result of the project want assurances that they will get what they want. While those contributing to the project want assurances that their investments will produce the desired results. This information will focus more on the scope of the project than on the cost / time aspects. Measures here might be number of requirements met or forecasted to be met. Change control information, quality measures, achievements and deliverables demonstrate that the project will achieve what is expected.

Finally, management wants to understand what is needed of them. Everyone wants to contribute to the success of the project, but it is not always obvious how this can be done. Most of those reading your reports do not have intimate knowledge of the projects and do not know immediately what is needed. It is then your responsibility to simply ask for help as needed. Do not assume that any fool seeing this report would know to do such and such, simply ask for the help and explain what is needed and why. If you need more time, money, resources ask. If you are stalled because of a particular problem, call in the big guns. That is what they are there for.
Well, that’s all well and good, but what does a “just enough” report look like. Here is my criteria:

1. KEEP IT TO ONE PAGE LONG AND NO LONGER !!!!!!!! (I can not stress this enough) – if you can’t say it in one page then don’t expect anyone to listen and it is YOUR FAULT – management does not have time to read excruciating details about everything they are involved in or responsible for. That’s why they hired you! Give it to them short, accurate and ON ONE PAGE!!

2. Use illustrations and diagrams whenever possible. This is not because words and numbers are too complicated for pointy haired managers, it is because pictures communicate more information in less time and with greater accuracy. If you haven’t studied work by Edward Tufte then do so. The expression of information is vital in our work for so many reasons.

3. Answer the three questions above. If you don’t, you will be asked these questions every time. Take care of this up front.

4. Tell a story. Make your report more that a point in time snapshot, show the past and predict the future. Some models are good at this – EVA has a lot of potential. One that I use is to show simply actual expenses against budgeted. I use a graph with a line showing actual expenditures up to the current date with a colored in area showing past and future budgets. Bind the past, present and future together in a consistent flow that tells a story of your project(s).

5. Keep the format consistent – same things at the same place on the page every time. Do not make the recipients of the report search for the information every time.

6. KEEP IT TO ONE PAGE – oh – you get the idea – really if they want more they’ll ask. Trust me – you don’t get to Senior management by being shy – keep it to one page, everyone’s life will be better for it – and you will rise to the challenge of presenting just enough information just in time!

Marketing your PMO

Yes, Marketing your PMO. Good, bad or otherwise, this is one of the primary jobs of the PMO Director. If the leader of the PMO is not doing this, then who will be? You want your organization to grow in knowledge and capability and you want to share how Project Management can help your customers better achieve their goals. There is nothing that helps you communicate this more effectively than the practices of Marketing.

If you’re like me, you’ve seen that vague smile and zombie-like glaze that comes over your loved ones when you start talking excitedly about how you were able to streamline the change management process by reducing the number of steps, modifying the forms and blah blah blah.... – Now imagine if the people you were talking to didn’t love you?

There is a lot to learn in Marketing and I won’t pretend to be an expert, but let me suggest three simple steps - I think you will find these effective, I have.

First - Find out how you can give value to your customer through project management.
Second – Give them that value with no strings attached.
Third – Talk to them about how you were able to achieve what you did.

I can’t tell you what your customers will value, but they can. Talk to them and begin your marketing campaign.

Week 19 (Building a PMO)

Distributed v Centralized PMOs

Yeah, I’ve skipped a few weeks. My official excuse is that those were the holidays and not much was happening. Since you all know it’s because it was the holidays and I got lazy, let’s just pretend.

A comment I got a few weeks ago about staffing has had me thinking about PMO models. There are a lot, but the two extremes that come to mind are the highly-centralized versus the distributed. Let me just set my definitions of these two and then talk about where I see the problems and possible solutions.

Centralized PMO – this PMO would contain almost all the project management work, knowledge and oversight for a single group or organization. Within this department would be all the project managers, PM trainers, methodology and tool experts, mentors, and PM specialists. If you want project management, this is where you come.

Distributed PMO – in this model, the PMO is very small and probably contains no more than a few people who have primary responsibility for the tools, methodology and maybe reporting. The PMs and specialists are distributed in the teams, and PM training would be part of corporate training.

There are a lot of advantages and disadvantages to these models. I still hold that the centralized model is more effective to the larger organization overall, but that is not the point of this post. What I have been thinking about is how to use the best of these models in a more effective manner, so here are my thoughts on a hybrid model.

First we start with the model of a centralized PMO, but we limit the involvement of PMs from this area to only certain types of projects (strategic, cross-department, high profile…). Or – and I think this is one of the key benefits of a centralized PMO – these PMs would be available to help departments that do not have their own PM. All other projects are handled at different levels of the organization by “imbedded” PMs. This removes some of the staffing and inequality issues related to a central model.

Next we need to address the tendency of distributed models to move toward entropy with the PMO becoming ineffective methodology police. I have a real personal bias towards this, because I did not get into this career to run around telling others that they needed to run a phase-gate review using forms 21 – 36 before they could go on with their project. I believe that this creates an atmosphere of compliance and that is not what we are about.

So, how to move from compliance to integration where all PMs regardless of location use the same practices and procedures because they are the right ones, not because they are the only ones? I don’t have a full answer, but I think there are several steps in the right direction.

1. Project Manager Rotation. This can be pretty tricky, but I think we should look at having this as part of a PM’s career path. The project manager would serve a certain period of time in the PMO (as a mentor, trainer, strategic PM, portfolio manager…) and another period as an imbedded PM. In fact moving from group to group would also work well. With the addition of timeframes such as no less than 6 months and no more than 2 years, we can keep up the circulation without constantly upsetting workflow.

Cross pollination of team members will create a group of project managers who have worked in multiple areas of the company. They have shared their knowledge, and learned about the business. This is consistent with the value of integrating project management within the organization. This also creates a cadre of professionals who have a wide understanding of the business and of management – not bad for any organization.

2. A simple, flexible methodology. I know I harp on this a lot, but complicated methodologies are difficult to sustain, manage and follow. The truly useful and efficient methodology will be very simple, flexible and will not change often. Maybe methodology is the wrong term, maybe better a set of guidelines, practices, values and a framework. Trying to integrate a methodology with hundreds of forms and process steps is irrational in almost all cases.

Some other ideas come to mind, more on those later. I have to go move a refrigerator.

Week 15 (Building a Program Management Office)

Week 15 – The price of Trust

Pretty amazing thought, but I’ve been noticing just how valuable trust is and how expensive distrust is.

Think about how much easier it is to work and interact with those you trust versus those whom you either distrust or who you just don’t trust as much. I think in the working environment, this can be greatly influenced by the management team. I was fortunate to work in a company where trust was an integral part of the culture and in others where CYA was the norm. I got a lot more work done in the former than the latter.

Trust impacts a lot of areas of your work life. The biggest and most obvious I think is communication. There is a completely different level of communication with those you trust and those you do not trust. Communication with those you trust is often less formal and overall richer in content. You are more likely to have a face to face with those you trust (you probably like them more). Face to face is the richest form of communication; you convey much more than just the words. You can communicate greater range of meaning and emotion.

On the other hand, those you do not trust are more likely than not to get an email. Probably one that has a few cc’s – just in case. The email is likely to be very factual and directive – “I need such and such by Tuesday.” You’re unlikely to convey emotions (emoticons not withstanding) or any richer channels – you probably even avoid verbal communications.

OK, yes I am talking about myself as well. I find that distrust leads to more distrust and avoidance and thus non-communication and ultimately ineffectiveness which hurts everyone and your project. Therefore, I conclude that it is counter-productive to distrust someone – regardless of their prior behavior. So, I can’t remember who said it, but the motto goes “trust, but verify.”

I’m going to work on adopting that. It is unprofessional for me not to verify and ensure that what is committed is done, but at the same time it is unprofessional (and unproductive) for me to go on the assumption that it will not be done, or not done well. I think I will save a lot of time and heartache personally.

Let me suggest then that trust is not earned it is given, and that we should give it freely and constantly to those we work with. Yes, just like Charlie Brown always going for the field goal with Lucy holding the ball. If you are in an un-trusting work relationship, it is time to take the first step – just like I will on Monday.

PMO Staffing (short)

Many PMOs today are made up of teams of professional, dedicated Project Managers who are assigned to projects throughout their organizations. One job of the PMO is to put the right PM with the right project at the right time. Because of the nature of projects, this can be VERY tricky. Even the best resource management can be inadequate when a project gets into trouble, or when several projects get behind schedule.

Staffing is also prime target of politics. Without a project prioritization system, the assignment of project managers can (and often will) be viewed as arbitrary, unfair, or biased. One way to counter this perception is to be scrupulously independent in everything you do. It will not help all the time, but being know as fair and unbiased in the little things will serve you well when it comes time for the big decisions.

Another staffing political pitfall is more subtle. In these situations, one group starts requesting a specific PM. If Joe did well for Accounting in the last project, then they will probably be asking for Joe again. They will hit you with pleas like “he already knows everyone here”, or “he’s familiar with the way we work”, and more. It sounds immanently logical and that’s the trap. Going down this path will turn Joe into “the Accounting PM.” And if Accounting has their very own PM why can’t everyone else? And why isn’t Accounting paying for him? And finally, why doesn’t he just report to accounting and we’ll get rid of the PMO?

So be careful how you staff your projects and keep the long view in mind – someone has to.

What's a PMO (short)

I’m sure that many of you have been asked this question and even pondered it yourself. If you are lucky enough to be building or managing a PMO, you’ve probably been struggling with the wealth of information and definitions that are available. Every PM pundit has their “anatomy of PMO” or ten essential components of a PMO. Well, you can relax; I’m not going to add another myopic pronouncement to the mix.

Instead, I’m going to suggest that this is the wrong question. The question is not “What is a PMO” but rather “What is YOUR PMO.” While PMOs certainly share common characteristics, those characteristics describe a PMO and do not define it. The only definition that matters is the one you and your stakeholders have created.

Your PMO will serve the needs of your community, your company, your management. Your PMO will be unique and effective within your environment and not a manifestation of some theoretical model out of a textbook. Next time someone asks “What’s a PMO” – tell them about YOUR PMO.

Week 7 (Building a Program Management Office)

Week 7

In spite of everything, we went into the meeting to present the requirements and it was a disaster. Everyone had a different agenda and opinion about the requirements. We discussed AGAIN things that I swore we had resolved. The program managers and I got together and did a quick lessons learned on the whole thing. We discovered what is probably obvious.

The meeting with everyone face-to-face was a great idea and worked well. Other things that we did well were to keep a single list of the requirements and work from that whenever we got together. The consensus was that the communication was good as well, and that everyone on the team was kept up to date on what we were doing and what was decided. And that is it for the good news.

On the lesson side many of the mistakes were mine. Communication to the board was not good or clear, and the board was well behind what the team was doing and needed to be brought up to date before we could give them the current status. I did not keep track of this and start from the last time we talked with the board and moved them to the decisions the team made.

The team did not have consensus going into the meeting and the communication was ad-hoc. We needed to clearly agree on who would talk about which requirements and what each of them would say – hopefully what we all agreed on! If we added an agenda (yes I did not put out an agenda – I could kick myself) with the appropriate information, then it would have been smoother.

I think my take from the whole thing is that I need to be much more formal and complete with any communications to the board. I hope the next one works, I’ve spent some time putting together a presentation for the next meeting – Tuesday’s monthly meeting. As I was doing that I realized we needed a lot better information about our projects. We really don’t have any metrics at all. We do use the red/yellow/green, but it is not as objectively determined as I would like so building metrics is my big goal over the next month.

What I am thinking is keeping it simple with schedule, compliance and goals. We do not really have good project goals. I mean basically we have the “get the job done” goal, but no real way to tell if we are making good progress towards the goal. We can tell that we are working hard, but not that it is on the most important things. I’m going to interview the board to get their goals, aggregate them and set up some criteria that we can check against.

Schedule will be kept simple – on schedule, off, etc. The problem here is that we do not have good schedules. That is what I’m working with the teams on during week 8. I expect that we will have something with milestones, deliverables, and good dates. I’m sure this will help everyone at least have a better picture. I am learning that project schedules are a lot more fiction than reality, but we are going to work on that.

Lastly I’m going to use compliance as a metric. The first metric will be the weekly reports then probably keeping the schedule up to date. Don’t know what else, but I’ll think on this. I normally hate these metrics since they look like tattle-tailing, but I think this is one of the only ways we are going to get the teams to do the work needed to produce the information for metrics. We’ll see wont we?

Soldiers

Sorry for being out, between contracts, vacation and my laptop being in the shop, things got a little hectic. I want to continue with the discussion of heroes and soldiers. I think we all agree we would like to have a hero around when we need one, but that a team of heroes can be a little – shall we say “sub-optimal.” On the other hand, a team of soldiers can really accomplish anything.

Soldiers

When I refer to soldiers, I am not talking about clones or mindless robots that follow orders to the letter and sacrifice themselves in droves at the whim of their commanders. No, the soldier I am talking about is the professional soldier. Think Roman Legionary or any of today’s highly trained military. With proper management, diversity and organization, a Project Management Office built with good soldiers will be very effective in changing and sustaining a culture of project management. That said, our soldier type has some characteristics that we want to be aware of.

• Soldiers are disciplined: This is one of the main differences between a soldier and a hero. A soldier can be expected to show restraint, paint within the lines and to follow company policies and norms. While a hero will often play “bull in a china shop”, your soldier is unlikely to leave a trail of broken dishes or irate coworkers.
  Soldiers are team players: Soldiers work well in units. There is a real synergy when a team of soldiers gets together to tackle a problem. Here is where you will really see the power of teamwork.
• Soldiers are Professional: Soldiers understand the company dress code. They understand and abide by corporate behavior norms. Soldiers approach their work as a craftsman would, seeking to do the best they can and with an effective combination of enthusiasm and thought.
• Soldiers are reliable: This probably sounds a little boring, but as a director, you understand the need for reliability. Soldiers help you provide a consistent level of quality in all things. When you send one to a customer site, you know how they will behave, you know they will not say or do anything outrageous, you know they will represent the Project Management Office faithfully. This is vital to creating a trustworthy image and perception of your PMO.
• Soldiers often Specialize: Many of your team will have an area that they are particularly good at. You may have a methodologist, or a trainer, or a mentor, each of us has different gifts and hopefully you will help your team develop those to everyone’s benefit. A specialized soldier working in their realm is about as good as anyone ever gets. This person is “in the zone.”
• Soldiers can be slow: As a rule, your soldiers will usually take a little more time to complete the work, or to address the problem than a hero would. If speed is your only criteria, calling up your soldier may not be the best option. Of course this is not true of all soldiers or all situations. A specialized soldier in her discipline can be as fast as or faster than any hero. Get the soldier out of their specialty, and things slow down a bit.
• Soldiers can be rigid: I am sure you have run into this. The team member knows how to do something, and does it just that way or they look at every problem the same way. To a hammer, everything looks like a nail right? This can be a real drawback when you are trying to institute widespread change. Inflexibility in your team does not set a good precedent or example for others to follow.
• Soldiers can be unimaginative: This goes hand in hand with rigid in some ways. Often soldiers are so good at working within the norms that they cannot see outside them. This gives a limited point of view with limited options. Many times these team members will talk about things in terms of “Right” and “Wrong” – with caps. Once that mind frame is set, it can be very difficult to break out to new ways of looking at things.

The Soldier Culture
In a corporation that has gone too far into the soldier culture tends to be very rigid and is all about following orders and procedures. These are by the book types of cultures to whom rules are paramount. As an example, I recently attended a convention for which I pre-registered. I went to the line to get my materials, and right next to me was someone handing out lanyards – I know I have millions of them, but she was handing out ones that had the convention name on them and all the packet had was the typical string ones. I asked her for one of the lanyards; she asked to see my badge; I showed it to her and she replied that the lanyards were only for the people who were registering onsite. I of course said – “you’re kidding right, it’s just a lanyard.” To which this obedient unimaginative soldier answered “no.” Mindy you she must have been holding 100 of these things. Her customer service ethic alone was abominable. But think from her perspective – she was told that she was to hand out lanyards to the people who registered for the convention on site. I didn’t so I did not get a lanyard. This is the kind of thinking that can pervade the typical soldier culture.
In these soldier cultures, the Project Management Office often becomes little more than forms police or methodology Nazis. While this may be comfortable for some, count me out. So what works?

The Warrior Culture
What is too frequent today is a conflict between the heroes and the soldiers. Soldiers call the heroes “loose cannons” or “cowboys” and heroes call the soldiers “pencil necks” or “suits.” They both see their way as the “right” way, so someone not working the “right” way is “wrong.” This fundamental assumption is the problem. I have a button that says “I’m right and you disagree so you must be wrong.” When this happens, any movement away from “right” is seen as compromise or worse. Guess what, there are a LOT of ways to do things. If there was a right way to build a car, there would be only one type of car, or house, or city, or family…. Take a look around, nature has the idea – diversity, synergy, cooperation.
The best (not right) organizations will have a good combination of heroes and soldiers along with the associated mindsets. You can have heroes that follow rules or soldiers that act independently in unfamiliar situations. Let’s call this the Warrior culture. The Warrior team is capable of organizing and attacking situations with the flexibility of heroes and the discipline of soldiers. Now that is where I want to work – challenge and stability, known and unknown, chaos and order.

Marketing Your PMO - Positioning Project Management

First a comment on some articles in the June 1, 2006 issue of CIO Magazine. The cover story “When Failure is Not an Option” is about how AG Edwards is making huge strides by improving their Project Management capabilities. Great stuff there for you, both in terms of practical advice on the how of getting this done. Too many people focus on the “what.” Also, showing your management that AgEdwards is doing this might give you some more ammunition in advancing PM in your organization. In the second article Sari Kalin talks about Portfolio Management. The article is short, easy to read and gives some excellent practical advice and spotlights Eastman Kodak’s work in Portfolio Management. This one is great for printing, circle a few key points and drop it off on your boss’ desk with a “thought you might be interested” comment.

With that as segue; I want to talk a little about the shameless promotion of the PMO and Project Management. Personally, I am not very good at this, but this is an essential part of your job as director. You are trying to institute a change in your company and the name of that change is Project Management. Even if you have a fairly fertile environment and a high maturity level, you still have to get out there and talk it up.

How many of you just said “yech?” Believe me I understand; Project Management is a good thing, that’s obvious right. All we should have to do is demonstrate success and everyone will see and want to implement Project Management immediately. As we internet geeks say – ROFL. For the most part, people will attribute your success to you, luck or some other factor. This is not to say that they do not appreciate it or harbor any ill-will to you.

We have been taught from the beginning that success is achieved through hard work, skill, perseverance and sometimes luck. When is the last time someone thanked a process for their success? OK, except for those infomercials that show you how to make millions in real-estate or surfing the internet. In our minds, success is a personal thing; even group successes are achieved through the personal contributions of the team members. We’ve grown up with great personal examples of success - heroes. This is another reason why the Hero Culture (see my July 3rd entry) is so prevalent. Admittedly, it’s not a bad thing for you to be associated with success, what you want to do is leverage the success to show people how Project Management can help them achieve success as well.

What you’re up against

Here is an example of the mental barriers you will face. Take a look at how computers are used. Today it is generally recognized that most workers can and do benefit from the use of computers. In particular, office workers get more work done with higher accuracy and in less time. (Of course we are now expected to do twice as much work in half the time). When mainframe computers and later personal computers came on the scene, they were widely resisted. There were still plenty of people doing their spreadsheets with calculators and typing memos on typewriters. Computers did not achieve success, they enable success. They were a lever that enabled people to do more, better, faster. Project Management is the same thing.

Position Project Management as an Enabler

When you talk about the successful completion of projects, spread the credit wide and excessively to every person involved. With this praise throw in phrases like “our PM processes enabled the team to identify and resolve issues before they became critical.” or “PM helped team members focus their efforts on the critical features that we delivered on-time on-budget.” And so on. If you can get any quotes from people – get them and publish them. Don’t force anything, you do not want false testimonials, you want something that the team members will repeat in 6 months without you around. The message here is that success does come from hard work AND Project Management gives you an advantage.

Position Project Management as a Tool

This is kind of an enabler too, but you will want to use the work tool, or toolkit. This model may work better for some people than the less tangible enabler model. In this case, you would rephrase the quotes above to something like: “Team members used the Critical Items log to ensure that they delivered the greatest value.” Not a great one, but you get the idea. An analogy here that I’ve use a lot is that you can hammer in a nail with a rock, a hammer, or a nail gun. We are tool users who are always seeking better tools, when you position PM as a tool, your message will resonate well.

Position Project Management as a Time-Saver

Personally, I like to position PM as a time-saver. My thought is that when you do a project, you will do the PM process one way or another. You will have to know what your issues are, you will have to know due dates, costs, resources, etc. You can either spend your time creating a method with each project, or you can use one that is proven to work, and change it as needed to meet your needs. So the quotes here are “the team saved significant time by prioritizing tasks using the Critical Items Log.”

Ultimately, you want to look for every opportunity to promote PM, but to promote different aspects and capabilities. You know your culture and the people you work with, some approaches will resonate, others will not. Part of your job will be to find this out and change your message to be meaningful. Don’t think that this ever ends, you will want to keep trying new avenues of communication and messages as things will constantly change and you will need to adapt – but you knew that!

Cargo Cult Project Management

Maybe you have experienced this phenomenon. You are at a company and they have a PM methodology, they are using the forms, there may even be people with Project Manager titles, but the benefits and results that come from project management are not there. I suggest that organizations like this are suffering from “Cargo Cult Project Management.” I doubt I can trademark that, so feel free to use it as your own. Let me indulge in a little history for those who may not be familiar with the term.

During World War II the Allied forces occupied many of the Pacific islands. Up until that point, many of the inhabitants of these islands had never seen manufactured goods. With the military occupation, things like clothing, food, weapons and other manufactured goods were delivered in plentiful quantities. These supplies arrived in airplanes. To the islanders who were unfamiliar with manufacturing or powered flight, the arrival of the good from airplanes seemed to be a direct delivery from the gods. After the war, the airplanes and their cargo, no longer came. In an attempt to get the planes to return islanders made airplanes out of wood, radio sets out of bamboo, and even painted military symbols on their bodies. They talked on the radios, waved flags, and lit up the runways at night, all to no avail.

This is not unlike what happens at some companies today. We use project charters, create Project Manager job titles, and produce a methodology but nothing really happens. We don’t get all those great project management benefits. Some PMO Directors have told me that they are not allowed to call their organization “the PMO.” This is invariably due to an unsuccessful attempt at a PMO which left everyone bitter and disillusioned. I can certainly sympathize with those feelings. Imagine how the natives that spent all day waving palm leaf flags felt when they finally realized that no cargo was coming. Just like these natives, executives and management have been asked to do a lot of work for little or no result.

How did this happen? More importantly, what can be done? In my opinion, this happens for two primary reasons. First, too much emphasis is placed on the trappings and appearance of project management. Secondly, someone tried to implement project management in the wrong order. Let’s look at the second reason first.

You can read earlier articles where I talked about the need to build your PMO through People, Processes, and Tool and in that order. In the case of a cargo cult PMO, someone has started with the tools. Not necessarily a purchased software product, although that is common, but the forms, the meetings, the language and other end products of Project Management. Just like the natives, we started with all the right tools, and got no result. The reason the natives did not get cargo is because there was no infrastructure, no industry, trade or machinery to create the cargo. Similarly, a PM tool without the underlying support of the right people and the right processes will fail.

Next there is this (IMHO) unhealthy focus on the physical aspects of project management, the forms, tools, reports. These are not project management. If you’re reading this, you probably already know that, but some PMOs have gotten a bad name because they tried to start there. This is a huge temptation and absolutely understandable. Your management is demanding that you show results so by creating a methodology or by implementing a tool you can show that something has actually happened. Something did happen and it may look like project management, it may even feel like project management, but it’s no more project management than a coconut headset is a radio.

Now, I am not saying that you can’t succeed if you start off with tools and methodologies. Some companies (the very rare ones) may already have a fertile environment for this. I’ll bet that if you looked carefully at these companies you would find that they already had the right people and processes in place; they just probably were not calling it Project Management. Unfortunately, most places are not like that. So what do you do if you are stuck in this kind of situation?

I think the first step is to assess what is going on. Resist the impulse to act, you probably represent the last chance project management will have at your company for the foreseeable future. If you fail, then you and project management are out the door. After you have an understanding of what is going on, cut, cut and cut some more. Get rid of every one of the forms or tools or processes that is not creating significant and measurable value. You can figure out what these are by observation. If everyone enters 8 hours for a project every day, then your time system is not being used correctly – can it. At this point you are not trying to fix anything - that will come later. Just clean house.

What you will be left with are the people, processes and tools that are producing and valuable. Start here by enhancing and consolidating. Improve what is working. Bring everything into a consistent whole. Call this your methodology if you want, but please do not confine project management to a series of steps to be taken. If you confine PM then so will everyone else. Things get more complicated from here and I’ve already written on several of these topics, so I’ll stop here. The idea is to stop doing the things that do not work and start doing the things that will.

Marketing Your PMO – Metrics (cont.)

Cost:
The BIG one! This metric is probably something you are already tracking. I’m sure you have been asked “what is the PMO buying me?” or “Is the PMO worth it?” or other such frightening inquiries. There are a lot of drivers for cost. Certainly, the desire to get the most out of every dollar is the underlying driver, but this does have some different flavors such as:
Resource Efficiency – how much productivity am I getting out of my staff? This can take a lot of forms – time on projects, time on maintenance, burdened cost, overhead…

Faster Project Completion – of course, the sooner they get done, the sooner we can start raking in the benefits and the more projects we can do overall, a big benefit of the PMO!

Reduction of Redundancy – here is a portfolio savings that PMOs bring. If you can eliminate a $1millon project because it represents duplicate work, then your PMO just saved the company $1million – almost enough to pay your salary. OK, the PMO does not deserve all the credit for the savings, but there is certainly a real justification that without your PMO, the company might have gone down the wrong path – or the same path twice.

Costs of Defects - Many of you are familiar with the formulas that show how much it costs to fix a problem or make a change in design versus how much it costs when you get to production. Improved product quality is a real benefit of Project Management. If you can measure and reduce the cost of changes and defects, then you are saving the company money or reducing cost.

Effective Forecasting - While this may not be considered a cost metric, it is certainly financial, and it does impact costs when a company does not have an effective cost forecasting model. How many times have you had to stop buying office supplies in November or December just to make budget? Your PMO can help management effectively forecast costs over longer periods which will lessen headaches and ultimately saves money.

PMO ROI – can’t forget this one. Your PMO will be seen by many as a cost vortex. If you’re going, you may be perceived as a black hole where the company has all these high paid people who do nothing. You will be fighting this constantly. You should really plan to continuously combat this perception via good marketing. Don’t think for a minute that you can establish that the PMO is worth it and then relax. You can never relax (OK – maybe never is the wrong word, but if there is someone out there who is relaxed about this, please write).

Because of the last bullet (PMO ROI), you will want to mirror your cost information with any savings or profits that resulted from your work. Whenever possible, report costs and benefits together. If you’re doing a balanced scorecard, or consolidated PMO status report, that is a great way of showing the whole picture. So where do you get all this lovely information and how do you report it?

A good mental model for cost metrics is earned value. Think “what value did I create for the money spent.” You may even want some form of CPI for you PMO; you could chart your CPI over time showing the return on investment. If you can couple that with a visual on the cumulative savings, even better. Something that looks like this might be very effective.

Here the ever-rising Blue line shows the cumulative savings over time while the pink line shows the CPI for your PMO. I have to stop here and make a recommendation about reporting in general. I have been very influenced by the work of Edward Tufte, his analysis of design and presentation are (IMHO) unsurpassed. The most important thing I have learned is that the presentation of information can be as vital to the message as the information itself. Before you start putting together management reports, I highly recommend that you look at his work. He has several great books, and he also has seminars. I went to a one-day one and it was worth every moment. Back to cost.

If you have information about what things cost before your PMO, then you will want to use that as much as possible. You can use these prior numbers for a while (months to a year) until you have established a trend and collected good post-PMO information. Once you have enough data on that, you can start comparing how you did last period to how you are doing this period, showing progress always. This really holds true for any of the metrics we’re discussing.

If you always measure cost as a factor of benefits, then we can present both sides of the equation. If you were to present just costs, then a document showing PMO costs would exist separate from a document showing PMO benefits. This document can then be used to argue that the PMO is costing the company money. Without the other side of the equation, you risk perception problems. Some ways of presenting costs and benefits are:

• PMO costs v. Project Benefits. Take the benefits portion of every project run by the PMO and compare that to your costs. Granted this is not a real return on investment, since a lot more went into producing those benefits than just your project management.
  
• PMO costs v. Project Management Savings. If you can, compare the costs of pre-PMO projects to that of post-PMO projects. Since you are now more efficient, you will be able to show how you are saving money. You can also show improved throughput with the same resources or even less people doing more.
  
• Project Hours v. Maintenance Hours. What you want to document here is that we are now spending more time on projects and less time on maintenance. This is probably going to be hard to get in the beginning, but as your projects go in and create better products, your ratio will improve. There is a general perception that time spent on projects is better than time spent keeping the lights on, so demonstrating an improvement in this area will be good.
  
  I think I overstayed my welcome on this one, so I’ll stop here. I will start trying to present more visual information and links as I continue. I’ve been pretty lax in that area and want to share some of the great sources out there.
  
  
  

Building Your PMO – People, Process, Tools – Part I – People (cont.)

Assuming you now have the list of qualifications, skills and characteristics of the type of person you want for your PMO. The only problem is that you don’t know how to find these people. How do you get the right person and not be fooled in the interview? Not only that, maybe you have 3 openings, but what mix is right for you and your PMO. We’ll save organization for later, for now a little about how to pick make sure you get the right people. There are a lot of tactics and a ton of good information is available, make use of it! As a general overview, these are some of my thoughts, as always if you have any ideas, post them for others to read.

Use Your Network: You probably know some good people already if you are part of any professional organizations or have kept in touch with friends and colleagues. Even if they aren’t the right people, they probably know someone who knows someone. Your network is probably the best place to find someone. Your friends would not recommend someone unqualified (well, let’s hope not), and you have a great chance of finding a “diamond in the rough”- someone who is better than their resume. There are a lot of good PMs out there looking for the chance to be part of your PMO. I have to recommend Ask the Headhunter, I have subscribed to Nick’s newsletter for about 6 years, and even when not looking for people or a job, the advice has been priceless. The newsletter and column focus on the job seeker more than the employer, but there are some priceless words of wisdom for anyone. The site is a gold mine of advice, you will not regret it! So stealing a key point from ATH:

Get Them to Do the Job: This is tough; in the past we have done simulations which are fun for all by the way. You can give the candidate a problem to solve, but my absolute favorite was “the project meeting.” One of the PMs in our group had a really harrowing meeting where just about everything happened, and he was quite challenged in just getting through the session – which he did. Anyway, we used this meeting as a simulation. Before the interview (after a phone interview usually) we arranged for the candidate to come onsite for some face-to-face talks. We would send the candidate some project documentation telling them about the history of the project, their role as the project manager, and other details about the meeting and the project status. Then, when they came in for interviews, we scheduled a meeting where the PMO members played the part of the project team and the candidate was the PM. We each had a role to play, one of us came late, one was constantly checking his PDA, one was constantly trying to bring up their issue and hijack the meeting, and so on. The really good thing is we have all been in exactly that kind of meeting. Frankly, most candidates were a little lost, but you could tell who knew what they were doing and who didn’t. Also, those who did their “homework” were obvious, as were those who didn’t. If nothing else, this tells you who is serious about the job and Project Management.

Constantly Recruit: One of the most frustrating experiences is to finally get that personnel increase approved only to have it pulled after you are almost ready to make an offer. So what I’ve found to work is to be constantly on the lookout for great people, and to be recruiting all the time. This way you will have a short list of people to choose from and can make the “official” part of the process as short as possible. I do not want to sound like an HR basher, but I have found that HR is generally not interested in you getting the best candidate; they are more concerned with legal and procedural risks and issues. Your objective would be to make the internal part of the hiring process as short as possible. This means you have to do a LOT of prescreening, you might even want to “interview” people from around town by inviting them to lunch and sharing ideas and experiences. Heck, maybe you will want to work with him or her. Another constant recruiting method is to get out there in professional organizations, so your network helps here too.

“Trust your Feelings”: Use the force. If you do not like something about someone – listen to those feelings. Don’t throw someone out solely because of what you feel, but find out why you feel uncomfortable. One good way is to talk it through with someone else. We try to do interviews with two interviewers. While one is talking / listening, the other can observe the interaction. Maybe the person with you saw something – you pulled back when the candidate asked about overtime and vacation. This way when the two interviewers talk immediately after the interview, you can share impressions and probably find the reason for any uneasy feelings. I’ve found that there is almost always a reason I feel uncomfortable about someone, and if I talk with someone, we can usually figure it out. Once you have a tangible reason, you can make a better decision.

OK – four again. Next time I’ll talk a little (maybe a lot) about organization – how to organize the crack team you’ve put together!