We need both the tools and techniques of project management and the skills, attributes, etc. of leadership. I’ve been working with one client. They have an excellent team but are not “performing” yet. This is typical of teams put together in an organization. They are still forming yet they are expected to perform. This challenge requires more leadership than project management skills as the question is how to get the team to quickly jell and move into the performing realm.
We’ve agreed that I’ll do a workshop on teamwork, one based on Patrick Lencioni’s Five Dysfunctions of a Team. This will be a great start although it won’t solve everything as the leaders need to be cognizant of their actions and expectations to support the improved team performance.
Most organizations take for granted that once a project is authorized it should be running at full speed immediately. Reality is that it takes time to figure out what to do, staff up, get the team to perform, and then get to a good situation. What are your experiences?
The May 25th, 2009 issue of Business Week’s cover story was about a new book by Jim Collins, author of Good to Great, on how a number of the companies that he and his team had followed in Good to Great had fallen from their high perches.
Collin’s new book, How the Might Fall, describes the stages of decline he and his team discovered:
Hubris born of success
Undisciplined Pursuit of More
Denial of Risk & Peril
Grasping for salvation
Capitulation to irrelevance or death
Very interesting reading but what does this have to do with project management? Well, as PMs we need to be cognizant of the business and understand how our efforts can help or hurt the business grow and stay alive. We should expand our reading beyond pure PM materials. I’m ordering my copy of How the Mighty Fall right now. If you haven’t read Good to Great, I recommend you do.
I’ve scheduled two CBPM, one in Durham, NC on May 29 and one in Santa Clara, CA on June 12. While setting up the workshops was not easy, marketing them has been more of a challenge.
For various reasons I cannot use PMI chapters to market the sessions, at least not for now (yes, I’m working on that). So, I’ve relied on emails and social networking sites to get the word out. The jury is out as to how well these approaches will work vs. using PMI chapters. I’ve also communicated with prior attendees who may have co-workers who are interested.
I guess I’m hitting the typical challenges of most startups: you have a great idea but trying to get the word out is a challenge. Thoughts? Suggestions welcome!
I’m working to schedule a “Project Acceleration through Commitment-Based Project Management” in May in the Raleigh/Durham, NC area. This class, which I’ve delivered already three times in California, has received outstanding reviews each time. The goal is to have the participants leave being able to run their projects using CBPM. More details to follow in my web site at http://www.pmlead.com.
I continue working with my client. We had to do a reset on their project due to issues outside the project that impacted their availability. Good progress is being made and resets do work when necessary. It is not necessary to run a full map day to do it. Instead, work through the deliverables matrix focusing on upcoming items and getting new commitments.
While it is not ideal to do a reset, sometimes it is the only way to bring reality into the project. Otherwise all deliverables will be late and the approach will have less of an impact — that is, being late will be the norm and the PM cannot leverage that tool to ensure progress.
Another item: just listened to a podcast on Agile project management and hear “we don’t use Gantt charts” in Agile. Sound familiar?
Let me know how it is going with your use of CBPM and what questions & suggestions you have.
It’s been a while since my last blog here, although I have a few in UC Santa Cruz Extensions. But today I wanted to give a brief update on the use of Commitment-Based Project Management, CBPM for short.
In January I presented the approach to a standing-room only audience at PMI Silicon Valley. There was tremendous interest and one of the attendees brought me into his company to consult and train on the approach. I visited in February, we ran a series of map days, and came up with a challenging but doable plan. Unfortunately, attention was taken off the effort due to other priorities and four weeks later, when they asked me to come again, things were late and we had to do a reset.
What this shows is that while coming up with a good plan is a great start, we all know that you have to stay on top of the effort or things will slip, regardless of how good the method is. I’m working with them to reset the plan and get the execution back on schedule.
In the meantime, I heard from one of the PMs who worked in my project with my prior employer and he’s been able to use CBPM successfully there, although he is forced to use MS Project to capture the plan and track the project. Don’t get me wrong, while I think MS Project can be overkill, it has some great features that are needed, such as the ability to capture dependencies. My spreadsheet allows the user to enter dependencies but it’s not the best approach. Something to mull about in my spare time on how to fix.
I have added Cost Performance Index and Schedule Performance Index calculations for Earned Value Management to the spreadsheet. Let me know if you are interested in this version. I’m still investigating how to automate it even more and I’m making some progress with VBA for Excel but that’s slow going.
The more work I do with projects, the more I realize that many PMs dont get it: the hardest part of project management is the soft part: the people skills. Most projects flounder not because the PM doesnt have the technical hard skills but because s/he doesnt have the soft skills.
Let me give you an example: I was asked to go help a project in which the customer was sending emails to senior VPs as to how messed up our organization was. He told his team to ignore us whenever possible. And it got worst from there.
So, I came in and started talking to the PM and the customer to get a sense of what was going on. Was the team not delivering? Well, they were, sort of, but promises had been made and not kept and the customer had not been informed before hand! Yes, you can argue with me, they didnt follow the communications plan (hard skill). But you should not have to have a communications plan that articulates each and every small activity to be successful. Use your common sense! If you are going to miss the deadline, dont wait until it happens. Tell the customer right away!
Once we started improving the communications, the storm calmed and things improved dramatically.
So, I was on the phone with David Schmaltz, author of The Blind Men and the Elephant yesterday discussing this situation. His experience, just like mine, is that most project failures are due to people issues. PMs focus on getting the plan developed (WBS, activity definition, activity sequencing, and on and on) while not worrying about the setting up a vision; making sure that the team knows where they are going, why it is important, and what is expected of them. Whats up?
My belief is that the soft skills are very hard and most people have trouble with them because they are hard to articulate. Yet weve been doing them all of our lives! As little kids we knew if our mother was upset without saying a word! Why cant we sense the same from our customers?
David is pulling together a group of similarly minded people. Hes started with a group in Facebook called ProjectCommunity (no space in between Project and Community) and has a site at http://www.projectcommunity.com. Come by and join in the discussion!
I just facilitated a map day for another project at my company. The project manager who requested my help insisted that he needed to collect start dates and durations for each deliverable so that he could build a critical path. By the way, duration for a deliverable is an oxymoron: a deliverable doesnt have duration. It is something that is built out of numerous tasks. The tasks that build the deliverable have durations. Commitment-based project management, which uses map days, relies on deliverables and individuals committing to deliver them by a certain date. It does not rely on task management.
That little technicality (deliverables don have duration) apart, theres a bigger issue. This map day was for a software development project. In my experience building a critical path for a project to any level of detail is an exercise in futility. Dont get me wrong. There is definitely a critical path. The problem is figuring out what it is in time to do anything about it. By the time you do, its changed!
Why is that? Well, software development is of an exploratory nature, not a deterministic nature. In many cases, what really needs to be done is not known until the effort starts and someone looks into it. Either that or spend an enormous amount of time analyzing and designing everything and run the risk that by the time you are ready the business has changed and no one needs what you build. Also, and sometimes more important, how long something will take will depend on the individual doing it. Studies have shown that some developers can be 10 times (yes, thats 10 times not 10%) more productive than other developers. So that fancy estimate done up front can be thrown out the window.
Every software development project is a custom project. While the tools and techniques are reused, the work to be done is customized. Theres no need to have the same deliverable built multiple times. Just copy it! This means that not two deliverables and their supporting tasks are the same. You can approximate using prior experience, experts, etc. but those estimates may be way off the mark. One of my early assignments as a consultant was to build an inventory report in COBOL (yes, Im a dinosaur). The manager estimated a whole week for me to do it. I did it in ½ a day! How! I used the COBOL Report Writer utility, something the manager was unaware of. Similarly, many other developers get creative in their work to move on to other work.
Finally, in most software development projects, the project manager knows the least about technology, tools, and methods. There is no way she could know as much. Her job is to plan and run the project not to spend time improving her coding skills.
The same is not true of deterministic projects, such as construction. It is well known how long it will take to pour concrete for a foundation and how long it will take to dry. And if you need two foundations, you need to do it twice. It is also well know what it will take to build a house and the order of steps. Construction projects are well defined. In these cases, building a critical path makes more sense (even then, construction projects are many times late, but thats another story).
Commitment-based Project Management relies on the individuals doing the work to make the commitments as to when they will be done. They use their experience and expertise to commit to a date that is more reliable than any estimate done in more traditional ways.
The job of the project manager is to monitor the completion of these deliverables on a regular basis and making sure that whenever theres a delay, the impact is understood and corrections made to bring the effort under control.
Different than the traditional PM approach? You bet. Practical? Yes. Effective? Most definitely. Give it a try. Contact us if you would like assistance. For further information, refer to Timm Esques No Surprises Project Management.
Im starting to see a few discussions about the role of leadership in project manager. For example, see Cinda Voeglis latest post. But this seems to be more the exception than the rule. Most of the commentary on PM revolves around the management aspects of the job.
As a PM who side-tracked into leadership development for about three years plus with lots of training at West Point and work with Scouts, I see leadership as a major force multiplier for any endeavor. Why is that?
A leader does many things but two key ones are communicating the vision and empowering the team to carry it out. In other words, heres what we have to do and I trust you to do it. Just let me know when you are done, if you need my help, or if you are having trouble. This approach is very different from traditional project management, where the PM constantly monitors all of the tasks and their status.
Can it work all the time? No, but neither does the traditional PM approach. We need to balance our approach based on the task to be carried out and the readiness of the follower. See Blanchards Situational Leadership II on how to apply it. Most followers are much more mature and ready to carry out an activity than we traditionally give them credit for. Give it a try!
By empowering the team and letting them know the objective the project leader gets off the middle of the road (a roadblock!) and lets the team perform. This is what I mean by a force multiplier!
CBPM (Commitment-Based Project Management) works because it empowers the team members. It allows them to commit to a date they can believe on not one the project manager made up.
This is the most important reason why it works, but there are other supporting reasons:
The plan is put together by the team, not by the PM or upper management.
The interdependencies become highly visible to everyone during the plan development process.
CBPM focuses on deliverables, not on tasks. The customer doesnt care about all of the work team members have to do to deliver an item. S/he only cares about the deliverables. In a similar fashion, team members only care about deliverables they need to be able to do their work, not all the other work that other team members have to do.
A deliverable is done or not done. None of this 80% done (which means that 80% of the effort remains, following the 80-20 rule). No grayness here. If theres disagreement, the customer of the deliverable has the final word.
Since the customer of a deliverable has the final say, this approach encourages the supplier of the deliverable to know what the customers want by communicating with them.
Its very clear who owns (the supplier) what deliverable in the matrix.
Its very clear who needs the deliverables (the customers).
Knowing who owns it and who needs it improves communications. The PM is not the keeper of the deliverable status. The suppliers and customers need to talk to each other.
Status is visible in the deliverables matrix. Its on time, late, or done. Red indicates late and no one likes their items being late.
The PAC (Performance Against Commitments) chart clearly indicates how well the team is doing.
Last Saturday, May 17th, I held a day-long Commitment-Based Project Management (CBPM) workshop in Mountain View at Symantecs facilities (thanks, Symantec!) We had 38 people in attendance and it was obvious the energy in the room as we discussed and role-played how to conduct a map day. At one point we were running almost two hours late (but we recovered)!
It is obvious to me that theres a need, a desire for an easier and more effective way to manage projects. Life as a PM is challenging enough without adding all of the details and paperwork that sometimes we think we have to deal with (or someone insists we have to deal with it!)
CBPM handles a lot of the details by putting the responsibility where it belongs: with the people doing the work. By empowering the team and trusting them but having the necessary verification tools (i.e., deliverables matrix and PAC) a PM can easily monitor a project and be successful without being overwhelmed and overloaded with details.
This was the third workshop Ive run (the two prior ones were at Symantec). Im working on scheduling future ones. PMI Silicon Valley is already discussing when we should have the next one. CornellUniversitys Johnson Graduate School of Management is also looking into their calendar to determine when we can run it. PMI Phoenix, San Francisco, and North Carolina have been approached. Do you want host a workshop in your company or group? Just let us know!