Thursday, March 29, 2007

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

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

Saturday, March 24, 2007

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!

Wednesday, March 14, 2007

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.

Monday, March 12, 2007

Week 27 - Change

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

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

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

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

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

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

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

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

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

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