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.
