Category: Workshop

This thought came up recently when one of my clients brought me in to do a map day. They already had a very detailed SOW (statement of work) that they had provided to the client. The SOW was almost a Work Breakdown Structure. How would this work?

In many of the map days I’ve been in, the teams have a broad idea of what they are supposed to build but not a detailed understanding of it. So we build the WBS/SOW on the fly.

In this case, we already had the SOW. This provided us with the opportunity to do a tremendous amount of pre-work. I took the SOW, populated the deliverables matrix with it, came up with abbreviations and pre-printed the Post Its with the information. What I lacked was owners and users and, in most cases, any kind of dates.

Using these pre-printed Post Its, I led the discussion. We focused on the first year to make sure we could meet the commitment for the first year. Lo and behold, we were done in about 1/2 of the time that it usually takes for a map day! In this case I would call it a map 1/2 day! We did find some items in the SOW that were not deliverables; we found a few things that were missing, but not much.

The one question was handling the higher levels of the SOW. My first approach was not to plot them but then I realized that people need the grouping to get a better picture of how things fit together and their timing. We needed to watch out for putting dates on higher levels that were not supported by the lower levels but this became obvious.

Once we had this information, I updated the spreadsheet and immediately had a tracking tool. Because of contract requirements, I exported the matrix to MS Project.

So, next time you have a map day, check to see if there’s a WBS or a SOW available. It will save a lot of time and your team will appreciate it. But to answer the title’s question, you do need a map day. Maybe a 1/2 if you are lucky!

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.

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.