All about Project Management Offices

The Agile PMO

2009-05-03T09:31:00.000-07:00

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

2009-03-07T07:51:00.000-08:00

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"

2009-02-15T13:02:00.001-08:00

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

2009-01-03T17:37:00.001-08:00

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

2009-01-01T15:33:00.000-08:00

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

2008-12-31T08:42:00.000-08:00

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

2008-08-30T08:10:00.001-07:00

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.

An Interesting week ahead

2007-11-24T08:43:00.000-08:00

Next week looks to be very interesting. I've not written much in the last month because I really haven't done much PMO work. I've been writing Plan documents, so you can imagine how much I want to come home and write more. One of the reasons I'm falling behind on the Accord project - more on that later.

So, next week we are going to begin our installation of Project Server 2007. We have some consultants coming in to help us with the setup and some training. I've got a little experience, but not enough to want to jump off that ledge alone. I have been reading up - bought a book and pulled some papers down from the MS site. We have been slowly building a schedule (I use that term loosely).

Our schedule (which everyone calls a plan of course) is running about 2000 lines right now. Probably somewhere on the order of 250 resources. I know that's too big, so we have to figure out how to manage at the level of detail we must (per the contract no tasks >80 hours) and still be able to give some meaningful management information. We have a couple of really interesting challenges ahead:

Size/complexity of the project: This really just a technical challenge, but one that will be with us throughout the entire project. The solution right now for this is a full time scheduler.

Politics: I am not really sure that everyone has bought in to the 80 hours deal, so there may be some work there trying to get the right informaiton into the schedule.

Earned Value: Another contract promise - yikes! MSProject has a the tools, it's collecting the information that is going to be a challenge. Right now, I'm struggling to figure out "value." Is it the value assigned by the client or the value assigned by the contractor? We have a fixed price contract so to the contractor value = bid - cost (or profit). If it costs more to produce something that was bid, that's a problem. But the client has a whole different value proposition based on rate of return, net present value, payback, etc.

Scope: This is tied with the politics too - what isn't. How much of MS Project Server do we want to implement - it's a pretty robust tool - what's enough and what is too much. I'm a minimalist and so is my counterpart, so I think we will go with as little as possible. I just hope that is enough.

Off to read more, check a few blogs, etc.

Hired Guns and the Aspirin Solution

2007-10-10T17:38:00.000-07:00

A great PMO can not be built from a template. Each PMO is a project. There are many different techniques that can be used. As the PMO manager, you are the cook, architect, conductor for this unique entity. Pick what is best for you. Introduce at the pace that is best for your company.

Many PMO stories begin with some high level executive deciding that a PMO is needed (there are TONs of triggers for this). The exec then selects some poor volunteer from the company and calls in a hired gun - a PROFESSIONAL (read consultant) who knows project management!

The Professional rides into town (cue spaghetti Western music). He has years of experience, comprehensive experience and a goal to make the guy who writes the checks happy. The goal is NOT to create a PMO directly, but to make the pain that the executive is feeling go away. Or at least make it look like it is - this is the "aspirin" solution.

So our hero comes in, interviews executives, holds meetings and Viola out comes a 200 slide PowerPoint that solves everything. Along with this PowerPoint comes a set of manuals that Arnold Schwarzenegger couldn't lift on his best day. The PowerPoint and the manuals are thinly customized versions of the same deck and documentation given to every other customer who needed a PMO.

I know that sounds cynical - but I’ve heard this story too many times. Many times you, the PMO manager, are then left carrying the ball (or hauling the methodology as the case may be). With one small adjustment, you can change this from an unpleasant situation where you are cleaning up the mess to a great starting or changing your PMO. The change is fairly simple.

Take control of the implementation. It’s that simple, really. Now, that also means that you need to be very involved in the study and work closely with the consultant. Make sure that there is an implementation plan. Interview the stakeholders and understand their problems. Prioritize these problems. Put the problems into the implementation schedule and plan to knock them out.

Take the voluminous documentation and keep the only copy. Through each step in implementation search the documentation and mine it for the few diamond(s) that will be useful. Find a process and rip it down to its essentials – then strip it more and find that one gem. Polish and cut that gem so it is perfect for you and your company and then implement.

2 New projects

2007-10-03T10:36:00.000-07:00

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

2007-08-15T09:38:00.001-07:00

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.

Band-Aids and Merry-go-rounds

2007-03-29T15:54:00.001-07:00

As I child I had a lot of experience with both of these. I assume everyone is familiar with band-aids, the merry-go-round I’m referring to is the kind you find on a playground. These are basically a large dish parallel to the ground mounted on a central axis with some handle bars to hold on to - here is a picture of one. Aside from a trip down memory lane, what do these two things have to do with managing a PMO or even project management or even work?

I’m glad you asked – both of these items and their lessons from childhood give us insight into change. First, I want to look at each type of change and then talk about which is better (or not)?

Band-Aids
Band-aids are good at covering up and protecting a cut, but that is not where I want to go with that, nor am I alluding to a band-aid fix for something. The change I want to discuss is the change that happens when the band-aid comes off.

I don’t know about you, but sometimes I dreaded having the band-aid off more that the cut. If you are a guy with a lot of hair – it is even worse! Now there are many techniques for removing a band-aid. You could soak them in water, wait until they fell off, or go for the slow excruciating teeth gritting pull. However, as mom always told us, the best way is the quick pull or yank. One short burst of pain, a heartfelt OUCH and it’s all over – we have changed from with a band-aid to without a band-aid and we can run off to play and get more cuts.

This is a type of change – more formally we often call this a revolutionary change. We move from one state to another with a lurch. Revolutionary change usually involves some sharp pains, but we quickly settle into the new status-quo. Revolutionary changes often take the form of management directives – “we will now have full project schedules for all our projects.” Presto, all projects have schedules. We have all been through this in one form or another, one day you do it this way, then next you do it that way. Fast is good – sometimes, what about slow?

Merry-go-rounds
Seems like a lot of hyphens in today’s piece. The merry-go-round uses centrifugal force to basically spin kids around, make them dizzy and fall down. Oddly, this used to be a lot of fun. The thing about merry-go-rounds is that you always needed someone strong to get them going, and it seemed to take forever.

Here is an example of slow change or evolutionary change. The merry-go-round spin begins from a full stop. Usually the next step is for everyone riding to grab a bar and start walking, then running around the outside to build up speed. As the speed builds up, some run harder and some jump on for the ride. Once things are really going, you need only one person standing on the outside giving a light but fast push. Here we went from full stop to head-spinning speed through constant every increasing speed, yet ever decreasing effort.

In a strange twist, it takes less effort to keep the merry-go-round spinning than it did to get it there in the first place. This is often a characteristic of revolutionary change. So which is better, and how do we apply this to working in a PMO?

Evolution v. Revolution
I think that each of these types of changes has their place; it is the incorrect application of the type of change that causes the problem. Revolutionary change is fast, deliberate and often brutal where evolution is slow, smooth and palatable. We move through and evolution and we experience a revolution. The answer to which is better lies in the analogy.

Revolutions, like band-aids, are powerful when a change creates pain or must be done immediately. The revolution is best in lay-offs, or killing projects, or organization changes. You move immediately from one state to another and get on with life.

Evolutions are like pushing the merry-go-round; it is almost impossible at first, but as you keep pushing the changes come faster and faster with less and less effort – and everyone jumps on board. Evolutions work for cultural or procedural changes on a large scale, exactly like creating a culture of project management.

Certainly there are exceptions, and one could argue that an evolutionary change is nothing but a series of revolutionary changes all in the same direction – good point. I also think that revolutionary changes are more suited to making small scale changes. To get an organization of 20 people to use project management does not require a long slow push. Getting 200 to use PM is another story.

When you think about how you will make a change – which is the job of the PMO, think about the best way to do it. I think that you’ll find some changes are best treated like merry-go-rounds starting with lots of effort while other times all you need is one good yank – OUCH

Lessons Learned – why don’t we learn from them?

2007-03-24T12:07:00.001-07:00

Still thinking about lessons learned and my biggest question is why don’t we learn from them?

Here is the situation that has come up to make me think again. My current program has a weekly meeting with the Governance board. We quickly review the status of the major projects, go over any big issues and review/approve any changes (as part of change management).

Over the past few weeks I have been getting pressure from my program managers to cancel these meetings and go to a once-monthly schedule. The main reasons seem to be that there are too many people in the meeting, the topics are repetitive, the board gets weekly status reports, and that the meeting is boring / waste of time.

A little about these meetings: when there are no major issues or actions to be taken, the meeting runs less than ½ an hour. We also hold one meeting monthly with the board that runs a little longer – the last one was 45 minutes, and it’s never been more than an hour. By my calculations that’s 2 hours and 15 minutes of time during an average 4 week month – or 1.4% of a 160 hour month.

Now, the program managers want to reduce this to 1 hour a month or .63% of their time per month. How unbelievably efficient we must be if a .8% savings is going to make any difference!

I don’t want to think bad things about people, but less than 1% of your time on somewhat boring over-communications? What about all those lessons learned – our previous project stated multiple times that the weekly board meeting was helpful! How can we not learn???

I have some thoughts on this.

We think the lessons don’t apply to us.

This, I think, is our most common problem. I have frequently observed that project teams can be very optimistic and confident. In the example above, the consensus was that we all communicate with our bosses and they communicate with each other, so why repeat that? In my case it seems that unlike every project in the recorded history of man, our project has such good communications that we can dispense with the onerous 1% burden and spend that time on better things. HA.

I think this over-optimism and belief that this project is different is one of the reasons we do not learn. For some reason when we get on a project we think that a positive attitude will overcome stupid actions. How many times have you brought up a risk or an issue or mentioned that since we are over budget now we will probably not recover and been told that you needed to “get with the program” or “think positively” or whatever. If you are out of gas, all the positive thinking in the world will not fill the tank, why do we think it can be done for a project?

We want to get things done

In looking at lessons learned, many times we find things like – should have had a better schedule, or better budgeting, or more communications, spent more time on requirements, etc. All of these things relate to how we do the work, not what we work on. Talking about how things get done or working on how things get done does not, in and of itself, get anything done. This is one of the reasons so many people hate planning – planning is not doing and we all like doing.

Lessons like “spend more time on requirements” are not easy to implement because we don’t want to spend time on requirements. Heck “we all know what needs to be done, let’s just get to work.” Bet you never heard that before! Or, in my case, a lesson that weekly meetings were beneficial and kept everyone informed is dismissed by a “we talk about this stuff all the time; I’m need to get things done, not meet.” And so on.

The enemy here is action and the idea that action is better than thought or discussion or planning. I believe the correct action is better than either of these and as we have all found so many times, doing things wrong takes far more time and money to correct than it would have had we just done some more thinking, or planning, or meeting.

There is no visible reward for getting your requirements right. There is no tangible product from having good communications. These things are unrewarding in and of themselves they produce no immediate feedback, therefore we have a difficult time engaging in these activities or even really believing that they are useful.

Bottom line

The sad truth is that these lessons learned are useful. That time spent in doing the work better is time well spent. That getting it right the first time is cheaper and easier than doing it now and fixing it later. That keeping your boss up to date can save you from being called on the carpet. But we will not all learn this, maybe some of us will, maybe not. I guess those of us that understand this need to keep calmly and clearly reminding those who do not. Boy – talk about fun!

Culture Clash

2007-03-14T16:16:00.000-07:00

Thushara wrote an interesting question in a recent post copied below:

"When you are a flat organization and when you got to deal with a very hierarchical customer organization with lots of bureaucracy .How do you manage the communication channels as a PM of such projects? ( I mean in your company you are reporting to your CEO and all the operational level details are transparent to him. Your CEO talks direct with the customers CEO who doesn’t get any operational details.. There is a major chaos situation here.."

Not that I have "the" answer, but I do have an answer, and I learned this as a consultant more so than a PM. The problem here is really not just one of organization, but one of culture. I would imagine that the two organizations are different in size, since size generally creates hierarchies and levels.

One of the problems with trying to match up organizations is that they usually start with the matching at the top so they start with CEO to CEO. All CEOs are equal I guess. Since yours is flatter, you get to the “operational” details much sooner, and with your CEO being closer, she (he) is probably a lot more in tune with what is going on. Actually this is good for you since your boss will not be surprised – a very bad thing.

Since the other CEO is not as in tune, there are a couple of things to do. First coach your CEO of the situation; you don’t want her accidentally showing up the customer CEO. Next find the person or persons on the customer team who have about the same level of involvement, knowledge, etc of the operational details that you do and who are equally invested. Regardless of their level in the client organization, these are your peers. Work with them to build a communication plan that will keep their CEO up to speed.

Combining this, you probably need two communication plans. One plan for both CEOs and another for your CEO. That way your boss knows what information his peer is getting, and you can keep your CEO better informed so she is always a step ahead. In the mean time you and your peer or peers are getting the work done.

Generally speaking both CEOs want to know how things are going, what they can do to help, and if there is anything they should be concerned about. If you keep this information in front of both of them, then you will reduce confusion a little.

Or not, that’s just one perspective – based on communication. There are probably a lot of other aspects to look at.

Week 27 - Change

2007-03-12T16:42:00.000-07:00

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

2007-02-25T15:25:00.000-08:00

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?

2007-02-18T11:40:00.000-08:00

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?

2007-02-18T10:42:00.000-08:00

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!!

2007-02-03T08:38:00.000-08:00

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

2007-01-28T13:56:00.000-08:00

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!

Week 20 - (Building a PMO) Reporting

2007-01-20T14:19:00.000-08:00

I’ve been thinking about reporting a good bit lately. What makes good reports? What type of reporting is the PMO responsible for? When? What? To whom? And so on. I have been working recently on streamlining the reporting we are doing on the project and yet providing more information in a more useful and timely manner.

I am a minimalist at heart. I believe in one-page. From a reporting perspective, there may be a need for more than one, but I think that the PMO that provide management with a one-page comprehensive status report has found the Holy Grail of reporting. My quest is probably equally romantic and impossible, but I think there is a lot of room for improvement out there.

Let me start with two components that I have been struggling with lately – I call them the “Justs.” They are Just enough information and Just in Time. I’ll start with the latter as that is the more familiar.

Just in Time started as an inventory management practice and Dell showed the world how effective and profitable this can be. Just in Time reporting refers to the freshness of the information. We have all walked into a meeting with management to review the reports we sent out yesterday knowing that some (perhaps many) pieces of information were no longer accurate. Face it, by their nature, projects change quickly and frequently and they have a terrible habit of being unpredictable. Part of the problem is the ever popular hierarchical reporting methods.

To use my current situation as an example, I have a weekly board meeting every Wednesday morning. At this meeting we discuss the current issues, action items, and status for the two programs we are managing. These programs consist of multiple projects from multiple departments. One of those departments is IT. I get the final set of IT information on Monday afternoon for presentation on Wednesday morning. Let’s look at how that information gets to the board.

Working backwards – On Monday the consolidated IT reports are reviewed by IT management and approved for general release. These reports are created on the previous Friday afternoon from a collection of status reports by each project. These individual project reports are due by end of day Thursday. Each project team puts their report together in the day or two preceding Thursday. In this case the IT information that the board reads on Wednesday morning is a week old. A lot can change in a week. Unfortunately this means that we often report tasks as incomplete and behind schedule when they were actually completed on time.

We take a different approach on the business side. Here, there is a full program meeting on Tuesday morning. At this meeting, each project leader and team member reports their status as of that moment. The project manager updates the schedule, issues and action items right there. The program level report is published immediately after the meeting. Since the PMO is present in these meetings, we are able to produce the business components of the weekly status right after the meeting as well. This means that on Wednesday morning the board is hearing about information that is less than 24 hours old.

There are two circumstances that influence the difference. First, the business organization is less hierarchical and less formal than IT. This allows much quicker communication. My observation is that IT is oriented around structure, process, exactness and consistency – all of which contribute to some excellent, stable and reliable systems. Unfortunately, this means that non-emergency information has a long way to go to be seen.

Secondly, the PMO is directly present in the lowest level of the business meetings while we are not present in the lowest level IT meetings. This means that we get the unvarnished “raw” information straight from the people who know it the best. This enables us to better understand the information and to weigh its importance and urgency. This is not the case with IT.

I think the solution is two fold. First, set up a system and process that has the shortest amount of time between the collecting the information and reporting it. Second, eliminate every step possible between the collection and reporting. The fastest this can be done is obviously to have the person collecting the information turn right around and report it. Even better have the recipients of the information hear it first hand. Of course, it is rarely possible to get today’s busy executives to spend that much time listening to details. Don’t forget, your value-add in the reporting cycle is to aggregate, summarize, separate useful from useless, and elevate the important.

To parallel this to Just In Time supply management, getting information from the business is like going to the orchard to pick the oranges while the information from IT has to be obtained by driving to their grocery store and waiting until it is stocked on the shelves. Go to the orchard, pick the best fruit and get that to your board right away.

PMO Reporting

2007-01-15T09:51:00.000-08:00

Reporting is often viewed as a less-than-glamorous responsibility of the PMO. I think that reporting is probably one of the most visible methods that a PMO can show value. The PMO reports go to management and those managers and executives make decisions based on your reports. By providing accurate and timely information in those reports, you – the PMO – are ensuring that the foundations of corporate decision-making are solid and built on the best information available.

With that as your mission, there are several different types of reports that the PMO may be responsible for: department reporting, project reporting, portfolio reporting and PMO reporting. Let’s take a quick look:

Department reporting takes several different forms; one common form is resource management and projections. These focus of these reports is to give information on a department or group.

Project reporting is probably the most familiar, this can take the form of your red/green/yellow status reports, buffer reports (for those using CCM), or earned value. These reports give information on a project or projects.

Portfolio Reporting gives information about a collection of projects, some common reports are the pipeline report which shows where each project is as it moves thorough the project lifecycle. Other reports include a project priority list, resource and cost projections, and possible other more sophisticated sets of information. While project reports are more tactical in nature, portfolio reports are used more for strategic decision-making.

Lastly we have PMO reporting – This is simply reports that tell how the PMO is doing. Some examples are budget reports, balanced scorecards, staffing and others.

Each of these reports offers you a great opportunity to demonstrate your PMOs independence, neutrality, honesty and consistency. They are also a great marketing tool.

Marketing your PMO

2007-01-15T09:48:00.000-08:00

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)

2007-01-13T09:50:00.000-08:00

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.

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.

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)

2006-12-30T08:51:00.001-08:00

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.

Week 14 (Building a Program Management Office)

2006-12-30T08:15:00.000-08:00

Week 14 – Change Control, Capacity and Budget

As I look at our projects, we have about 15 months between now and final implementation. We also have all our requirements completed, defined and ready for programming. All this is great, but I’ve been thinking a lot about our ability to make changes (mostly scope) over the remaining time.

In looking at this, the first question is: What is our capacity for change? I think this has to be determined based on resources, schedules, lead times, budgets and the like. We may actually have the capacity to make a 180 degree change, or a series of changes that add up to that. In any case, I think each project must have some “change limit” – this being the amount of change that can be absorbed within the time and budget available.

The first existing method that comes to mind for managing change is the management reserve budget. The intention of this is primarily to deal with risks, but something similar might be arranged for change. Maybe a change reserve budget. This would then define the capacity for change up front and allow us to track against that capacity. I think that we could then add something called a “change rate” to allow us to better allocate that capacity across the project.

The rate of change would naturally (I think) have to decrease over the course of the project. So that while we might have the capacity to make say $100,000 worth of changes, we could not reasonably make all of those changes at once, nor would it be possible to make them all at the last minute.

I think that the rate would have to continually decrease across the duration of the project, and at some point (depending on methodology, flexibility, resources, etc) the project would not be able to sustain any changes - we used to call this “the freeze.” I think then that our change model would look something like that below:

I have not figured out how to determine a good rate, but the idea here is that we pace ourselves with our changes, and that if we try to make too many at any one point, we end up overloading the project- impacting dates, etc.
I know that the traditional model of change control is that we always assess the impact and elevate that to the “powers that be” for a decision on whether we can do the change or not. But experience has shown that we often end up making certain changes and not changing any dates. How many times have you heard “it’s only a week, can’t you absorb that in your 10 month project?” Well yeah, I did absorb the first 12 one-week changes, but this is lucky 13. Now with a “rate” or speed limit, you can schedule the changes, or push back if there is too much at any given time. One way might be to say that we can only accept X amount of changes for the next cycle / month / period.

I think that the concern I am looking to address is the tendency to use up our entire change budget at the beginning of a project and get ½ way through with nothing left. If we use the rate as a limit, then we can actually have the ability to make changes later in the project when they’re needed.

Another idea I hear was about prioritizing changes, I worry about this for the simple reasons that if you only have one change, then it is top priority. Then after you put that in the next change that comes up will be top priority. The priority system is useful when you have all the information in front of you, but with change, you don’t know what is over the horizon. If you did, you would have planned for it and it wouldn’t be a change and you wouldn’t need to prioritize it.

So I think the answer is to pace yourself. Whether you are running a marathon or a sprint, if you use up all your energy too early, you’re in for a hard time. If we use the change rate, then we know we will have the ability to handle at least some part of what is coming.

Of course, I have no idea how to determine a change rate, and as I think more, I realize that this will create a backlog of changes – which we can then prioritize! Hmmm

PMO Staffing (short)

2006-12-14T20:09:00.000-08:00

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.

Week 13 (Building a Program Management Office)

2006-12-02T10:19:00.000-08:00

Well full week back after the Thanksgiving break. This was another travel week as we installed a PM at one of the project locations. The PMO has now doubled in size to two!! I think the new PM will work out great as she is working in the location where all the business teams are located and those are the people who have to live with what we implement.

This week did once again cause me to think about roles and identities. What is the PMO? What is a project manager? It’s easy to say “it depends”, but when there are people and projects involved, we need to have a clear definition. I have already learned that if there is more than one boss, there is more than one definition of your role. This is doubly true for consultants.

In bringing on the new PM, I am concerned that she is being under (used/appreciated?). In this case, the PM is certainly capable of managing a large part of the project and she could certainly provide some very useful advice and counsel to the leadership team. Because of the perceptions, this is just not likely. The perception is that the PM is there to do the support work, and that’s it. I brought the new PM to the board meeting and I was asked by the business lead why I brought her –as in “she is not this level so she doesn’t need to be here.” This pretty much defined at least our starting point.

Again, it comes down to people and I have a real problem here. Clearly, we (the PMO) were brought on because of our knowledge and experience, yet this is rarely sought and often unwanted. Why would anyone seek a particular set of expertise and then ignore it or leave it on the shelf. It is like buying a high-powered computer and doing nothing but web surfing. Strange, what does this mean? Well I have a theory.

I think that the problem is one of comfort and understanding. Using the high-powered computer example, if all you know is web surfing, then that is what you’ll do. They see the computer as just able to web surf faster and better, and do not see that they can produce multi-media presentations or do their taxes or run a small business – or even better – play the latest graphics-intensive games. So the challenge there is to raise awareness. The second challenge is to make them comfortable with the tools and techniques of project management. So how do I go about that???

Well, first thought is that I have to become more assertive and aggressive. I can’t play a passive and supporting role; I have to take an active and leadership role. And that will certainly piss someone off. I don’t seem to be having a lot of luck in the persuasion department, so I’m going to take some things on myself (more work, but hopefully more success) and I’m going to push for some other things. One of which will be to have full-blown planning session for one of the projects – that could be successful, but not if everyone comes in with a bad attitude – which they will if I do this wrong. Well, this is the time of year when everyone is supposedly in a good mood; maybe I can leverage some of that. Ho Ho Ho.

PMO Support Function (short)

2006-12-02T09:50:00.000-08:00

Support PMO services are often referred to as administrative functions, and may be considered “menial” or “trivial”. Nothing could be further from the truth.

A PMO provides support services to assist with the management of a project. The key differentiator between support and project management is that support is not a managerial role. A supporting team member will often update the schedule, run meetings, follow up on open issues and other similar tasks, but they will not have the responsibility or authority to make project level decisions. Supporting on a project is often a good role for junior PMs, showing them the processes and placing them with a more seasoned PM for mentoring.

Support is the hard part of project management and it is what often meets the most resistance. Team members do not want to take minutes, track issues and action items, produce reports and so on. As with all clouds, this one has a sliver lining and becomes one of the keys gaining project management acceptance.

If you – the PMO – perform the support function, your stakeholders can realize the value of project management without incurring the cost. This will open a lot of doors and minds. Providing exceptional project support then is one of the first steps in building a great PMO.

What's a PMO (short)

2006-11-24T07:55:00.001-08:00

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 12 (Building a Program Management Office)

2006-11-24T06:57:00.000-08:00

Happy Thanksgiving to those who celebrate the event. The holiday made it a short week for me and a welcome one at that. The big event this week was the November governance board meeting. This is a typical board meeting for a program, we start with a presentation and the board members ask questions about the information, we talk about current status, upcoming milestones, issues and the like. This month’s went very well and I contribute that to two factors. The first, I was prepared. I put together a good presentation, I reviewed all the information, I had all the raw data and reports and so on. One thing I am learning, at least in this particular program, preparation is key! The second reason I think things went well is that hardly anyone showed up – lots of people on Thanksgiving vacation – for which I am thankful!

The two hour meeting lasted about an hour and fifteen minutes. We had good conversations and discussions. Both projects have made marked improvements over the past two weeks and I think the teams are much more confident and optimistic. That is really half the battle sometimes. At this point, we have a fair handle on performance against milestones and schedule, change control, scope and issues. Not so hot yet on risks, resources, financial performance and a few other areas, but working on it. Since only one department even records time and cost to the project, we are not going to achieve more than a fairly low level of control and information in those areas.

The good news for this week is that we have a project manager starting in one of our locations to help with the project work. Our one office is doing a lot of the heavy lifting in terms of PM work, and it is not getting the attention that it needs. Our new PM will start off with some more administrative and analysis work, but I expect that they will have much more responsibility very quickly. I really look forward to this as I am hoping that it will free some of my time as well so that I can spend more on putting together a PMO guidelines that can be used for all projects of this time. If the company is going to get in this business, then having a method/standard of operations for implementation will be very useful!

Well off to run a few of those new found pounds off. I think 20 miles will do the trick – that would be…. Unlikely . There’s still some apple pie in the fridge…mmmmm

Week 11 (Building a Program Management Office)

2006-11-24T06:26:00.000-08:00

Week 11 went well, if somewhat quiet. I think that a lot of people were worn out after last week. Big events were conversations with one customer and some good work on completing the project schedule for the other project.

Right now, one of the projects is working with our customer and the company that currently holds the contract to negotiate a live date. We had a change in scope and delivery and that caused all three companies to have to look again at the dates. Right now we are in a situation where we each have a date that works for us, so that makes three dates. I am sure after our discussions and negotiations we will come up with a date that is equally unpalatable for all of us. Such is compromise. I’m sure we have not heard the last on all this; it is going to be interesting.

On the other project, we really have a good workable project schedule. Now for the aficionados, no it is not leveled and based lined, with actual times and so on. That, frankly, is a little more than we can really expect based on quite a few things. The schedule does however clearly indicate milestones, major tasks and responsibilities. In other words, what needs to be done when and by whom. We have a bit more than completion dates; we do have durations and hence start dates. Right now, all of the tasks are 80 hours or less, and span two weeks or less, so we have a fine enough level of detail to be able to track the work carefully and elevate and or react as needed. I am not a stickler for the 8 – 80 rule or other such PM rules. If you read this blog much, you know that I oppose rules and forms and procedures that exist only to be complied with. If something doesn’t make life easier/better for the PM and the team then my vote is – forget it.

I had a presentation on Monday that gave me the chance to put together some of the project information in one consolidated format. We don’t have a standard presentation template. I have to confess that I enjoy presentations. I like the idea of putting together information in a format that in some ways can be artistic. If I have not said this before, I highly recommend Edward Tufte. He has some extraordinary examples of information presentation. His books and workshop are worth every penny! He talks about things like information density, sparklines (my favorite). He sums it up well as “simple design, intense content.” Not that my presentation would ever wind up in one of his books, but I am working on it.

Week 10 (Building a Program Management Office)

2006-11-11T09:09:00.000-08:00

Week 10

I had another difficult week this week. We had 2 2-day sessions where we tried to get a better handle on the work for the two projects. We actually made a lot of progress, and I think at least one of the projects is on the right path. Granted the path will be very difficult and busy. We have a lot to do between now and the live date of 3/1/07. I think that the tone of the group is much better now than it has been and I honestly see them as a “team.” I honestly do not know why this group seems to be more of a team than the other project group. I think it is certainly something that I will look at more as the projects go on. The other project group is more a series of teams who are working together. I think that some of it has to do with the size/intensity of the project combined with the personalities and the overall organizational structure.

But first about this week; for the smaller project, I was assigned (volunteered?) to serve as facilitator. The goal was really to get a clear mutual understanding of the work needed to be done between now and the live date. My first step was to lead the team through a very high level breakdown of the project. Nothing really detailed, or down to the work package level. Instead we looked at the high level tasks and looked at the task to see how complex it was, how many dependencies there were, and how “independent” the task was. For most tasks, we did not go into a lot of detailed analysis. We did find one are of tasks that one member of our team nicknamed “the water-main” that represented the critical path and many associated important and highly dependent tasks. While we still have not done any critical path analysis, I am sure that most of these tasks will end up on the critical path, or the resource critical path.

To do the detailed analysis, we went low-tech. We started with the WBS created earlier and stated breaking down the tasks and sequencing them using sticky notes and a whiteboard. I recommend this since you can move the tasks around easily and draw the relationships using the whiteboard and whiteboard markers. Nothing is permanent; you can toss a sticky out if you don’t need it, and you can break it up into two or three sitickies if you need that. This method is very flexible and visual. I think that works for most people. By placing the information on the wall in front of the team, everyone in the room can look at any part of the diagram and any participant can take as much time as they want on any section. This gives each person a lot more freedom and usually a lot more involvement.

Some other conventions we followed for the meeting. We wrote the meeting goals on a poster-sized sticky and it was on the wall and visible the entire time. We had a “parking lot” – another poster-sized sticky where we kept items that we wanted to talk about, but just did not have enough time, or were not directly related to the goals of the meeting. We also had a poster up for risks – here we wrote down risks as they came up during the discussions. I like this method since risks always pop-up during these types of meetings, and if you collect them all and address them at the end, you often find that some of the risks are gone based on what you’ve done during the meeting, and often many can be addressed with the same mitigation plan. The last constant we had was a poster with “to do” or action items on it. This way, when something came up we wrote it down and moved on. At the end of the meeting we went over the to do list, assigned someone to each and a due date. It was a great way to wrap up.

The other 2-day meeting was somewhat similar. I am faced with a very difficult situation in that group where I have somehow earned the enmity of one of the team leads who is working very hard to have me marginalized and / or removed. This is a very difficult and sensitive situation for a consultant. I am not handling this well or badly, somewhere in between, but I am being deliberately cautious and non-confrontational. It is amazing how much different things are when you are on the outside looking in.

Regardless of all that, the meetings went well. That project is certainly in a more difficult situation, and the team members are not as open to compromise and innovation as the other team. The meeting saw a wide use of the “can’t” word and several “shoulds” and “musts.” I think this team could find some creative alternatives to the situations they are in, but the political environment encourages individual success over project success. I have seen this a lot in many different organizations. Simply put, the organization, company, and most importantly the compensation system encourages success within the organizational hierarchy over successes that span organizations. This is often one of the biggest risks that projects face, and one of the easiest to overcome.

There are a lot of ways to improve projects success chances by overcoming some of my thoughts on this are:

Give someone specific responsibility for project success and give them the money to do this. Asking someone to succeed on a project over which they have no real authority is a huge risk. Make no mistake – money is authority. The person with the funding is the one running the project. The closer the money is to the project, the more likely it will be used for the project only.
Create an extra-organizational structure (like…. say a PMO) to run the project. The less influenced this group is by the organizations involved, the better. I’ve written on impartiality of a PMO before. I was able to observe over the last few days how much easier it is for the PMO to facilitate a meeting than it is for one of the project teams to do so. In the meetings that I facilitated, the discussions were within the team and there was no thought that I was trying to push the meeting or group towards a solution. In the ones where a team member was leading, there was noticeable tension between team members and the facilitator, and a tendency of the facilitator to move the meeting in a slightly biased direction.
Create dedicated project teams. I’ve seen this work time and again. Of course it needs to be a TEAM, and it needs to be DEDICATED. That does not mean a few part time people from different areas working together over the phone when they can make their schedules meet. Dedicated team work best when their members are solely dedicated to the project and they are as co-located as possible. If you can have 1 or 2 locations where the majority of the team are that’s a plus. I know this may sound contrary to flat world theory – of which I am an advocate. I still think that collaboration is best done face-to-face. The further apart your team is the less they will collaborate. Face it, to collaborate to the guy next to you often means leaning back in your chair, to do so with the team in India means scheduling a conference call, and trying to get 4 groups in 3 different time zones together is a major effort. It’s not as easy as standing up and yelling – “hey, I’ve got an idea, let’s get a coke and let me bounce it by you.”

And now that I am thirsty, I think I will take my own advice and get something to drink as I – yes, you guessed it – wait on my LATE flight home. Hey maybe that’s why I don’t believe in this dispersed group thing?

Week 9 (Building a Program Management Office)

2006-11-11T08:59:00.000-08:00

Week 9

This week I got a lot more time to do some physical, document producing work. As I’ve mentioned, one of my responsibilities is to organize the work being done by the teams and to create templates and procedures that can be used in future projects that are like this one. I kind of like that part of the work since it is a form of legacy, something that I can leave behind and something that I have the opportunity to create. I’m somewhat challenged trying to spend the kind of time I would like on these activities. Of course, I recognized that this is only one part of the entire job, and that as much as I would like, I cannot loose myself in that, but rather have to continue with the relationships that will ultimately help make the projects successful.

There in lies my newest problem – people. Here is my lesson this week. No matter how innocent a situation appears, do not ever takes sides in an internal argument. No matter how obvious it is that one side or the other is right or justified or whatever, do not take sides. You can agree with someone, but that had better be because of your knowledge or experience and not because you share the opinion. Here is what I did in a nutshell.

I was in a meeting where one member of the meeting showed their frustration and somewhat directly implied that another member was deficient in their duties. So someone got mad and made sure everyone knew it. Nothing huge - I’ve been cursed at, walked out on, hung up on, screamed at .. you name it, and this was nothing of that level, just a clear statement of displeasure with a bit of “I don’t care who knows it.” After the meeting I was called in to comment. I sad that it was clear someone was frustrated and that the behavior was noticeable and antagonistic – and in my opinion it was. I had pretty much forgotten about it but when I was asked that’s what I said. Well that was when the you-know-what hit the fan.

The person I talked to reported my statements to the manager of the person who spoke out. That person called me and quizzed me, and clearly mentioned my comments to the original offender. Well that person has placed me at the top of their hit list. This person is not the type to forgive and forget, nor are they into “proportional response.” My action has caused an all out war against me where this person is probably expending far more effort trying to harm me than in doing the project. In fact that is the project – wonder if there’s a charter or a schedule? Probably not, since project management is unnecessary to hear this person talk.

So the lesson is, if this ever happens to me again, I will politely say that I do not wish to make any comments in relation to this issue. I will say that my personal opinion is not really needed to help the project succeed. I will not be impolite, but I will be insistent and mute. Once again, I learn that no matter how honestly people ask, they do not want to hear my opinion. I already have a rule that when someone asks me a question like “is there something I can improve” or “what do you think of my management style” I always avoid commenting, deflect the conversation or give some innocuous answer. When someone working for me asks for that kind of feedback, I always tell them to think about it and ask me again in 48 hours. Those who really want to know, ask again. This doesn’t mean I don’t give unsolicited feedback where it is warranted, it is solicited feedback that has invariably gotten me in trouble.

Anyway, the week pretty much went OK, I got to spend a lot of time putting together status reports, project schedules and other useful docs. I hope to get them into use the week after next. I also spent a lot of this week getting ready for the planning sessions next week. This is really my first big opportunity to show some of my skills. I think I can lead at least one of the project teams to a good resolution. The other one, well I’m not so sure, too many chiefs and too much politics and too many divergent goals. I’m sure we will get through all that, but it is so unnecessary and counter-productive. As an outsider, I have the opportunity to observe it and learn a great deal. I hope I’m learning how to put it aside in myself and focus on the job and the people.

Week 7 (Building a Program Management Office)

2006-10-28T14:40:00.000-07:00

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?

Week 8 (Building a Program Management Office)

2006-10-28T14:36:00.001-07:00

Week 8

Well, week 8 ends with me sitting in the airport hoping that I’ll make it home in less than 12 hours. You never know. This week was very busy and productive. Ha – my phone just rang with the airline telling me that my 1:35 flight is now scheduled to leave at 2:30 – and so it begins! Well the big lesson this week is communications!

On Monday, I met with the customer most of the day going over the project management documentation, procedures, etc. For the most part we seem to be in synch. The customer has a slightly different model and they are looking for much of the same information, just in different formats or with different names. The primary concern of the customer PM is getting audited by their PMO. I cringe to think about that. I can’t tell you how disappointing it is to me that a PMO has sunk to the level of just making sure everyone fills out the forms correctly. And we wonder how we get a bad name. I’ve been thinking about that – I’ll write more later on how I think we get that way. My communication lesson on Monday was that we all have different names for things, so if you want to stick to your definition, then be prepared for misunderstanding. This lesson was repeated throughout the week.

Tuesday was another long meeting day, really two meetings. One about – yes you guessed it – the requirements. And no we STILL did not get it all worked out, even after 4 hours of meeting. Here the communication problem is relatively simple. We are not documenting and communicating our decisions. There is no central repository or central accountable person. With everyone able to continually discuss alternatives and every discussion interpreted differently and no central source or artifact, most of our calls start out with “I understood this to mean that”, or “I thought we were going to do this”…. No one KNOWS what we’re doing, they just all have their impressions of what they think has been decided. We need to implement a more rigorous requirements process. I’m going to push for formal documents to be distributed, reviewed and approved and once approved sent to change control. I know sounds fundamental, but when you hear about our fracturing problem you’ll understand a little better.

Wednesday reinforced my Monday lesson – one of the biggest barriers to communication is the fallacy of thinking that you somehow posses the “right” definition of a word. I actually heard someone say to another team member – “that is not what it means” referring to a certain word. Let’s say the word was “plan.” One we all have a problem with. How many times have we interchangeably used the words plan and schedule? They have two very different meanings, particularly to those who are familiar with PMI’s definitions. I once tried to explain the difference in the terms and that the thing that was in Microsoft Project was a schedule and not a plan. I was generally ignored and was told that I needed to be more flexible in my thinking. That still sticks a little, but it is essentially correct and I’ve tried to do better. Now, I simply call my .mpp file a schedule and if someone calls it a plan, I don’t correct them or argue.

Back to the problem at hand. If you are going to stick with your definition or your mental model, then be prepared for misunderstandings. One of my favorite quotes goes something like: “never forget that with one miniscule exception, the universe consists entirely of others.” Kind of puts thing in perspective. I also think about accident reports where everyone has a different point of view. I remember one I was in where a guy ran a red light and dinged my car, we pulled over and the guy admitted he had run it, but one of the people on the side of the road said that I had run the light, I was shocked, how could someone see the same thing I did and get it wrong, isn’t the truth universal? Well the truth is, but how we describe it isn’t. I try very hard now to think about what the other person is trying to communicate and not just the words they are using. We work in a very technical and precision oriented culture these days and we use a lot of words that have multiple meanings or nuances. Give the other person the benefit of the doubt. Explain what you are saying from different perspectives and when what the other person says doesn’t make sense, ask. Don’t assume, get to the meaning, and for Pete’s sake stop calling a schedule a plan – that really bugs me.

Leave Well Enough Alone

2006-10-22T16:27:00.000-07:00

One thing I am noticing is that PM forms tend to grow and grow. The existing forms get more complicated and the number continues to expand. I was working a risk form the other day given to me and it was in excel. The cells were locked and I had to choose from drop downs as to what type of risk I had, what the cause of the risk was, and which strategy I chose. There were a few others that I forget, but basically I was very constricted in the choices that I had. It was frustrating, what if my risk impacted both cost and time – I couldn’t choose that, I had to pick one or the other. I couldn’t even align the text in the fields – it wanted to center all the text on the bottom I thought it would look better if it was left justified and in the middle – too bad. What were they thinking??

Here is what I think they are thinking:

By restricting the choices, the form is easier to fill out for novice PMs. With limited choices, you can guide the PM through the process without a lot of confusion. I think: With this kind of paint-by-the-numbers, either you have a project that is so simple you should probably not need a risk assessment, or you have the wrong PM. Either accept that you don’t need much of a risk assessment, or get a new PM. This form is not going to fix the problem.

The restrictions make it easier for the PMO to categorize all the project risks that are happening throughout the company, and maybe steps can be taken to eliminate or mitigate those risks at a higher level. A noble and worthwhile pursuit. I think: Maybe the PMO should do some work. Instead of forcing PMs into neat boxes, maybe the PMO should be looking at the risks as they are – not as they are categorized. Where are the lessons learned? Where is the communication and community of practice to share this information? I think the access database with pie charts and pareto analysis is a lazy approach to the idea of recurring corporate project risk. Do all this, but do not force the PMs to fit it into your box, analyze the risks and find out how the risks categorized themselves. By forcing them into boxes, you risk misunderstanding, mis-categorization and actually fixing the wrong issue.

The form is being constantly tweaked and improved over time. As the PMO – form owners – learn more they make changes to the forms. Each change is designed to capture more information, or prevent mistakes, or to make it easier to fill out. I think: Leave well enough alone!! Maybe it’s time we started thinking of forms as works of art (although many are hardly that!). Van Gogh did not keep repainting Sunflowers to make it “better.” I think that we would all be a lot better off if we simplified every form and then made it next to impossible to change them. Unfortunately, we end up with PMOs who’s only job is maintenance of forms and methodologies, so we take all that knowledge and expertise and destroy it by forcing these people to come up with every more complicated forms and methodologies. Tell me it’s not true.

So I think we would all be a lot better off if we took all that experience and knowledge and spent it helping people become better project managers than in creating forms and methodologies under the assumption that people are bad project managers. First, no form is going to make a bad PM good. Second, no good PM needs a form designed for a bad PM. So make your forms useful, simple, flexible and few. Spend your time spreading PM knowledge not PM paper.

Week 6 (Building a Program Management Office)

2006-10-07T10:29:00.000-07:00

Well now, a MUCH better week. On Monday, we presented the PMO “Processes and Procedures” presentation to many of the team members. I guess about 20 or so in the room and another 10 on the conference call and web meeting. Much as I would like to think it all went well, I think the idea of using the forms and processes was received a bit like a doctor telling you that you need to exercise more. Maybe not that bad, maybe more like telling someone they had to take medicine or eat the right foods. We all know it’s the right thing, but the level of enthusiasm is rather low. Let’s face it, Project Management is not exciting in and of itself, it is a means to an end – effective projects and successful work. Much like diet and exercise lead to greater health and longevity. And much like diet and exercise, not very flashy or exciting.

The group also got together and came up with the next set of requirements. There were a lot, far more than we could do with the time and money available. We did do something that I thought was great in that we cut the list down immediately. Without any more analysis or effort, we now have 20 requirements that we are going to do cost / benefit analysis on. The others we are putting on the table and we’ll look at them after implementation. I think that the sooner you cut scope the better. When trying to complete a project, I think it is best to focus on the smallest possible scope needed for success and if things go well, add to it. Like that will happen! More likely, your scope is too large in any case. I suspect ours is as well, but we are looking at less and we now have a precedent of cutting quickly. We also have broken through a mental barrier about taking things out of the project. I think that as we go forward, the team will be more receptive and understanding of not doing things and will be quicker to cut. That will save time and money of which we have too few. Like all projects.

Got some interesting role clarification on Wednesday. We had our first short board meeting call, and I wanted them to help me understand who the major “players” were on the team(s) and who had responsibility for what. The problem I was having, and many of the team as well, was that often two team members would be trying to accomplish the same thing, or no one was working on something important. Not anything malicious, just a normal situation when a lot of people come together to work on something this complex. So I asked if the board could clarify the roles and responsibilities of the team members reporting direct to them. Well, apparently that is me. I had initially understood my role to be much more consultative than directive, but that is not the case. Very interesting… The nice thing is that I got this charter on a conference call that had just about everyone in it. Most of the board and about 20 other people were in the call, so everyone heard it and I am not having any difficulties in the “authority” area. Now how do we organize?

We have a pretty unique situation, doesn’t everyone? My real challenge is that everyone wants to be included in just about everything. You’ve noticed the number of people we have in requirements gathering and conference calls, that is pretty common. My first reaction is that this is too many to be truly effective. Just because everyone has an opinion does not mean that their opinion is going to make a material difference in the outcome. But how do you tell people that?? For some reason, it either comes off as “you’re not important” or “we don’t care about your opinion.” In an inclusive and people oriented culture, this can be a hard message to get across. Case in point, how many programs of this size have 20 people on a weekly quick status call to the Governance Board? Well I know of one.

My challenge now is to build the next level of management (we’re calling the “program level”). My inclination is to keep this level around the 3 -5 number, but it is looking like I have to make it seven. Already people are asking me to invite them to my weekly program level meeting, which I was hoping would be a good conversation among the leaders, but looks like it may devolve into a free for all. I’m not sure what to do honestly except to crack down a little. Next meeting for the group is Wednesday my thought is to run a highly controlled meeting and disinterest the squatters so they stay out and then maybe the number of people will be reduced so we can get a good and useful conversation going. Then again I may be proven completely wrong – yet again. I guess we will find out won’t we?

On another front, I am making a very deliberate effort to improve my communications to, and relationships with, Board members. I came up with something that might work for me. Since I just though of this on Friday, I’ll wait a while to share. The general idea is to make my communications deliberate and effective. Hopefully, I will build good habits there and be even better at my job.

Week 5 (Building a Program Management Office)

2006-10-07T09:09:00.000-07:00

Week 5

Well, this has not been a banner week. It really started off last Friday when I went on vacation and did not attend a conference call. Obviously, I should have been in on the call. I clearly misunderstood what was expected. Of course, I did not find out about any of this until I got back in the office on Monday. My long weekend was spent trekking the Appalachian Trail – in the rain. I was really looking forward to going back to work, wearing something dry, not smelling like dirt and sweat, and sitting down on a chair. All of those hopes came true (except for the sweating thing – after I found out about Friday). This does bring up something about discipline/failure and perspective that might be worth talking about for a minute.

I hate to fail – no really hate it. Now I’m not talking about winning at all costs, I’m talking about the making a mistake kind of failing. Even more, I hate to have someone find out about it. But I was also listening last week to Manager Tools , a podcast that is now a must for me, and I highly recommend that if you are managing a PMO, or anything else for that matter. Outstanding content, and thank you Dina Scott from Controlling Chaos for recommending them. Also another MUST podcast for me.

So getting caught making a mistake is abhorrent to me and is often very debilitating. I have a hard time stopping kicking myself and getting on with things. I did talk to two of my board after missing the meeting, and both expertly and honestly coached me. I HATED it – not that they were doing a bad job, they were perfect – using almost exactly the “feedback” model that Mark and Mike talk about in Manager Tools. But that they needed to use it on ME !! That I had screwed up so much just really got to me. Then I thought – I wonder how many times the people I give feedback/coaching to feel exactly the same way? So this was my first good lesson of the week. Something we all know, but that hit home a little more. I can make mistakes and it is not the end of the world any more than if someone on my team made one. That doesn’t excuse them, and certainly not if I make them again, but if I am to grow and succeed, mistakes are inevitable and boy when someone points them out it does reinforce the lesson.

I said the “first” good lesson this week. The second one is what I am now calling “play to the box seats.” In my career I have been pretty good with my directs and generally with my peers. The problem I have universally had is with my supervisors. I won’t go through my excuses, but I tend to put a lot more demands (unspoken) on my supervisors. I do not communicate with them as well as I would like and I often carry misconceptions around. For the most part I have often behaved as if being a good manager is to do my job and make sure my boss does not have to worry about me. I’ve stressed my independence and ability to get the job done. That’s not enough. Yeah- stinks doesn’t it. The fact is that my supervisors are accountable for what I am doing, and they have much more information and far wider views than I do. They do not always want someone who is off alone doing their own thing even if it is well-aligned, intentioned and generally effective.

What supervisors want is someone who can do all those things AND communicate, relate, understand, cooperate and more - At every level of the company. Sometimes project managers think it is enough to do their project well. Not if you want to play in the big leagues. One mentor I had once told me that after attaining a certain level, everyone in management is “good”, and if you want to rise beyond that level it takes more. One of those things is opening up your horizons, becoming far more people and relationship oriented than task oriented and becoming much more effective.

So what am I going to do? Well I’m starting with inclusion and communication. I set up a monthly call with the board that is an “official” status review of where we are on the program and the program activities. This will be a more formal review and presentation. We also have a weekly ½ hour meeting to address any issues or concerns in a more timely fashion. As I get more organized and involved, we will make this change control and issues calls that I know will be very effective for everyone.

On the PMO side we (the PMO) – which is really just two of us now, myself and a manager who spends about ½ of her time on PMO work – came up with our list of documents and RACI roles and responsibilities. What we chose were:

Action Items / Issues Log – Log of short term work/assignments/decision
Risk Log – spreadsheet showing risks and actions/dispositions – long term use
Change Log – List of changes and their dispositions

(the three above are all in one document / spreadsheet) other official documents are:

Project Schedule – MS project so far
Change Control Request – the form the change control is written on – one thing we did add here that I like is that we require information about both the “current state” and the “expected state.” I hope this will stop a lot of questions and confusion.
Meeting Minutes
Status Report (one pager)

We are hammering out organization and some of what will be reported at each level, who is responsible, accountable and what Red, Green, Yellow will mean.

The presentation is next week, so we will see how that goes. Also next week, we have our first informal board meeting and a two and ½ day onsite about the next group of requirements. Never a dull moment.

Week 4 (Building a Program Management Office)

2006-09-29T16:56:00.000-07:00

Thing really took off this week! We were able to do some real in-depth work on the requirements. While we did not solve everything, the team gained a better understanding and we were able to significantly whittle down the list. More work on that to go, but should be OK. We have a fixed budget and a hard delivery date, so there is not much choice about which of the triple constraints is going to give.

I did do some more analysis of the existing documents. What is it about some people and documents???? First, the company has several sets of documentation for projects – corporate PMO, the quality management group, and IT has its CMM documents. There are a few others out there, but those are the main ones. Each group has a very cohesive and useful set of documents and often associated procedures. But why are they so complicated?? Why is there so much information needed to do such simple things? I guess when you give people the job of putting together documentation templates and procedures, they just do not stop. Most of us can put together an action item spreadsheet in 10 minutes. Imagine if that was your job – yikes – 10 minutes of work and you’re on the street? No – why not add links and procedures and notes and more columns and and and…..

Sorry, that was a bit of a rant wasn’t it? I guess it is just so obvious to me why people baulk at Project Management when we walk up to them with a ream of paper and say “if you fill all these out, you’ll be a project manager.” Like that loan guy on the TV commercials with the stack of forms to fill out for loans. Except we will put up with that to buy a house, not to run a project! Funny though isn’t it – the last house I bought was about $125,000 and my project is around $10,000,000 but I’m more willing to fill out the forms for the house. Let’s play with that a moment. I spent about 10 hours over the course of several weeks filling out loan papers and the innumerable legal documents and signing my name about 100 times to buy my house. So if I am willing to spend 10 hours for $125,000 then I should be willing to spend 800 hours for $10,000,000 – yep almost six solid months of filling out forms ! Yet I’ll bet we spend no more than 2 weeks in most projects.

My challenge is to find the “right” amount of useful information that takes an appropriate amount of time and put it into the forms and procedures that everyone can use with the least amount of pain. I am also working on how to organize the reporting structure (not organization / hierarchy so much) in such a way as to spread the work out as much as possible so that each level does only what they need and that information is rolled up to the next level who add what is pertinent there and rolls up, etc. My PMO does not have the staff to handle much work (the PMO being me and one other part-time manager), so we have to spread the burden as much as possible to maximize the value and minimize the pain / cost.

I went back and looked into RACI (Responsibility, Accountability, Consultation, Information) method and I think that will play well here both in relation to forms and procedures. We seem to have a lot of challenges in the roles and responsibilities area so I think I’ll address that first through the reporting, then move to decision making.

Onward.

Week 3 (Building a Program Management Office)

2006-09-20T20:17:00.000-07:00

Mostly travel this week. Why is it that all your flights are perfect on your way out, but when you’re heading home, the entire aviation infrastructure fails? Of course I ended up getting home, tired and somewhat more fragrant than when I left.

The biggest things this week were the requirements. The team did agree to get together in person (guess who is writing this from the airport) to work out the details. I’m very optimistic about the meeting and the outcome. I will get the chance to facilitate a larger meeting with team members from different sites, and I’ll get to introduce a few tools and techniques.

First one will be a forced-ranking system that I’ve used for a variety of purposes from ranking projects to employees. It is a simple paired-comparison process that you can do on a grid. The one I’ll do will be on an excel spreadsheet. Below is a short example of how this works.

The idea is that each alternative is compared once against every other alternative. Half the table is shaded since you are making only one comparison. You can either work down the columns or by rows. Working down the A column, you would ask at each cell - “which is more important A or B, A or C, A or D and so on.” Once you have done this for each row, simple add up the number of times each alternative occurs. The alternative that occurs the most is the most important and so on. In the event of a tie, look for the cell where the tying alternatives were compared – the one selected is the higher. This ends up in a forced ranking with some good indications of the relative importance and differences between the alternatives.

Another tool I’m going to use is a roles and responsibility grid. Pretty simple, but there really is not one for this program.

On the PMO side, I’ve got some work! We have several areas where documents are kept, but they generally are the documents needed by each team, and not a comprehensive set of project documents. There really is not a clear standard for program documentation – there are a lot of suggestions and formats. Our challenge is to set a standard and the appropriate procedures that work within the multiple organizations. I am confident we can do it. I think the roles and responsibilities is the place to start. Understand what is expected of each role, then we can move towards procedures.

Other challenges include Risk management, change management, issue management, and many of the other traditional PM stuff. More and more next week and on.

By the way – never never tempt or challenge the airline gods for they are a vengeful and capricious lot. My flight arrived 2 ½ hours late.

Week 2 (Building a Program Management Office)

2006-09-10T16:37:00.000-07:00

Another great week. After a long and relaxing weekend, we got right back into the flow. The biggest thing this week was the discussion about the significant differences between what was estimated and what is needed. A common project issue, but this one was recognized early, and the team has taken steps to address this now rather than wait until it becomes a crisis. But that is "project" stuff. Program Management Stuff: The challenge of building a methodology and framework continue. I need to merge at least two well-developed methodologies together and customize them for this type of program. Both methodologies have a lot of SDLC (System Development Life Cycle) components and are obviously IT-centric. This poses some challenges since there will be a great deal of non-IT work to be done. I will probably get all the details on this in the coming week and have some specific items to dig in to and relate. In the area of documentation/deliverables/artifacts or whatever they are calling these today, there is a wide variety of quality and quantity. My thought here is to concentrate on what can be reused and what is unique to the program. In this area, the schedule figures prominently. With multiple projects feeding into six main programs, there are a lot of schedules out there. Well, that is not exactly true. There are some schedules out there, some spreadsheets, some word documents, some post-it notes and some good memories. My challenge is how do all of these inter-relate and how do we track this. There have got to be thousands of tasks being managed by 20 managers, how to get them all to feed information int a joint schedule? Well, honestly, I do not know yet and suspect that I am going to find out. My current plan is to work down from the key dates and deliverables. I think one "summary" or overall schedule will be used for communication with the sponsors, customers and ourside stakeholders. There will then be one schedule for each customer (2) that will be split into either 2 or 3 sub schedules each representing one of the key programs. Past that, I don't think the PMO will be involved in other than helping each of the program managers in organizing and collecting their schedule information. It is likely to be very different for each group. So far, this sounds pretty simple, so I am sure there is something I am missing. Basically mirroring the

Communication: As we all know this is and will continue to be a key. My thought here is that my first job is “seek to understand.” I do not see how I can provide team members with the information that they need without understanding the team members themselves. For this I am convinced that nothing other than personal contact will do the job. I think you may be able to like and work well with people that you know over the phone or email, but that we can’t build the level of trust necessary without a personal relationship.

For this my approach is to do some traveling, probably a lot of traveling over the course of the program. I expect that only by meeting and working directly with the team members will I understand what is important to them and their communication and behavior styles. There is a lot of work involved beyond the traveling. I hate classifying people; we (people) are too complex and too adaptable to be classified. This makes it impossible to me meet once or twice, pigeonhole someone and then stick to that for the length of the program. What I need to do is to “understand” the people I am working with, how they relate to me, the work, the environment, the company, etc.. To do this is going to require that I be very open and vulnerable. I plan to invest a lot of myself in this work, if I didn’t how could I expect anyone to trust me?

Communication is not effective without trust. Trust requires a lot more than a few visits and come handshakes.

Week 1 (Building a Program Management Office)

2006-09-02T15:52:00.000-07:00

Well, I just started on a new assignment building a Program Management Office and I thought that I would give a weekly update on what I am doing and going through, thoughts, etc. First a little background. The program has been active for about a month or two, so I am coming in early, but not completely at the start.

The Program is a set of three other programs that each consist of many projects. I’m not sure exactly yet just how many projects there are all told. One of the challenges that I’ve been asked to help with is managing and coordinating all the work so that things do not get dropped “between the cracks” so to speak. There are 6 major separate units involved, 3 are internal (I’ll refer to these as “client” groups), two customers and one external vendor – who works for the customer and us.

One internal organization has a methodology and is following that fairly well. One customer has a methodology and set of documentation that they would like to see, but I have not seen that yet. The client corporation has a methodology that is based on the PMI framework, so it is pretty easy to understand. I am still not too sure if that methodology is in use by all the client organizations.

This week, I mostly just started getting my balance and understanding who is who and what is what. I did get immediately involved in facilitating some work on budget and requirements. As a result of this meeting, I started using Meeting Minutes and Action Items. These were not new to anyone, but I didn’t see any action items for the program initially. I used the client’s forms.

The lesson here I think is to start small and simple. We have one person in the PMO – me, and a methodology consisting of 2 forms. No one seemed overwhelmed or resistant.

Overall the week went well and I got to meet many of the principles. All of whom are very capable and professional people. Nice too, I am looking forward to working with all of them!

Independence in a Project Management Office

2006-08-19T08:19:00.000-07:00

Within almost all companies, individual departments tend to be somewhat self-centered. This is not necessarily bad, since the department exists to perform some function and we want the people in that department to focus on that function. Unfortunately, this can often lead to a little tunnel vision on the part of the people in the department. They often see their projects as more important that some other areas. This is a natural behavior in the corporate world. This type of behavior can kill a PMO.

Since being a little self-centered is the norm, your peers will assume that you are operating in the same way. This is a hurdle that you will have to overcome as much as possible in order to effectively do your job. Your PMO will be reporting to someone in some department/division, therefore there will be a perception that the PMO represents that organization. There may also be a perception that the PMO is biased towards that organization. This will be a fact of life that you will either have to overcome or accept. If we use a risk model, this is a risk that you have to choose how to deal with. My proposal is that we deal with it through mitigation strategies.

Get a clear understanding with your manager. Your manager can torpedo any efforts you make towards independence, so it is vital that you have a complete meeting of the minds. If you and your manager agree that independence is important, then you can create a working relationship where it is OK to say no to your boss. A very tricky proposition, but if you have the right information, understanding and relationship, then this can be done to everyone’s benefit. With external decision criteria, and consistency on your part, this can be done.

Become totally transparent. I say totally, the only exceptions that I would make would be for something confidential or legal. In those cases, it is important that you make it clear that you are not sharing the information for those reasons. Most people can respect and understand that. By making all other information about what you do and how you do it available, you show that the Project Management Office has nothing to hide and that there are no secret negotiations going on. This strategy will also help immensely in building up trust. Believe me, people will know if you are hiding something, and if they find out, they will loose faith in you, and that can be the kiss of death.

Fight for those outside your organization. Now, this can’t be fake or contrived. Let’s say that your PMO is reporting to the COO and Marking has a big project that they are having trouble getting resource for. You will want to support Marketing, and actively push to find those people. If this means going to the COO and getting her to take people of her projects to work on the Marketing one, then so much the better. If you support only your own projects, you will not be seen as objective and independent.

Be consistent. In everything, people can not easily trust someone who they perceive as inconsistent. If you combine consistency with transparency, then people will be able to tell why you supported one project over another. They will also see that this applies no matter whose project it is. We all trust predictability. Consistency can also help eliminate conflict before it starts. If people know how you will react, and why, they will often alter their behavior. If someone is trying to get a project through that has a very low IRR, and they know that IRR is one of the top project scoring criteria, then they are more likely to delay, defer or reject the project before it ever comes before a review board.

Stick to you values. I know this is obvious too, but has to be said. Your PMO will have a set of values and goals and behavior (if you don’t have these now, they I strongly suggest that you build them). If you unflinchingly stick to these then you will be seen as trustworthy and independent.

It would be great if you could do all this one time, but unfortunately you will have to constantly engage in these activities. It is like rowing upstream, the minute you stop rowing, you will start going backwards. Sometimes quickly, sometimes slowly, but it is inevitable. If you remain honest and true to your values, then you can make wonderful progress and may begin implementing some very large changes within your company.

Soldiers

2006-08-14T23:15:00.000-07:00

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.

Hiatus

2006-07-26T05:54:00.000-07:00

All,
I apologize for the recent gap in my posting. My laptop has been sent to the shop, and not only is this where my materials are, but the rest of my family has been active on our only other machine. Who would have thought, now I'm wishing we had another computer - more computers than TVs or bathrooms. I wonder what that says about me......

Back soon

Derry

Marketing Your PMO - Positioning Project Management

2006-07-14T09:16:00.000-07:00

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!

Heroes and Soldiers

2006-07-03T13:41:00.000-07:00

I want to talk about two of the many types of people you will work with. As with any attempt to categorize people, my examples will fall short of illustrating the true complexity of people. However, I hope this will be helpful when you are looking for candidates and trying to understand some of the motivations others (and maybe yourself). I know that these terms may raise some controversy for those of you in the states; I am using the archetypes here and not trying to make any judgment or inference.

Heroes
We all know who these are, from Beowulf to Superman these are the people who slay the dragons and save the day. This is the “go to” person who can always solve the problem that no one else can deal with. Heroes live for the impossible task, the life-or-death struggle and the insurmountable challenge. Many of us probably were heroes at one time, getting juiced by the challenge, long hours and impossible odds and finally pulling it off at the last minute. We all love heroes, but everyone is not a hero, and sometimes you just don’t need a hero. Heroes have some characteristics that we need to understand whenever we work with them:

Heroes are responsive: Pick up the red phone, turn on the Bat-signal, yell for help and your hero is there.

Heroes get the job done (whatever it takes): If it absolutely, positively has to be done, then a hero will get it done. Great, but pull out your checkbook, heroes do not come cheap.

Heroes are Fast: Faster than a speeding bullet! A hero will be there, solve the problem and make everything right in a flash – there is no comic hero called “slow man” or “the Slug”, heroes fly to the rescue, they don’t walk.

Heroes are loners: The only place you will find a team of heroes is in the comics. Heroes don’t want to be bothered with others – sometimes they have a side-kick or trainee, but that’s often a dangerous job. To paraphrase “Q” from Star Trek Next Generation – “it’s hard to be a team player when you’re omnipotent.”

Heroes make a mess: When Superman battles it out with giant robot invaders, they usually tumble a city block or two causing billions in damages. Ever see a hero cleaning up afterward? No, they are gone on to the next crisis. This happens a lot in programming where the hero comes in and writes some obtuse code that invariably fails 3 months later.

Heroes are direct: Heroes act on problems, they “go for the jugular”, they are “can do” people who are “results-oriented.” Heroes go straight to the problem and solve it.

Heroes need contests (conflict): A bored hero will find a dragon to slay, princess to rescue or go on a grail quest. Simple tasks like farming or filling out a timesheet are beneath them, not worth their talents. Without a test of their talents, heroes are not heroes, they are just like you or I so a hero will always be looking for the next dragon or quest.

Heroes are egotistical: Some exceptions with reluctant heroes, but for the most part, these people are good and they know it. This means that they will have special needs that you will have to meet.

Heroes are lousy leaders: While a hero may lead a charge up the hill or be the first to attack a problem, they are not leaders. A hero is a terrible mentor. Heroes are not generally patient or circumspect or thoughtful. Heroes act, they do not talk or think or plan.

Heroes ride off into the sunset: Let me beat these clichés to death. A hero leaves, they’re off to the next challenge, and they often leave a mess. Guess who gets to clean that up?

Heroes are dangerous: Just ask every Security officer on the Enterprise (red shirts). Standing too close to a hero can be a problem; our hero may be impervious to nuclear weapons, but those of us nearby are slightly less durable. When a hero comes in to save your project, if they succeed, they’re the hero (again). If they fail you will be watching them ride off into the sunset while you clean up the mess and count the cost.

Sounds like I am against heroes. I am not against individuals who are heroic, I am opposed to hero cultures.

The Hero Culture

This is an organization that worships heroes. In these, everything is an emergency; it is all about getting it done and not about planning. Thinking is looked on as ineffectual since doing is paramount. In these organizations, there is always another fire to run to, another urgent problem to solve. People in these organizations are seen as heroes and only those who put forth heroic effort are viewed as valuable.

Unfortunately, this culture thrives on these situations. It is far more exciting to pull the project out at the last minute by pulling 90 hour weeks than it is to just plan the work correctly and finish on time with no fuss. In a heroic culture, the latter type of project is looked on as if there was a failure. Projects that do not require heroic effort must have been underestimated and the team members were lazy. Think about a football game. Who is the bigger hero, the team that puts 7 points on the board every quarter and shuts out the opponents or the one who wins in the last 10 seconds by a hail-Mary pass?

Problem is – projects are not contests, they are projects, and that is where the hero culture fails.

PMO Overboard

2006-06-21T12:00:00.000-07:00

One of the major goals of every PMO is to help build consistency across an organization. Many of us, and many executives, have interpreted consistency as using the same processes or forms. As I said in my Cargo Cult discussion, there are some of the dangers of jumping right into implementing forms, procedures, guidelines and standards before building the proper infrastructure. Even with good planning and the right support system in place, you can get trapped into a situation that morphs your PMO from a corporate leader and change agent to the equivalent of the Auditing department for projects.

OK, now that I’ve offended auditors everywhere, let me state clearly that I feel that auditing and standards are a vital part of bringing consistency and compliance to any organization. Without verification, how will you know how well you are doing? What I am cautioning against is the danger of making verification and auditing the primary functions of the PMO. Certainly you will have some of this work, but if you do not carefully exercise growth, you may end up spending more time telling people how to fill out forms than anything else.

So, if we assume that you have grander expectations for your PMO, how do you avoid this trap? There are several methods and techniques that you can use. The first is to follow Ulysses’ lead and prepare for the song of the Sirens.

Listen to Siren’s Song (and live through it)
There are many sirens out there, and they are not all trying to sell you the ultimate enterprise software or methodology or training or consulting. Some are far more subtle, so tie yourself to the mast, and listen to the song, Mythology tells us of several sirens and their powers. Without pushing too far, let’s use them as a metaphor for what you will face.

I say “tie yourself to the mast” because restraint is vital to any engagement with sirens. I did not say that you should put wax in your ears. The siren’s can offer great benefits and solve a lot of your problems. The danger is not in hearing the song, but rather in crashing your ship on the rocks. You will be lured by comprehensive, detailed and well thought out solutions. Sirens will promise you a comprehensive pre-built solution to your problems that, with a few tweaks, will be perfect. When you first hear those sweet sounds, prepare for some dangerous waters.

What you want to do is emulate Ulysses and gain the benefits without crashing. I can’t tell you what you may need to do in every situation, but here are some examples

Software: Software solutions today provide for almost every need of a PMO, which is exactly what you have to watch out for. In today’s environment, software is often the only solution. By making a careful evaluation of what you need and what the software offers, you can implement only a select subset of functions, and then only in a controlled manner. Don’t open the flood gates.

Consulting: This is another wonderful resource. Consultants have faced similar situations and are often specialists at what they do. As with software, they will often offer more than you need by singing their sweet and reasonable song. Here you must have your goals set, defined and finite. If you know exactly what you want the consultants for, then you can control the situation. Even if you want them to give you recommendations, make that a separate engagement with the delivery of recommendations. Once you have those, you can decide which you want to take and then engage consultants where you need them.

Certification: This is one that blindsides a lot of us. There are some standard setting bodies the offer certification through compliance with their standards. In my experience, most of these bodies produce outstanding products and organizations that adopt these standards have consistently shown marked improvement. Like Ulysses, listen to this song and benefit, but beware of the rocks.

The Rocks
Simply put the danger with all of these is that you will implement something that requires a substantial support system. Guess where the resources to do this will come from? Right – your PMO! The bigger and more complicated a system, process or standard you put in place, the more work you will have to do to keep it alive. You may have to budget and resources to handle this, more likely you don’t.

You are probably constrained by headcount and / or money. Based on your goals, how do you want to spend your limited resources? Many a PMO has died by trying to implement something that took more resources than they had, or that fundamentally changed the PMO. Many directors have told me that they can’t call their team “The PMO” because PMO has a bad name. They then go on to say how the old PMO tried to implement this enterprise-wide software system, or process or certification and failed. They failed because they were seduced by the lure of the “comprehensive solution.”

What probably happened was that the PMO started with a mandate to create change and an abundance of enthusiasm. They then tried to implement something that was so complex / difficult/ intricate that, in the blink of an eye, the PMO transformed from change leader to the enforcer of the status quo. Naturally, this gained them nothing but enmity, resulting in the demise of the PMO. You probably want to avoid this.

Navigation:
Start with the obvious. Keep it simple. You do this by sticking with your goals and putting everything else to the side. There will be many attractive side paths that lead only to destruction. You are better served to achieve one goal on time than to accomplish too much too late. You can always do more, but you know all this.

Next you will want to determine how the work can be rolled out and shared. Not the implementation, but the ongoing operations. If you implement something that only the PMO can manage, then only the PMO will manage it. Think about rolling out procedures, tools and forms in such a way that they can (as much as possible) be supported by the organization as a whole. You want Project Management to become part of the culture, what better way to do that than to have everyone contributing. One way to think of it is like performance evaluations. In most companies, these are not done by HR, but rather by management and often with employee contributions. Performance evaluation is part of the culture.

Using a software system as an example, if you start with time management only, implement that and give maintenance and reporting capabilities to the users, you will have made a major achievement. By keeping your destination in mind and sharing the control with others, you can still hear the siren’s song without crashing on the rocks.

Marketing Your PMO – Metrics - Control

2006-06-11T09:35:00.000-07:00

Control:

The control drivers are similar to, and overlap, many of the other metric areas, but I think it is important to note that in some instances control is the success criteria. Project Management is an excellent medium for improving control in an organization. Every one has experienced the feelings of helplessness and frustration when things get out of control. If you have children, you know exactly what I am talking about. Unfortunately, even Project Management will not help that problem, but it will help at work. Image the frustration that a COO or CIO feels when they do not seem to be able to influence or change the way their organization works. To them things seem out of control, so they look for ways of creating a situation where they have a certain level of control over what is happening.

You will know that control issues exist when there are not really any good answers to some of the following questions:

What is everyone working on?
How much time are we spending on new projects?
Are we spending our time on the most important work?
How are we progressing the corporate goals?
Why is everyone so busy yet nothing seems to be getting done?
Why does everyone hate us (this happens a lot when IT gets out of control)

And so on. The asking of these questions is the first step in addressing any control issues. If no one recognizes the symptoms as being the result of control issues, then you have an entirely different problem. Control is one of the best ways to advance Project Management in your organization. This problem is a great opportunity to show value, and once you have hooked management on being in control, they will never let go. Hey – they wanted management so they could be in control right? So what to do?

Control metrics are going to be a little broader in scope than the other metrics. One level of control is simply knowing what is going on and being able to direct that. This requires relatively simple metrics and measures. However, you can move up the scale to such things as portfolio management and balanced scorecards which are far more complex and involved. I’m not going to do justice to the more complex metrics, but let’s cover the highlights of possible alternatives.

Inventory – Hopefully you have done this, or at least started. Knowing what is going on is the first step of control. Find out what everyone in the organization is working on. Not what they say they are working on, but what is actually going on. At first this will take some interviewing and investigation. I’ve found that this can be a communication issue. For example, you might ask an IT manager what her group works on. She might recite 4 or 5 big projects and a few smaller ones and completely neglect to tell you about maintenance time. You are representing project management, so the people you talk to may think you are asking only about project management. In the case above, it may have sounded like the manager’s team was not doing a lot, until you find out that 80% of her team’s time is spent on production problem resolution and enhancements. There may be a perception by others that her team doesn’t get much done because no one knows about this other time. Once you find out what is being worked on – document and publicize. That alone will change things.

I’m willing to bet that you will find that your organization is split into an unhealthy number of separate activities. In one personal example, I did this study and found that an IT organization of 150 people were working on 78 separate projects as well as performing regular IT support functions. One CIO referred to this type of situation as a “death of a thousand cuts.” I’ve seen this again and again; look for it in your organization. Just bringing this to light will create some real benefits.

Aggregated PM Metrics – Another more advanced way of demonstrating control is to take the information generally gathered at the project level and aggregate and summarize them. This is the traditional metrics you would expect from a PMO. Some examples are:

Projects Delivered on time / on budget / variance
Project Change counts and magnitude
Actual v. Estimated
Resource Time (Realization and Utilization are good here)

Advanced Metrics – Like I said, I will not cover these in detail here, but below are some examples:

NPV of Project Portfolio
IRR of Project Portfolio
Balanced Scorecard and Portfolio Metrics such as:
o Customer Satisfaction
o Financial Achievement
o Alignment / Advancement of organization goals
o Improved Revenue
o Cost Savings

There are others, but I caution against these until you have the ability and demand for this type of information. These types of metrics require a bit of infrastructure and effort. If management is not willing and ready to commit this (which they are usually not at the beginning), then you will be in a very unpleasant situation where you cannot deliver. If you get pressure to go with the full load, do whatever you can to push towards a small start. Suggest a prototype, starting with easier information, whatever. I’ve said before one of the best ways to fail with a PMO is to over promise.

Marketing Your PMO – Metrics - Competency

2006-06-04T11:16:00.000-07:00

Continuing with the basic metrics that you can use to show PMO value.

Competency:
The drive for Project Management competency generally comes from some internal source or sources. This may actually be a primary driver of the existence of your PMO. These drivers generally take the form of statements like “we need to become more capable with our project execution” or “we plan to become a world class organization.” Terms like “best practices” also are thrown around here. The idea is that there is a clear recognition that something is missing – project management competence. Unfortunately, this lack creates some problems for you in trying to fill that void.

One problem is that “competency” is only very generally defined and understood and will mean different things to different people. Your job at this point is to nail down a definition. You start by interviewing stakeholders giving particular attention to those who hold the purse strings for the PMO. Yes, that sounds superficial, but in order to infuse a Project Management culture in your organization, you have to exist, to exist you need support and money. After interviewing you should have some qualifications that stick out as competency measures. This then is your basis for the measurements and communication of competency.

Now comes and important part of the work. You have information about competency and how to measure it. With this information you can create the definition of competence. If you do not clearly define competency and communicate that definition, you run the risk of not meeting expectations of those who have a slightly different perception. With a common definition, you can shoot for goals that are understood by all.

Another problem with competency is the same one that every new PMO faces. How can you show improvement? You want to be careful that you are not implying incompetence as the prior condition, but rather show improvement in existing capabilities. I recommend that once you have defined competency and communicated (socialized) this, you benchmark. For each component of competency, where do you stand right now? Benchmarking gives you a lot of advantages:

It gives a much better picture of the current state
It involves many stakeholders giving them even more input and buy-in
It gives you time to better define, adjust and communicate what you will be doing.
It gives stakeholders time to become comfortable with the ideas

Of course the biggest reason is to get the baseline metrics and to be able to show improvement from those initial values. Everyone has agreed to what competency is. They have agreed that more competency is better than less. They have agreed that the organization is at the defined baseline. If you can show that your PMO is moving the organization from less competency to more competency, you are clearly showing that the PMO has value.

So what are those metrics that will show value? While these may be easy to list here, measuring these may not be quite as simple. Let me start with the easier ones.

Training and/or certification of Project Managers: Clearly if your Project Managers are more competent, then the organization is more competent. If your company will spring for it, PMP certification is a great idea. From my personal perspective, I do not recommend this as something to be taken lightly. I’ll get on my soapbox for a second. The PMP certification is something that belongs to those of us who choose Project Management as our profession. I do not think that PMP are three letters to be put after someone’s name so that they can get a better job, or a higher salary. If you are not serious about PM, don’t bother. Anyway, that said, certification of dedicated, capable people is a clear indication of improved competence (also consistency). Other types of training work well also. You may have internal courses, you could have a vendor come in and give a class or series of classes or send team members offsite. Any of these works as long as you are consistent and measure. Creating a career path (I’ll cover that later) with required training and showing progress along that path is a great method.

A Knowledge Repository. This can be the beginning of your methodology, a library of best practices, or anything similar. The idea is to build something that can be accessible to everyone and that will contain institutional knowledge. Some good components of this might be:

Lessons Learned
Common Project Risks
Useful Documents and Forms – project status reports, meeting minutes, etc- the beginning of methodologies
Approval and Review Recommendations – who needs to know about your project and review/ approve steps
Templates
Past project folders

This area will be a great place to consolidate the knowledge and experience of the organization and show that you are learning from the past.

Industry Standard Measures: There are quite a few of these that measure competency for an organization, such as CMM for software, Six Sigma for quality and efficiency, or OPM3 for Project Management. A warning, these tend to be very comprehensive and detailed. I do not suggest adopting any of these without a lot of forethought, money, patience and commitment. Going down one of these roads is NOT trivial. I do recommend that you become familiar with these and others. There is a lot of great information, ideas, measures and knowledge in these methodologies. The methodologies use Key Indicators or Key Process Areas and other measures, almost any of which make a great metric for measuring competency and improvement in your PMO.

Cargo Cult Project Management

2006-05-26T11:37:00.000-07:00

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.

Metrics References

2006-05-24T10:36:00.000-07:00

Apologies to my past professors for not using the correct reference style, but frankly I don't feel like spending an hour correctly formatting a set hyperlinks. And since this is not for a grade I don't have to.

These are some of the documents I read when putting together the articles and presentation on metrics. I used a little of this and a little of that, so all share pretty equally. My thanks to the authors for making their work available.

Assessing the Value of Project Management Offices (PMO) By PROFESSOR YOUNG H. KWAK, PH.D. (KWAK@GWU.EDU, HTTP://GWU.EDU/~KWAK ) AND CHRISTINE XIAO YI DAI, PH.D. CANDIDATE (CDAI@GWU.EDU )

Selling Project Management to Executives: What’s the hook? Dr. Janice Thomas, Associate Professor, Centre for Innovative Management, Athabasca University, JaniceT@athabascau.ca

Growing Your Business Through The Project Management Office Steve Rollins, MBA, PMP, Steve.Rollins@EPM-Solutions.com.

The State of the Project Management Profession Gregory G. Stine, PMP, Project Management Institute.

Marketing Your PMO – Metrics (cont.)

2006-05-23T11:03:00.000-07:00

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.

Marketing Your PMO – Metrics

2006-05-20T08:21:00.000-07:00

So, how well is the PMO doing? How much money are you saving the company? Have you created a Project Management culture? Are your projects more successful? Are they taking less time, more efficient, lest costly, higher quality…. Are you going nuts trying to figure out how you can prove your PMO is helping? Well Metric is certainly one way to communicate this.

The metrics a PMO Director may be concerned with fall into three broad categories. Project Metrics – these tell how well an individual project is doing, so things like EVA, risks, issues, those types of information would be collected and reported. Second there are Portfolio Metrics. This is a completely different topic, but corporate alignment, strategic goals and so forth would be covered here. Lastly, and most germane to this column are PMO Metrics. I’ve divided these into 5 categories based on the primary drivers. This is no firm, hard-and-fast categorization, but rather something that just helps me think about the purpose and type of metrics. The categories and some discussion are below:

Compliance:
The compliance driver I usually external to the organizations and can come in the form of laws, regulations or contract agreements. Probably the most prevalent and well-known compliance driver these days is the Sarbanes-Oxley Act. The basic premise behind compliance is to ensure that a certain minimum level is reached. If you have children, you know exactly what compliance is when you say – “clean your room” and do an inspection later to find that everything has been stuffed in the closet. For which you usually get the response “you didn’t tell me to clean the closet.” So, while I don’t advocate this method of compliance, the basic tenet is the same. Compliance Metrics then need to measure and communicate compliance.

First, you need to understand the compliance and non-compliance conditions. In many cases this is written somewhere, probably a contract or some other legal document, so get ready for some confusing reading. If you are lucky, said document may have information about how compliance/non-compliance will be determined. If it does, then those measures are exactly what you will use. In any case some determined investigation on your part will reveal the compliance goals.

From there, create a process to measure those goals and begin measuring. Create a contingency plan to bring you back into compliance should the metrics show you have slipped. The use of run-chart type measurements with control limits is well suited for compliance measurement. But remember, you are not looking to be “exceptional” or “superior” at compliance, this is a pass/fail game, so do not put more into this than is necessary to ensure that you are passing. Kind of like the PMP test right?

Consistency:

The drivers for consistency usually come from inside an organization. Often they come as directives or mandates from management. These can be as simple as “we need to be more consistent around here” to adoption of one of the more rigorous methodologies. Some of the better known methodologies are Capability Maturity Model in software development, Six Sigma, ISO, or OPM3. All of these methodologies have a foundation of consistency. It’s a simple concept; you can not improve what you are doing if you are always doing something different.

The first step then is to do the same work the same way every time, only then can you improve. Great, but how do you prove you are becoming “more” consistent, or that you have reached a level where you can say that you are consistent? If you are using one of the aforementioned methodologies, you are in luck as there is ample information and processes for you to use. If you are not, or as an addition, you can perform these measures yourself.

The key to consistency is adoption. You want to measure the adoption rate of the standards. Often this can be expressed in numbers or percentages. Numbers are good to show raw progress while percentages show the increases in terms of penetration. Since we are a PMO, we will be measuring how well Project Management is being adopted within an organization, so some measure here might be:

# or % of Projects with Project Charter (or plan, schedule, etc.)
# or % of Projects with an assigned Project Manager
# or % of Projects using standards
# or % of Departments using PMs in their projects
# or % of employees trained in Project Management

You get the idea – find out what your management means by “consistent” and start to measure that. Of course, by measuring you will improve adoption and hence consistency. No manager wants their VP to ask them why they are not using Project Managers in their projects when everyone else is. Conformance is a powerful motivator. The nice thing about these metrics is that they are binary, either you are doing this or you are not. Your job as PMO director is to capture the individual components, aggregate and report. Not too tough, but very powerful.

A warning here, like with all measurement, you risk becoming seen as the police. Don’t be a tattle tale; consistency is a great way to work with your peers to help them adopt Project Management. As you collect the numbers, you will notice that this or that department is a little behind or is using less than another. This is your golden opportunity. Go to that manager, show them the numbers (BEFORE YOU PUBLISH), explain how the numbers are derived and suggest ways to improve. Say something like: “If we were to assign Dan to these projects that would bring you up to 90% of your project with assigned PMs.” They may not be your biggest advocate, but no one wants to be at the lower end of the curve. Do not “enforce”, help, assist, find ways to make them successful.

Building Your PMO – People, Process, Tools – Part II – PM Processes

2006-04-29T11:47:00.000-07:00

(Apologies for the shortness this week - life and work keep interfering )

Well, you are building a PMO, so you’ll be expected to come up with some Project Management procedures. There are a plethora of great procedure sets out there that cover everything you can imagine about Project Management, they usually come with their own documentation and form sets. Your company probably already has some standards or processes that you will want or need to include in anything. Again, below are my ideas and thoughts, suggestions only, I know many of you have had different experiences, please share them.

Start Small.

This is pretty generic and universal advice, so I’ll go quickly. Whether you are starting from scratch or have some existing material, start small. Most of you know this one already. Don’t try to impress by inundating your organization with rules and forms, they’ll rebel. For the first time around, I would use very light processes and forms – maybe a charter, schedule, action items/issues list, and meeting minutes. Have your PM do all these so that no burden is on the sponsor or other team members. You’ve got good PMs, just trust in that, they’ll get the job done, and that is what counts.

What to do with Existing PM Standards?

This can be a real problem. Management may be looking to you to implement these standards, or to enforce them. Personally, I did not get into this to “enforce” anything, so I would begin negotiations with the objective of starting small and controlled and building on. In all likelihood, the package or set of standards you start with will not fit the way business is being done. Use this to encourage a process by which you start with a subset and add on as needed.

One company I worked for had purchased a very comprehensive set of Project Management and software development standards and procedures. There must have been 200 or more forms. The product was available on the intranet, and the project manager was expected to go and select the methodology they were going to use and then use the forms and procedures associated with that methodology. The methodologies were all based on software, and they were pretty specific – web based, mainframe, client-server, purchase, etc. I am sure that you can guess what happened. Since there was no PMO or procedure for using the tool, PMs just picked out what they wanted, used that and then copied the documentation from one project to the next. Everyone was “using” the tool, but the only similarities ended up being the fonts and the title pages. IMHO, that was because it was too complex. That is one reason why I advocate people, processes and then tools.

So, take whatever you have, boil it down to the essentials, then take half of that and start. You should not have any problem convincing people to use less, except maybe those who are invested in the tool or process. Find them, and get their help and buy-in, make them a part of this. Be careful that you are not perceived as wanting to slay a sacred cow, if all of this is new, then you can use that as a starting point. Things like “I need to start small so I understand everything” will go a long way here.

Next time, I’ll talk a little about build or buy options and how to move from processes to tools

Building Your PMO – People, Process, Tools – Part II – Processes – Forms

2006-04-23T11:48:00.001-07:00

First, let me express my general distaste for forms. While I can’t say I hate all forms, I do believe that many organizations have used them incorrectly and created situations that are more harmful than beneficial. I do believe that the right forms can be very useful and beneficial. For one thing, every time I get on an airplane, I become a huge fan of the pilot’s pre-flight checklist. However, I don’t think I want my pilot filling out a form during a crisis – I’d rather they were flying the plane. That said, I think that by following a few guidelines and understanding the nature of forms, a PMO can use them to benefit the company and the PMO!

Forms Tend to Grow Rather than Shrink.

I will not say that I never saw someone remove a field from a form, but how many times have you filled out something on a form and had absolutely no idea how it got there, or what it is for, but you have to fill it out! I could scream. If you are going to create a form for anything, start as small as possible. I’m a fan of the “one page” school – fit it all on one page. That forces you to decide what is important and drop the rest.

Now I did have one team member who thought that meant to decrease the font until it all fit on a single page – no really. This is the same guy that gave me a 91 page screen design – yes ONE screen with 91 pages of documentation. Laudable in some ways, but I could not see the customer reading it and signing off, so in my infinite generosity I instructed him to cut the size by half, making it still twice as large as the other screen designs. Well he just printed the darn thing on both sides of the paper. Surely there is a level of the pit reserved for these people, but I digress.

Here’s a real frightening thought. Your forms may be around for a long time. Not only do the darn things grow, but they seem to be immortal. What will your form look like five years from now? I don’t know, but wouldn’t it be nice if it was just as useful then as it is today. Start with this in mind; be careful not to incorporate temporary jargon, or the types of things that will require maintenance over time. Some examples are the names of departments or people, use instead the role that the person will be playing (project sponsor, project manager, etc). As a general rule, wherever possible, don’t put anything, when you have to put something make it as self-explanatory as possible. If you have to explain your form now, image how it will be in five years. Don’t image, take a look at some of your company’s forms.

Never use Two Forms where one will do.

I think that if you build a form with the idea that everyone who sees it hates it, and wants nothing more than to not fill it out, you will have a good start. Double or triple that, and rather than help your customer meet their goals, you’ve create a lifelong enemy. Fewer and less and above all, please don’t require the same information in multiple places.

I recently moved and got a new doctor. I ring the bell, wait until they slide back the opaque glass and acknowledge my existence. Upon seeing me, the nurse hands me the every popular clipboard (provided to her by the makers of Viagra) and a pen (compliments of the makers of Levitra). “Please fill these out” she says. So, with odd feelings of inadequacy, I shuffle to my seat with the enthusiasm normally reserved for my dentist and begin. Moving through the process I discover that there are 7 forms that I need to fill out – ALL 7 ask me for my name, address, city, state, zip and phone. Three ask me about my “emergency contact”, they all require my SSN and signature – I can’t go on, I’m having flashbacks. If you think this is frustrating, think how tired your customer is of having to enter that stupid 14 digit “project number” on every form! At least I care about my address and emergency contact. Don’t ask for the same information more than once.

One great example of how one team I was on used this principle is that we created a form for the project initiation. This was just to get things kicked off, get a sponsor and a PM, that kind of information. This form next became the project Charter by the addition of a few sections giving more information about he project, team, scope, etc. The charter then goes in front of the Steering Committee for approval, once approved, the charter then grows into the Project Plan document. Now, I know this is an example of a form growing – which I said is bad, but no duplicate information is required, the document grows in proportion to the stage and complexity of the project, and no one is having to fill the same thing out multiple times. I think this is a great approach- we also use this for meeting agenda and minutes – the agenda becomes the minutes by the addition of a section. There is then only one document to store.

DIY – Do it yourself.

OK, want to keep your customers from hating your forms. Fill them out yourself. I’ve advocated doing the work yourself before, and the reasons are the same. How can they complain if you are doing the work and they are getting the benefit? Certainly some will complain that you need to be “working” not filling out forms, but that’s a whole different problem. Aside from delivering value at a low perceived cost there is another benefit to you (the PMO) filling out your own forms. You certainly will not want them to be as simple and easy as possible.

Try it, I’d like to get that nurse to sit in his waiting room for 6 hours writing their name and address again and again. I’ll bet they would figure out a better way! Just like you will. If you and your team are intimately familiar with your forms, as only those who use them constantly are, you will find ways to make them as efficient as possible. That incentive does not exist when you graciously provide others with the forms. Even asking is not enough. They are probably too busy filling out forms to tell you how to do it better. If you and your team are using the forms daily, those forms will become models of efficiency – trust me!

Building Your PMO – People, Process, Tools – Part II – Processes – The PMO as a Professional Services Organization (cont.)

2006-04-08T11:41:00.000-07:00

Standards

These are not the PMI or QA types of standards; I’m not referring to making sure every project has a charter. There are certainly great ones out there and some that will work for you but I’m talking about standards for you, your PMO and your team.

I believe that everyone wants to achieve more, by setting standards for your team; you challenge them to do better. Also, standards create a personality for your PMO. If everyone on your team can be expected to meet a high level of professional standards, then the same can be said of the PMO. Unfortunately, if one member falls out, you’ve got trouble – but that’s why you got into management right?

As an example, let’s take the value of Teamwork. How would you set standards for this? You set standards as expectations, some ideas:

· We help when asked – we are never “too busy”
· We always treat each other with respect – particularly when we do not agree
· We are here for the success of the organization, the team and each other. Only by helping others succeed can we succeed.
· We will share our ideas, experience, knowledge and problems with each other.
· We are never alone.

I’m sure there are more that you can come up with – I’d suggest a small number of standards for each value. The standards help define and communicate the value. I deliberately used “we” in all of these to help communicate the teamwork even more.

Since you have set standards, you have given teeth to your values. Your values are not slogans or sound-bytes; they are something that everyone on your team lives. If your behavior is not going to match your values – forget it. If these standards only apply for your friends or – worse – for those in power, forget it. I have seen too many people who set their behavior standards based on the size of a person’s office. I have nothing but contempt for that kind of behavior.

Understanding

So we have values and standards, how to ensure that everyone (all your stakeholders) understand them. You want to make sure that not just the team, but everyone associated with the team understands your values. When your customers know your PMO will do what is best for them before grabbing for some personal gain, you become valuable.
Understanding of your values and standards will establish the identity of your PMO. You are as your customers perceive you. I won’t get into the whole “perception is reality” thing, but perception is understanding. By acting according to your standards, you create the reality, perception and understanding that you want. Your PMO is too important to leave this to chance.

You will also need to communicate your values and standards. I’m not a fan of big posters or plastering slogans all over the place, so how do you communicate?
First, you communicate by how you act. For example, what does it communicate when a project is rejected because it is not written on the latest version of the Project Charter? Not teamwork, that is for sure. However, when you cut and paste the old Charter into the proper form and work with the sponsor to fill in any missing elements, you send a clear message that you will do what it takes to make your sponsor successful.

Branding your PMO is important in giving it an identity and helping people understand. Think about any popular brands and what that brand means to you. How quickly you can understand values by simply thinking of the brand. Wal-Mart is low prices, Disney is fun, Nordstrom’s is service and so on. You PMO will have a brand and identity whether you like it or not, best to make sure you have the one you want.

Good old written and verbal communication is part of the mix too. How do you communicate the success of a project, by giving accolades to the team members or crediting the PMO? Do you freely share information, or do you hoard it? Do you seek feedback; do you talk with your stakeholders constantly? Lots of good communication help out there from all walks of business, use it.

Management

Now the ugly part, you’ve got to manage all this. Standards provide value only when consistently applied and enforced. Quality can only exist where it is measured and required. Training is effective only when planned to achieve a goal and tailored to each individual. All this means a lot of work for the manager, so some ideas:

· Tie the standards to rewards and penalties. You can not be serious if you are not willing to reward and penalize behavior. Reward is easy, but penalize is vital. If you do not take appropriate action when values are violated, you’re sunk.

· Train your team in what you expect. Don’t just lay down a standard and say “meet it”, help them meet it. Give your team members sufficient time and training to achieve the standards. You are creating elite professionals. Olympic-level athletes train constantly, even more importantly, they think and analyze their performance. It will be no different for your team. I’m not talking about sending them off to a 3 day course and marking the “training” box complete. Training is ongoing and career long.

· Align your individual goals with the team goals, which are in turn lined all the way back to the company goals. Clearly link the work of each team member with the success of the company. As a PMO you are probably already doing this for all the projects, just do the same for the people. Knowing exactly how you are contributing to the success of the company (and yourself) is a great motivator – particularly for the type of people you are hiring.

· Feedback, feedback and more feedback. High performance individuals want to know how to perform better, don’t expect that they will “know” that what they did is good or bad all the time. Your team will be making mistakes and they will be hitting it out of the park – you need to be there both times. Spend the time to take a careful look at how the event came about and in the former, work to avoid it and in the latter, seek to repeat.

If there is any way to do it, create a significant performance-based component to you salary plan. Not just on-time, on-budget, on-scope, but also including teamwork, personal growth, and contribution to the PM culture that you are trying to build. One performance goal we used was for each PM to design and give a one-hour class (lunch and learn type) on a Project Management topic at least once every quarter. This got the PM some time in front of audience, let them prepare a class; learn more about a topic and share that knowledge with others. This was a real win for everyone involved.

I haven’t talked much about the customers / partners yet, and not to slight them at all. I really believe that your partners hopefully are the key to the PMO success and the success of each individual. Here I’d like to suggest something off the beaten path and that is to have your partners provide key input into any review or performance evaluation / compensation for you and your team. This can be pretty scary, and unconventional, but let me give some reasons:

· It is really all about the relationships you build with your partners and your ability to work with them towards mutual success. If they are not successful, you can not be. Feigning success because you delivered exactly what was asked for when your partner is unhappy is rude, unprofessional and dishonest.

· Your partners are vital to your success, what better way of telling them and showing that you mean it than to give them direct control of your success? You will never be a “them” when you share your success this directly. If you can somehow tie your success to your partner’s even better!

· It places you in a vulnerable position by showing you trust your partners. Vulnerability is a key component to trust. Partners will never trust you if you can not show that you trust them. This is a great way of showing you trust them. As always, this isn’t a trick or gimmick – you must be sincere and ready to take the consequences, if this is only a token amount, then don’t bother, it has to be a significant amount of money.

By tying your values, goals and objectives directly to performance, you give them teeth and meaning. No one is confused about the value of money and this is you voluntarily placing your money where your mouth is. Just be ready, lack of commitment in any form will invalidate this strategy, and worse lose the trust of team members and partners.

Building Your PMO – People, Process, Tools – Part II – Processes The PMO as a Professional Services Organization

2006-04-01T14:09:00.000-08:00

For the most part, PMOs are staff organizations for the most part. We are a service only unit within the company. We are often perceived as not producing value and many people are less-than-enthusiastic with the forms, methodologies, “bureaucracy” and “paperwork” that we produce. On the flip side, in Circle of Innovation, Tom Peters advocates that “all value comes from Professional Services”. The value of your PMO is in the people who represent it.

We’ve talked about how to put your team together; the next thing is organizing and managing them. Quick word on my management philosophy - I believe people want work to be meaningful, they want to succeed, and they want to be part of a great team. Our job is to put the pieces together to make a great team.

In his book True Professional , David Maister uses to the term professionalism to encompass the ideas of pride in work, commitment to quality, genuine desire to help, and dedication to the interests of clients. (Everything I have read of his has been wonderful – I highly recommend him). Using this as a basis, we can evaluate some of the components of professionalism.

The first component of professionalism is competence. One must have the capability to perform the required service or create the required product to be a professional. If you can’t do the job, you are probably not going to last long, although I have seen some consultants who… well – not us, and not our PMO.

Next component is attitude. A professional is not here “just for the money” they demonstrate care and commitment. Care is the key here, if you and your team do not care, everyone knows – fortunately you wouldn’t be reading this if you didn’t care, so that’s a done deal.

Finally professionals have character. There is a set of core values that they consistently demonstrate by their actions. If you cannot be trusted, your in trouble and will be very ineffective. If your customers don’t trust the PMO with their projects, portfolio or team, you cannot do your job. Again, not a problem for us personally, but we do want to make sure that the team has all these attributes in abundance.

Implementing and Managing Professionalism

So how do we get started – obviously the right people will make this a walk in the park (that’s why it’s people, process, tools), but even then you cannot take any of this for granted. I suggest you start with a set of core values. These values must be clearly communicated not just in words, but also through consistent actions. Values cannot be sacrificed to any form of expediency, they are not a fall back position or something to put on your card. If you show that your values are flexible or inconsistent, then you loose all trust and who wants to be like that anyway! Some suggestions on values:

· Teamwork
· Commitment to Learning and Continual Improvement
· Adherence to Standards
· Quality
· Customer Satisfaction
· Communication
· Intolerance of unprofessional behavior and results

Your set will depend on what makes sense for you and your team. We all have different values; different priorities for those values. The important thing is that we remain consistently faithful to our values.

Regardless of your PMOs specific values, I think that implementing and managing a professional organization falls into three main areas. First, professionalism requires a set of standards for behavior, performance, learning, quality, communication and service.

Next, we want everyone associated with the PMO to have the same understanding of these values and what is required to meet acceptable levels. This understanding can only be gained through a combination of training, education, coaching, counseling, and experience.

Finally, like everything else, professionalism must be managed. Progress and performance must be managed by making adjustments, encouraging improvement, and discouraging non-compliance. These activities fall within the purview of management – your job.

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

2006-03-25T09:59:00.000-08:00

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!

Building your PMO - People, Process Tools - Part I - People

2006-03-18T10:54:00.000-08:00

I want to suggest that there is an order to how you develop a PMO, and probably any organization, and the first step is getting the right people. Then you develop the processes and then tools. Of course this is an iterative process – not waterfall, but if you do not have the right people, forget it.

I won’t go into the logistics, as a manager you’ve probably already done this a million times. The right skill set is important, but that is very dependent on your situation and what you need. I firmly believe that you can teach people almost anything in terms of skills, as long as they are the right people. I think the right people for a PMO need to have a few important characteristics.

A Passion for Project Management: This is hard to find, but easy to detect. If you are doing multiple interviews, you will find this. One way to see it is to get them talking, if they can’t stop talking about PM, they love it. You will need people who are excited about what PM can do for a company. Passionate people are infective and you want everyone on your team to spread the virus of PM and PMOs. Each team member is the PMO every time they say or do anything. You’ve met these people. For a great example, just watch a Discover Channel documentary on some archaeological dig an listen to those archaeologists talk about a piece of rock or a skull. Or watch Antiques Road show when they have a really great find. They shake and can barely hold still enough to talk, and everyone else is thinking – “It’s just a rock for Pete’s sake” – but to them it is something so much more! And somehow to you that rock becomes so much more. That is exactly the type of person you want on your team.

Independence: Your team will often be out on their own, they need to be able to stand up to a lot of resistance and sometimes abuse. Personal independence and strength of character are vital. The last thing you need is a team member going to the customer location and caving in or saying things like “OK, we don’t really need a charter if you don’t want one.” One technique I’ve used to help PMs in the field to help them in situations like this is to have them tell the customer “I have to do a charter, my boss requires it, so if you would help me through this, that would be great.” That’s a less confrontational approach. How to determine if they are independent? I’ll talk about one in the “interview” section later.

An Open and Flexible Mind: Sounds like a yoga thing, but I hope you understand. I have had great PMs who could work independently, but could not get out of a rut. One of the worst situations is where the PM insists on following the letter of the law and not the spirit. Insisting that the customer must have this or that field filled out exactly this way is annoying at best, and it can torpedo your PMO quicker than anything. No one wants to be forced to do trivial work, and believe me, there are tons of customers out there who thing PM is trivial. That is what you are up against, so if your team can not focus on the vision and the goal and find creative alternative routes there, you are in trouble. Using the charter as an example, it is important that the document exist and that it serves it’s purpose, not that the cost benefit section contain an ROI over 5 years calculated using the corporate cost of funds at 6% and future value projections at 7% and so on. NOT TO say that your project should not have some kind of cost/benefit analysis!

A Sense of Humor / Perspective: This is something I always look for in employees. If they can not smile and laugh, frankly I’d rather not work with them. Additionally, I have found that people who do not have a sense of humor take things too seriously and tend to be closed minded. They also have a hard time at self examination, if someone can’t look at themselves and laugh, then they probably have a hard time changing. I hate to say this, but hey – it’s only work and most of us are not involved in life-threatening projects. The person who will pour themselves into their work heart and soul, but still understands that it is just that- work is the kind of person I love to work with. When you find these people keep them!

Four is enough for today - next I’ll talk a little about the interview process which is absolutely vital to finding these right people.

Building Your PMO - 10 PMO Books

2006-03-14T17:45:00.000-08:00

Here is a list of 10 PMO (and portfolio management) books that have been recommended by other PMOers. I can't take credit for this; this is a compilation of books that I've collected, some from the PMO SIG, and some from my former PMI local chapter. I encourage any of you to post your thoughts on the books. I'll post my thoughts on the ones I've read too. Just to be clear - I am not personally recommending any of these (yet), but I know how hard it is to find good reference material. My first shot at links, so forgive me if that doesn't work.

J Ross Publishing has some freebies at http://www.jrosspub.com/

Advanced Project Management Office, The By: Parviz F. Rad, Ginger Levin
A comprehensive text that looks at function and implementation and covers the complete project management office in a simple format that is easy to read and understand. The author did an outstanding job focusing on the project management process, including project performance and competency. While many industrial organizations are becoming involved in project management, The Advanced Project Management Office will guide project practitioners into the world of success.

Project Management Office Toolkit, The By: Jolyon Hallows
The Project Management Office Toolkit shows you exactly how to apply project management structures to your company's core function, starting from the ground up. This book includes a CD-ROM containing every essential form you need to successfully complete a project, as well as more than 50 worksheets, templates, charts, and descriptions needed to establish a project office, set standards and organize new information.

Running the Successful Hi-Tech Project Office By: Eduardo Miranda
This is your complete how to book on establishing the Project Office as a methodology for managing multiple development initiatives within your organization. The book presents the PO (Project Office) as a model for use in a wide variety of organizations, especially in R and D environments. As more and more forward-looking firms adopt the project form as their preferred way to organize development work, the need for you to coordinate the use of scarce resources and align initiatives becomes quite..

Project Portfolio Management By: Harvey A. Levine and Max Wideman
Project Portfolio Management is an increasingly hot topic in New Product Development, IT, Pharmaceuticals, R and D and Engineering. Harvey Levine has compiled the first guide to help program managers and managers of project offices sort through their existing projects and create a healthy portfolio of projects that will lead to increased ROI for the organization. Levine answers the following questions:

Project Portfolio Management By: James S. Pennypacker, Lowell Dye, Eds.
Selecting the right projects to work on is critical in gaining a competitive edge in today's marketplace. Learn about portfolio management tools, techniques and methods in this collection of articles from leaders in the field like David Cleland, Robert Cooper, Thomas Saaty, David Frame, Steven Wheelwright and others. Case studies and best practices show you how others successfully manage their portfolios.

Advanced Project Portfolio Management and the PMO By: Gerald I. Kendall, PMP and Steve C. Rollins, PMP
Covers the strategy, tactics, and processes needed for successful project portfolio management. It discusses how the PMO can effectively influence project teams and their team members to consistently seek out delivery acceleration opportunities and/or delivery threats relative to their work, and the overall mission of the project team. It also provides a detailed plan for both strategic planning and a PMO, reviews the most popular EPM tools and provides a way to evaluate PMO implementation using..

Using the Project Management Maturity Model: Strategic Planning for Project Management, 2nd Edition By: Harold Kerzner, Ph.D.
Using the Project Management Maturity Model, Second Edition is the updated edition of Harold Kerzner's renowned book covering his Project Management Maturity Model (PMMM). In this hands-on book, Kerzner offers a unique, industry-validated tool for helping companies of all sizes assess and improve their progress in integrating project management into every part of their organizations. Conveniently organized into two sections, this Second Edition begins with an examination of strategic planning pr...

Project Management : Strategic Design and Implementation by David I. Cleland and Lewis R. Ireland (Hardcover - Jun 10, 2002)

"There is nothing permanent except change," advised Heraclitus of Greece in 513 B.C. Project Management: Strategic Design and Implementation, Fourth Edition, by David I. Cleland and Lewis R. Ireland, provides contemporary evidence that both change and improvement are the natural order of things in project management literature.

The EnterPrize Organization: Organizing Software Projects for Accountability and Success By: Neal Whitten. PMP
Neal Whitten presents a highly practical guide to software project management, using a model that builds on the strengths of functional projectized and matrix organizations, while reducing or eliminating their weaknesses. You will recognize proven and familiar ways to define key roles and responsibilities, while also discovering exciting new organizational ideas for software projects. Throughout the book, Whitten shares lessons that have a profound impact on your ability to draw out project…

The Complete Project Management Office Handbook by Gerard M. Hill (Hardcover - December 18, 2003)

"[I]f a reader wants to implement a PMO at the working level, The Complete Project Management Office Handbook is a thorough description of how to do it. Its well-defined project management continuum and numerous tables and function models provide detailed guidance for anyone, from the novice to the experienced project manager, to determine where they are in the project-management-office continuum and how to achieve their objective…[This book] is a comprehensive resource for creating or growing a PMO." -Journal of Product Innovation Management, 2005

Marketing your PMO - Field of Dreams v. Drug Dealer Approaches

2006-03-12T12:54:00.000-08:00

I think we are all familiar with the Field of Dreams approach which goes: "If you build it they will come." Under this approach, if you build the perfect PMO or the perfect set of forms or the perfect methodology the world will beat a path to your door. Much like the final scene with lines of cars driving into Ray's field, there you will sit in your office with a line of people hungry for PM wisdom, methodologies, your forms that are paragons of efficiency and meaning. And then - hopefully you wake up. Remember, they have done without you are your "bureaucracy" just fine up to now. You may be lucky and you have the support you need to implement a PMO, and some people may actually recognize the benefit, but there are still a bunch of people out there that do not and too many of us will end up in organizations where there is passive resistance and lip service. Not only does it make the job harder, but it could result in a failure and a bad name for the PMO. I am sure there are plenty of you who work in organizations where PMO is a 4-letter word, and probably because someone tried to build one using the Field of Dreams approach and it failed. Worse, they could have been using the “take your medicine” approach where management insists that everyone use PMO methodologies – because it is good for them, and then proceeds to chase the non-conformers around the building with a teaspoon of PMO trying to catch them and make them swallow it. I am sure there is no one model that will work, so PMO builders need all the tools they can get. My favorite is the “drug dealer” approach.

This is a very simple approach. We (us PMO guys) know that there are many benefits to a PMO – I won’t reiterate them, if you don’t know, you might want to do some more reading J. The problem is getting someone else (the right people) to appreciate those benefits. So, your task is to first discover the pain point(s) of those people – your stakeholders. A good person to start with might be your most vocal opponent. Talk to that person – do NOT talk about project management or PMOs, work to find out what bothers them, what causes them pain. It might be that they never know what their projects are doing, and they don’t trust the people who tell them that everything looks good. Obviously, you need to find something that Project Management / PMOs can help them with. Once you have this understanding, you will need to do some work.

Figure out how a PMO and/or project management can help, and then do it. You have to be careful not to interfere, and you need to make sure that ALL the work is done within the PMO, do not cause any impact on the stakeholder or their team(s). I would suggest that some kind of report or information is a good way to go. In my case, we did an impact analysis of the current project load and what would happen if a certain project was added. Whatever it is, it needs to be something useful and here is the catch – the first one is free. Once your stakeholder experiences some of those PMO benefits, they will want more. As you supply the services or information to the stakeholder, the value will become apparent. By creating something of value, you also create something worth paying for. Whether that payment is support or work or budget, once the benefits are clear and experienced, you will find your work much easier.

Hope this helps.

Demonstrating PMO Value - Why Prioritization is Important

2006-03-07T06:39:00.000-08:00

OK - everyone hates having to decide which project is more important than which. Frankly, I find that a little disheartening since setting priorities and direction is exactly what we look for in senior management. It seems that some senior managers (not the ones I work with mind you) think that everything is important and that their job is to get you to understand that and just "get it done." - Crap

Some facts:
1. Unless you are working at some idiot factory, there will always, always be more good ideas for projects than there will be people to do them. The day there are more people than projects, you might want to update your resume, because sooner or later management will figure that out.

2. Corollary to fact 1: YOU CAN’T DO THEM ALL – duh. I was in one meeting where I tried to explain this and was told that we would just hire more people if we didn’t have enough, so unless you have an unlimited budget, you probably can’t do all your projects – certainly not at the same time. If you tried to do them all, you would probably still be working on a punch-card to CICS conversion today.

3. SOMEONE IS ALREADY PRIORITIZING PROJECTS. Admit it, when a worker has 20 projects all equally important, what do they do? They do the fun one, the interesting one, the one that their buddy over there wanted, the one their boss wanted, the last one someone asked about….. Not the optimum prioritization method. Now image you have 10 people working simultaneously on 10 projects all equally important. What are the odds that any 2 people are even working on the same project at the same time (I know statistically the odds are good, but you get the point). So everyone works on whatever project until someone with some pull tries to get them all together on the “hot” project. We then drop everything, work that project for a while and the others languor in neglect until one of those becomes hot – this is not a logical prioritization method.

4. Sometimes, less is more, slower is faster…. There was an article that I read in the April 2004 PMI Journal - MANAGING THE IMPACT OF CUSTOMER SUPPORT DISRUPTIONS ON NEW PRODUCT DEVELOPMENT PROJECTS by Robert C. Ash and Dwight E. Smith-Daniels(sorry it's a secure link, but PMI members can get to this) that studied the effects of switching between different work items / projects. Basically, the more you switch, the less you get done and the more time you need to re-familiarize yourself when you pick up where you left off. And the longer you are away the worse it gets. So, let’s face it multi-tasking is great but it has its limits. You can not expect to write 4 books at the same time if you switch after every letter. Maybe it would be better to write one book at a time, maybe 2. The problem is that today (my experience is with IT so I will use that as an example) the average programmer is supporting one or two production systems, has a few minor projects (“back burner”) and one or two major ones. That may be the perfect mix, but if it is, I haven’t seen any evidence of it. The more you switch (past a certain point) the more you loose. So our indecisiveness is expensive.

5. It takes longer to do many things at once than it takes to do many things sequentially (again within limits). Look at the book example. Have you ever decided to clean the kitchen and an hour later you’re in your bathroom picking up dirty clothes? The kitchen is still dirty, the bathroom is not much better, and you’re frustrated because you just can’t seem to make any progress?? Just like work. What would have happened had you just stayed in the kitchen?

So where do these fact lead us. The conclusion is that our current method of not deciding and trying to do everything at once is expensive and inefficient. Now here is my thought – you don’t need to prioritize, just do fewer things. You can try this two ways:
Actually prioritize projects – think “to do” lists. Lots of political work here, but ultimately you want people doing the work that is most beneficial to the company, so getting the whole portfolio thing up and running will be a boon, but it takes a while and it is very difficult. Which leads to my second alternative
Just make a list. As the PMO Director, just make a list of all the projects (if they are all equally important, then it doesn’t matter which is first – right). Publish the list and tell everyone that this is a list of projects in priority order and that if they are working on more than one of these projects, then they should give all their time to the highest until they have completed their work and move down the list. Of course that’s not going to work, but it will point out the need for consensus prioritization. No one will disagree that everyone should be “on the same page” or pulling the oars together, or whatever your teamwork slogan is.

Demonstrating PMO Value - Aligning Work with Objectives

2006-02-04T10:16:00.000-08:00

Aligning Work with Objectives

by: Derry Simmel, MBA, PMP

Companies today are looking for more ways to make the most of every dollar. They have long had objectives and goals, mission statements and vision. These inspiring words are designed to motivate team members and encourage all departments to combine forces and drive to success.

Unfortunately, too often these finely crafted words end up as little more than banners and plaques next to the elevators or on the company website. Cynicism aside, most organizations are dedicated to achieving the objectives, but the gap between objective and project is often uncrossed. With all the best intentions, companies today are still spending resources on projects that will have no real impact, or worse, projects that are causing harm.

As the Chief Project Officer, you bring unique capabilities and advantages to the company by being able to make this important connection. You can demonstrate the value of the work being done by connecting the work directly with the strategic objectives. This approach also sets up mechanisms to measure and report on the contributions of the projects.

This article is not a step-by-step guide to project alignment, and does not address mandatory projects. We will however discuss ways of creating an environment favorable to successfully making the connection between strategic objectives and the projects.

Some of you will have project alignment thrust on you; others have been trying to sell the process for years. In either case, this is a priceless opportunity and one that will not happen twice. If you are not already, this activity will make you and your team an integral part of corporate strategic management.

A few tenets that form a basis for the process are below. While these may seem obvious, they are often ignored when decisions about projects are made. By understanding, communicating and incorporating these tenets into the connection process, you will find your task easier.

Every project a company executes either contributes to that company’s success or its failure. There is no in-between; a project that “does no harm” uses corporate resources that could be better spent on a project that contributes to objectives.

All Projects are NOT created equal. Every project contributes differently. It is not in the company’s best interest to treat projects “equitably.”

There are more good projects than there are resources to do them. The corollary to this is you can not do them all. Many companies try to do too much, resulting in missed dates, quality problems, etc.

Not all projects contribute to all objectives. It would be nice if everything we did contributed to every objective, but they do not and they will not. It is acceptable to have a project that doesn’t contribute to one of the objectives. It is even possible, and reasonable, to have a project that goes against one of the objectives.

You will have far greater success if these ideals are accepted by those involved in the process. Next, you will objectively, transparently and simply connect strategic objectives with the projects in your portfolio. It is vital that the process be demonstrably objective, transparent, and easy to understand.

The process must be objective. If any part of your process is perceived as partial, it is over, do not pass go, do not collect that bonus, go directly to obscurity.

Your process must be transparent. If it is not, it will be perceived as secretive. A secretive process must be biased - see “partial” above.

Your process must be simple (easy to understand). You can not explain a difficult process in an elevator speech. Most people are not going to pay attention to a long explanation, resulting in lost interest and commitment.

Your process will consist of three main components, the objectives, the relationship of each project to those objectives and the overall portfolio results.

Objectives:

Projects are going to be measured against objectives. You want to know not only whether or not a project contributes, but how much it contributes.

Objectives that are not clearly understood will yield conflicting results. While everyone in the group knows what “Customer Satisfaction” is, they rarely agree on that meaning.

Like projects, not all objectives are created equal. It is more important to comply with the law than it is to write new job descriptions. Understanding this and the degree of difference is important. I suggest that your process indicate not only the ranking of each objective but its relative importance or weight. Saying objectives are ranked 1, 2, 3 is not as informative as saying that objective 1 is 300% more important than two and two is 1% more important than three.

Projects:

Here we are looking at connecting objectives to projects, not determining validity of projects. Some projects may have strong connections to objectives but be cost prohibitive or just not feasible. Connectivity or alignment alone is not sufficient for determining the viability of a project.

You will need some way of evaluating each project against each objective. There are a number of methods that can be used; you may even want to use different methods for different objectives. As long as you use the same method for the same objective for every project you can expect consistent results. Remember the principles of objectivity, transparency, and simplicity discussed above as you build and use this method.

As with objectives, I recommend that you establish the intensity of the connection. Projects that are highly aligned with corporate objectives would be more valuable than those that are loosely aligned.

There are many fine examples of techniques available in books, articles or white papers. Most portfolio management tools come with some form of connectivity/alignment process as well. Some research, knowledge of your organization and your own experience will lead you to the system that works best for your company here and now. As with all such things, start small and simple, prototype, change and evolve.

First Post

2006-02-02T08:32:00.000-08:00

OK,
This is my fist log to get this started. In short, I want to talk about PMOs. Project Management Offices, Program Management Offices, Enterprise PMOs, Service PMOs, you name it. All of these organizations serve an important purpose in business today, and I think those of us who work in PMOs (let's agree to use PMO as the generic term) know the importance and potential. PMOs are all about understanding work, and with that management, strategy, tactics and more. We are all about Management, and this our PMOs are probably the first physical representation of a company actually "thinking" about work instead of just "doing".

So there we start. How do we aid our organizations in becoming better not just by doing better, but deliberately planning and thinking about how to do better. World-class runners don't get that way by just running a lot - they plan their workouts, their diets, their sleep, you name it. World-class companies do the same. 'OK - enough to start - post your thoughts and ideas, let's open some more conversations.