Saturday, October 28, 2006

Week 8 (Building a Program Management Office)

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.

No comments: