I've been overwhelmed lately with life things - new job, new house, moving, packing, packing, packing, moving - resting from about killing myself since I am clearly not 20-years old any longer - or even 30 0r - oh well you get the idea.
So, my two new great projects are: Building a PMO - yes again - I love this - this one is for a public sector multi-million / multi-year program and subsequently the software organization that results from this!!
The other one is with the PMOSIG. We are working on a PMO Accord that will document lessons learned and best practices from PMO SIG members. This will be fantastic as it will be a collection of the knowledge from those who have walked the walk. No theory, just tried and true experience. Also there will be multiple perspectives on the same topics, maybe even some healthy disagreement. My job on this is part editor, part contributor and part coordinator / project manager.
So stay tuned. I'll be updating the blog on the progress of both of these!
Derry
Showing posts with label lessons learned. Show all posts
Showing posts with label lessons learned. Show all posts
Wednesday, October 03, 2007
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?
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?
Sunday, February 25, 2007
Week 25 (Building a PMO) - Lessons Learned? - Process
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 :-)
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 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.
Subscribe to:
Posts (Atom)
