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?
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.
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.
Sunday, October 22, 2006
Leave Well Enough Alone
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:
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.
Saturday, October 07, 2006
Week 6 (Building a Program Management Office)
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.
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)
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.
Subscribe to:
Posts (Atom)
