Saturday, November 11, 2006

Week 10 (Building a Program Management Office)

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?

No comments: