An Interesting week ahead

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

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

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

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

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

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

Derry

Quick thoughts on a PMI research paper on PMOs

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

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

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

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

Band-Aids and Merry-go-rounds

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?

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

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.