In project management, we generally group our processes under the heading of “methodology.” For some reason, I think methodology brings a more formal connotation than process. Either way you slice it, the way we do our work is what those of us in the profession are all about. The PMO is the corporate manifestation of the need to improve the way we work. So, what did we learn about how to work together on this particular project? I think five of the top 10 lessons were process related. The list and discussion follow.
1. We left management and planning unattended for too long.
Bet you never heard that one before! Without going into a rant, essentially we began the project with a boilerplate project schedule and methodology that was designed for small projects of this type. The schedule called for a 16 week step by step implementation. That went down the drain almost immediately and now 17 months later – TA DA! We go live. If you are going to plan – do it! Do it right, do it often, and don’t let convenience dictate how long you are going to plan. On my other project, we have a two-day planning session coming up this week. Guess how long we are going to plan? Not until we have a good plan, not until we have a shared understanding – two days – that is it for a 12 month multi-million dollar project the entire leadership team is getting together for exactly two days to plan! Boy, are we good! ---- ooops I’m ranting – suffice to say, my opinion is that planning may not always be perfect, but I’ve never been on a project where I didn’t see a lesson learned like the one above – and I’ve never even heard of a project where people said that they wish they hadn’t spent as much time planning.
2. We had the most success when we were all informed.
Communications! There is an interesting story here, and while it is not the only communication situation that helped us, it is one worth telling. Since about mid-December, the project has been hanging on by a thread with looming deadlines and a lot of nail-biting. We gave one of our weekly reports to the board, and someone suggested that we might benefit from a daily call – touch point, stand-up, type of thing. Well, that went over like you might expect – “I’m too busy to take time out every day for a call”, or “I know what I need to do” “That would just slow me down” and so on. We decided to adopt a method that I think I stole from scrum. First we scheduled the call for 15 minutes. During the call we went through the roster and each person said what they did yesterday, what they planned for today and any situation that might be keeping them from accomplishing their work. For the first week or two we had abysmal attendance, of about 15 invitees we were lucky to get 5. We persisted and elevated to the board asking that they “encourage” their team members to attend. That ultimately worked and for January and February we had great attendance. Some times the calls went long, some times we were less disciplined that we would have liked, but the #1 positive feedback I got for lessons learned was on how much the daily call helped. Almost every participant in the call mentioned it as one of the 3 things they would do again. It was really rewarding to see that popping up so often as I got the responses.
3. Once engaged and informed, management responded quickly and helpfully.
Yes, “once engaged and informed” are the key words here. We had a real problem being succinct and persistent about our needs. Of course without a schedule or a good understanding of the work, that was hard. However, every time we were able to say what we needed, for how long and when, we experienced great responsiveness. This then is the key. Don’t raise vague complaints – the team was working long hours and making little progress, but they were unable to clearly express the need. Once we sat down, thought about it and gave a clear definition - we needed an Access expert who had some product knowledge for about 3 – 4 weeks at least 50% of the time. The executives fell all over themselves getting the right person, and while it was a bit more than 4 weeks and quite a bit more than 50% of the time, everyone hung on and we got through it. Moral – know what you need before you ask.
4. We did things right, wrong, and mostly late
This is typical of every project. We made a lot of mistakes in how we approached the work, in how we solved some of the problems, but I think these were all exasperated by our lack of clear objectives. We did not have critical success factors or a good schedule initially, so we were not able to keep the project on target. Everyone had a sense that things were going bad, but we often waited or delayed either through optimism or ignorance. Then when it got really bad, it was too late to recover by any normal means and we had to call in the cavalry. Only long hours and additional people allowed us to pull though – the sign of bad planning and waiting too long to acknowledge (recognize?) a problem. There was a lot of good work late in the schedule that if done earlier would have been higher quality and easier on everyone.
5. A great customer relationship got us through many challenges
There are a lot of ways of looking at this. My favorite metaphor is the “open kimono” one. Doing business with full transparency in my book is the only way to go. That doesn’t mean giving up the company secrets, but it does mean keeping the customer informed and if at all possible making them a functioning part of the team. Too many managers try to censor the information that goes to the customer so that they are giving the customer a specific contrived view of the project. Everyone sees through this and it does little more than cause distrust. You may be able to control the information flow, but the customer will know that something is being held back. How they react to that differs among customers and people, but it is rarely a good reaction. In our case, we had weekly meetings and discussed any level of detail that the customer wanted. We discussed our process and schedule, and when we were late, we talked about that too. The customer knew that we has their best interests in mind and they trusted us – not blindly, but because we were open and honest. The customer team was exactly the same sharing their challenges – all this lead to better understanding. When we hit a rough spot we hit it together, and that is a partnership – no hype or glad-handing, mutual respect and trust.
There you go, only one left for next week – tools – maybe I’ll cover it now. We didn’t have the skills and tools needed. Make sure these are lined up and immediately available, or you will be left scrambling. My father in-law is a wonderful mechanic, electrician, plumber, you name it, and he ALWAYS has the right tools – and that makes all the difference. When you can’t seem to get things to work right, find an expert and ask – they will have the right tools – which reminds me that my new hand-built computer still refuses to power up – time to have granddaddy over to visit the grandkids and maybe take a look at my project :-)
Sunday, February 25, 2007
Sunday, February 18, 2007
Week 24 (Building a PMO) - Lessons Learned?
If I take the lessons learned from last week and look at them, I think we can logically divide them into 3 categories – People, Processes, and Tools. These are the building blocks of every organization or project. There is a lot of overlap in these lessons and some fall into all three categories, but the division works for my purposes here.
People: The people lessons were:
- The people we had were great; there just weren’t enough of them.
- Unclear roles and responsibilities led to confusion and loss of precious time.
- We were slowed by constant competition for resources.
- We did not have a clear understanding of the work when we estimated.
These issues paint a clear picture of our project and our main people-related challenges. We were consistently understaffed, competing for resources and often confused about who should do what. What is not mentioned here is that there were effectively 4 project managers for this one project and no one had full authority – so there’s the answer to the confusion problems.
As I look back, it is possible we did not get the people we needed due to political skill, combined with the lack of a single project manager. Let’s face it, obtaining needed resources within most organizations today has more to do with how good you are at asking than how much you need them. In our case, I think we might have allowed ourselves to be victims. When we did not have what we needed, we often rolled up our sleeves and gave it our best shot while half-heartedly asking for help. This tendency towards action meant that we tried first and then ended up pleading for people only after we had gone down the wrong road. Better to get the right people in the first place, or manage this as a risk with contingency and mitigation plans (longer timeframes, training classes).
The roles and responsibilities problems started from the beginning. The project initiated as if it was a typical, small installation project. These projects generally take 16 weeks; ours ended up at 17 months. This miss-categorization set unreasonable expectations and incorrect staffing. The roles assigned “project manager”, or “business analyst” have a completely different meaning for a 16 week boiler plate project than they do for a 17 month implementation. It took us a while to discover this, understand and adapt. Even as we end this, no one person speaks for the project, fortunately we all speak with one voice – more or less.
Lastly, competition for resources was a constant problem. Only one person was full time on the project up until about 3 months ago when the full-time staff doubled to two people! This excludes IT development staff who were often full time for short periods according to the development schedule. In most cases, we would get a statement of general support without specific date and effort commitments. Then, when needed the people were able to only dedicate a portion of their time, extending the deliverables. Fact is we did not account for that. Maybe that is more the problem than the unavailability. Seems we did not learn from this and plan accordingly. We didn’t do that. We didn’t because it was too hard to get everyone together and we were too busy “doing” the work to take time to plan it. OK – we knew that was wrong, but we accepted it as better than nothing. The error was that we did not add this as a risk and raise awareness to the “powers that be.” I’m starting to feel pretty stupid; I seem to have mistaken some progress for good progress. Isn’t any progress good? Isn’t there a quote that says something like: good is the enemy of great? I’m not feeling so great right now.
Week 23 (Building a PMO) - Lessons Learned?
Well, one of the major deliverables for one of our customers has arrived – we are going live on 3/1! As of this writing, it really looks like we will make it, and with quite a few reasons to be proud. We will be implementing a considerable part of what we planned, and in some cases, a little extra. Of course since we had no real success criteria, the idea of a successful implementation is not applicable. How can you succeed if you don’t know what success is? I’ll get to that another time… Today – lessons learned.
First, I am an advocate of learning lessons at all times during the project and recording them as they occur, something that I did with this one. My reasoning is that we tend to forget over time, so waiting until the end of the project may result in lost lessons. Also, after a project is completed, we all have a tendency to paint a slightly rosier than real picture of what happened. The aura of success (or even just getting the darn thing over with) can create a euphoria that makes things look - not so bad.
The reason I added the question mark to the title is reflective of my skepticism that we are actually learning here. I propose that a well-run project will have lessons learned that relate ONLY to the parts of the project that were new. The other parts, I expect we would have learned from already. Now, that is not to say that continuous improvement is not possible, but rather that the “lessons” from continuous improvement are a different order of magnitude than those from the newer parts of the project. That is – if you have been learning in the first place! I think we are learning a little, but not as well as we could. One of the jobs of a PMO is codify or ingrain these lessons into the culture and processes of the organization. This way we can collectively and consistently learn these lessons rather than learning them individually and unpredictably.
So here are some lessons learned form the most recent project in our current program – how many of these do you already know?
1. The people we had were great; there just weren’t enough of them.
2. We left management and planning unattended for too long.
3. Unclear roles and responsibilities led to confusion and loss of precious time.
4. We had the most success when we were all informed.
5. Once engaged and informed, management responded quickly and helpfully.
6. We did things right, wrong, and mostly late.
7. We were slowed by constant competition for resources.
8. A great customer relationship got us through many challenges
9. We often did not have the tools and skills needed to do the best job.
10. We did not have a clear understanding of the work when we estimated.
I am sure every one of you can relate to these lessons. These were not all the lessons, but these are the ones I think we already knew. Yet somehow we did not learn from them in the past. Why? I think I will break these down a little over the next few weeks and look at them – surely there is a reason, or reasons. Hmmmm.
First, I am an advocate of learning lessons at all times during the project and recording them as they occur, something that I did with this one. My reasoning is that we tend to forget over time, so waiting until the end of the project may result in lost lessons. Also, after a project is completed, we all have a tendency to paint a slightly rosier than real picture of what happened. The aura of success (or even just getting the darn thing over with) can create a euphoria that makes things look - not so bad.
The reason I added the question mark to the title is reflective of my skepticism that we are actually learning here. I propose that a well-run project will have lessons learned that relate ONLY to the parts of the project that were new. The other parts, I expect we would have learned from already. Now, that is not to say that continuous improvement is not possible, but rather that the “lessons” from continuous improvement are a different order of magnitude than those from the newer parts of the project. That is – if you have been learning in the first place! I think we are learning a little, but not as well as we could. One of the jobs of a PMO is codify or ingrain these lessons into the culture and processes of the organization. This way we can collectively and consistently learn these lessons rather than learning them individually and unpredictably.
So here are some lessons learned form the most recent project in our current program – how many of these do you already know?
1. The people we had were great; there just weren’t enough of them.
2. We left management and planning unattended for too long.
3. Unclear roles and responsibilities led to confusion and loss of precious time.
4. We had the most success when we were all informed.
5. Once engaged and informed, management responded quickly and helpfully.
6. We did things right, wrong, and mostly late.
7. We were slowed by constant competition for resources.
8. A great customer relationship got us through many challenges
9. We often did not have the tools and skills needed to do the best job.
10. We did not have a clear understanding of the work when we estimated.
I am sure every one of you can relate to these lessons. These were not all the lessons, but these are the ones I think we already knew. Yet somehow we did not learn from them in the past. Why? I think I will break these down a little over the next few weeks and look at them – surely there is a reason, or reasons. Hmmmm.
Saturday, February 03, 2007
Week 22 (Building a PMO) - POWER!!
Power – yes, power, it brings up all sorts of negative references – “Absolute power corrupts absolutely” being the most famous. Well power exists and it is used and misused every day, mostly misused or abused. I’ve recently been able to observe and better understand the workings of power. I’ve seen manipulation, abuse and absence. I want to talk about the absence of power as my current assignment has taught me a lot about that.
First, let me talk about the difference between power and influence. Influence is absolutely necessary and vital to everything we do. When you can use influence do so, use power only as a last resort. No matter what position you have, working jointly with someone and using your mutual respectful relationship to come to a decision is infinitely preferable to using power – EXCEPT – when you can’t agree, or there is not a relationship of mutual respect.
So therein lays the benefits (even necessity) of power. As hard as it is to believe, not every working relationship is one of mutual respect and cooperation – no news flash there! Now, I think the first job of all of us is to create that kind of relationship. Everyone benefits when these relationships exist, including the company and the stockholders. Therefore, it is inherent in your job as a manager to build and maintain these relationships and influence. But sometimes, things just have to get done. That is when power can be adeptly applied towards success. Where there is no power, there are problems.
Consultants have a unique perspective on power. We are ultimately powerless. Any perceived power is simply a very strong and widespread influence. Being the only expert in the room often gives the illusion of power but, as we have all seen, power trumps influence. Being powerless is a great motivator to learning about power – trust me on this one! One thing I am learning is that when power is not defined and understood by all, there is a level of chaos that is expensive and detrimental.
A project without ONE single project manager is a project at risk. The more project managers the more risk. This seems so obvious that you might wonder why I am saying this. Power and politics often create situations where there are multiple project managers. In my current assignment there are at least 3 projects managers on the two major projects. One could argue that there are as many as five on one of them. The organization started simply enough and the story goes something like this:
We have a project that will involve many different areas of the company – it’s important to all of us, so we want each area to assign one of their best people to the project (and part-time only, but that’s a later blog). Of course this usually means managers get assigned and usually some wrangling goes on where these people all end up being at the same organizational level (i.e. pay grade). So now we have 3 to 5 managers all with separate areas of control as the “appointed leaders” of their area. Here is where organizational culture comes in.
In most organizations territory is closely guarded, so each appointee has some mandate from their management to protect the interests of their group. There is also some tacit or actual agreement that each appointee will have “final say” or power over anything that impacts that area. See the problem? Makes you want to scream right. Believe it or not al this seems very logical from the point of view of those making these decisions. Well to my eyes, here is the 800 pound gorilla. THIS IS A PROJECT !!
This project must be impacting multiple organizations or we would not have involved them, so there will be many decisions that impact every organization involved and some of those will have to favor one over another. Since we now have a group of equals who are first dedicated to their organization, they will fight for the decision that is in their interest. This can lead to a plethora of wasteful activities. Imaging if these people are not working from a position of mutual respect and trust! That means a struggle at almost every decision – and projects have a lot of decisions!
One of the ideas of projects is to create something that is greater than the sum of its parts. With shared (and I use that term loosely) responsibility, each leader is looking out for their area and the picture of the project to them consists of “mine” and “not mine.” This creates several problems. Not everyone’s definitions of mine/not mine agree, so you have areas that several people feel they own (mine, mine); and those areas that no one owns (not mine, not mine). The only place where there is harmony is when something thinks they own something and everyone else considers that thing “not mine.”
Conflict arises when the views of the appointees do not agree. Obviously, if several of us think something is ours, a direct conflict over ownership and the power to decide ensues. If everyone thinks something is “not mine”, then we might all just drop it, or even better one of us might decide that that something is “yours” and YOU need to do something about it. Ah what fun that is! Try to get someone to work on something for which they have no sense of ownership! So begins the joyous practice of finger pointing and CYA that we all enjoy.
What a load of crap – all this because some people were more interested in having some power than in getting the work done for the company. Here a single, responsible person with power can save huge amounts of money and time and achieve success for everyone. Seems too many of us would rather lead in hell than be part of a winning team which I guess explains a lot of the working environments out there today.
I need to think of some way of creating a scenario or game that shows how ineffective this is … hmm.
First, let me talk about the difference between power and influence. Influence is absolutely necessary and vital to everything we do. When you can use influence do so, use power only as a last resort. No matter what position you have, working jointly with someone and using your mutual respectful relationship to come to a decision is infinitely preferable to using power – EXCEPT – when you can’t agree, or there is not a relationship of mutual respect.
So therein lays the benefits (even necessity) of power. As hard as it is to believe, not every working relationship is one of mutual respect and cooperation – no news flash there! Now, I think the first job of all of us is to create that kind of relationship. Everyone benefits when these relationships exist, including the company and the stockholders. Therefore, it is inherent in your job as a manager to build and maintain these relationships and influence. But sometimes, things just have to get done. That is when power can be adeptly applied towards success. Where there is no power, there are problems.
Consultants have a unique perspective on power. We are ultimately powerless. Any perceived power is simply a very strong and widespread influence. Being the only expert in the room often gives the illusion of power but, as we have all seen, power trumps influence. Being powerless is a great motivator to learning about power – trust me on this one! One thing I am learning is that when power is not defined and understood by all, there is a level of chaos that is expensive and detrimental.
A project without ONE single project manager is a project at risk. The more project managers the more risk. This seems so obvious that you might wonder why I am saying this. Power and politics often create situations where there are multiple project managers. In my current assignment there are at least 3 projects managers on the two major projects. One could argue that there are as many as five on one of them. The organization started simply enough and the story goes something like this:
We have a project that will involve many different areas of the company – it’s important to all of us, so we want each area to assign one of their best people to the project (and part-time only, but that’s a later blog). Of course this usually means managers get assigned and usually some wrangling goes on where these people all end up being at the same organizational level (i.e. pay grade). So now we have 3 to 5 managers all with separate areas of control as the “appointed leaders” of their area. Here is where organizational culture comes in.
In most organizations territory is closely guarded, so each appointee has some mandate from their management to protect the interests of their group. There is also some tacit or actual agreement that each appointee will have “final say” or power over anything that impacts that area. See the problem? Makes you want to scream right. Believe it or not al this seems very logical from the point of view of those making these decisions. Well to my eyes, here is the 800 pound gorilla. THIS IS A PROJECT !!
This project must be impacting multiple organizations or we would not have involved them, so there will be many decisions that impact every organization involved and some of those will have to favor one over another. Since we now have a group of equals who are first dedicated to their organization, they will fight for the decision that is in their interest. This can lead to a plethora of wasteful activities. Imaging if these people are not working from a position of mutual respect and trust! That means a struggle at almost every decision – and projects have a lot of decisions!
One of the ideas of projects is to create something that is greater than the sum of its parts. With shared (and I use that term loosely) responsibility, each leader is looking out for their area and the picture of the project to them consists of “mine” and “not mine.” This creates several problems. Not everyone’s definitions of mine/not mine agree, so you have areas that several people feel they own (mine, mine); and those areas that no one owns (not mine, not mine). The only place where there is harmony is when something thinks they own something and everyone else considers that thing “not mine.”
Conflict arises when the views of the appointees do not agree. Obviously, if several of us think something is ours, a direct conflict over ownership and the power to decide ensues. If everyone thinks something is “not mine”, then we might all just drop it, or even better one of us might decide that that something is “yours” and YOU need to do something about it. Ah what fun that is! Try to get someone to work on something for which they have no sense of ownership! So begins the joyous practice of finger pointing and CYA that we all enjoy.
What a load of crap – all this because some people were more interested in having some power than in getting the work done for the company. Here a single, responsible person with power can save huge amounts of money and time and achieve success for everyone. Seems too many of us would rather lead in hell than be part of a winning team which I guess explains a lot of the working environments out there today.
I need to think of some way of creating a scenario or game that shows how ineffective this is … hmm.
Subscribe to:
Posts (Atom)
