Is it PM or Leadership that’s needed?

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.fivedysfunctions.jpg

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?

From “Good to Great” to Fallen

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:

  1. Hubris born of success
  2. Undisciplined Pursuit of More
  3. Denial of Risk & Peril
  4. Grasping for salvation
  5. Capitulation to irrelevance or death

Very interesting reading but what does this have to do with project management? Wehowthemightyfall.jpgll, 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.

CBPM Workshops and the Challenges of Marketing

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!

Continuing updates and upcoming workshop

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

pac.jpgI 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.

Update on Commitment-Based Project Management

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.

How are you using CBPM? Let us know!

It’s the People, St…d!

people.jpgUpdate: Read a related CIO magazine article: “Six Attributes of Successful Project Managers“.


The more work I do with projects, the more I realize that many PMs don’t get it: the hardest part of project management is the soft part: the people skills. Most projects flounder not because the PM doesn’t have the technical hard skills but because s/he doesn’t 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 didn’t 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, don’t 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. What’s 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 we’ve been doing them all of our lives! As little kids we knew if our mother was upset without saying a word! Why can’t we sense the same from our customers?


David is pulling together a group of similarly minded people. He’s started with a group in Facebook called ProjectCommunity (no space in between Project and Community) and has a site at Come by and join in the discussion!


As a bonus, my two basic rules of PM:

  1. Under promise and over deliver
  2. If you are going to slip, slip once and slip big.


Go out and have great projects!


Jose Solera, MBA, PMP

Why do we need a critical path? We don’t!


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 doesn’t 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, there’s 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. Don’t 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, it’s 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, that’s 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. There’s 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, I’m 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 that’s 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 there’s 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 Esque’s No Surprises Project Management.


Project Manager or Project Leader?

leader-1.jpgI’m starting to see a few discussions about the role of leadership in project manager. For example, see Cinda Voegli’s 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, “here’s 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 Blanchard’s 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!

What makes CBPM work?


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:

  1. The plan is put together by the team, not by the PM or upper management.
  2. The interdependencies become highly visible to everyone during the plan development process.
  3. CBPM focuses on deliverables, not on tasks. The customer doesn’t 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.
  4. 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 there’s disagreement, the “customer” of the deliverable has the final word.
  5. 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.
  6. It’s very clear who owns (the “supplier”) what deliverable in the matrix.
  7. It’s very clear who needs the deliverables (the “customers”).
  8. 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.
  9. Status is visible in the deliverables matrix. It’s on time, late, or done. Red indicates late and no one likes their items being late.
  10. The PAC (Performance Against Commitments) chart clearly indicates how well the team is doing.

What’s your experience with CBPM? Let us know.

Successful CBPM Workshop!

WorkshopLast Saturday, May 17th, I held a day-long Commitment-Based Project Management (CBPM) workshop in Mountain View at Symantec’s 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 there’s 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 I’ve run (the two prior ones were at Symantec). I’m working on scheduling future ones. PMI Silicon Valley is already discussing when we should have the next one. Cornell University’s 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!


Jose Solera, MBA, PMP