I was thinking about how many projects I have been part of, how many project plans I made, and how many of them actually succeeded.  I could not think of any that were as planned - on time and budget, no matter how good the tools I used were. There is an old saying "Man plans, and God Laughs."  How true, how true!        

Sometimes missing a deadline in a project has a cascading effect. You're late, then the next guy is late and so on and so on, until the last guy is way late and you have blown your budget and timeline.  It seems to me that most of the project planning tools are based on 1950's project technology, and here we are in the new millennium and the number of projects that seem to be on time and on budget has not gotten any better.  This leads me to believe there are several problems here that have either broken the tools we use, or that our assumptions about projects are incorrect.

Incorrect Assumptions

When project tools were first built they were for professional project managers who used to do it all with paper and pencil, so moving up to the computer was a big step up.  However, I think we lost something in this step up, and that was people.  When the professional project manager managed a project by hand, he knew everyone on the project and interacted with them (usually face to face or on the telephone) on a daily basis to make sure things were on track.  When moving to the computer we made recording things more efficient, but took the "social" aspects of project management out of the equation.  I think that was our first mistake.

Our second mistake was that most of these tools were built for the professional project manager, and today most of the people that use project management tools are not professional project managers. So the right tool for the problem (project management) but for the wrong population.

Our third mistake was in estimating tasks and time.  When working with MS Project (which is the most popular tool today) you can estimate the times for tasks and based on all the tasks, resources and time estimates MS Project will tell you that Thursday February 23^th at 2:00 you should be complete with the project.  If you are an experienced project manager you always include a "fudge factor" of about 10%, which takes you to March 1, which is when you tell your boss the project will be done. But low and behold, it is April 1 (fool's day) and the project still is not done.  You have a black eye, your boss is pissed at you, and you walk around shaking your head wondering how this could have happened.

I think the misassumption that happened here was in the estimates.  By applying the "fudge factor" you gave everyone's estimate about 10% slippage.  However, as talked about earlier, slippages tend to compound especially if one task is dependent on the ones before to get started.  The second part of this issue is estimating itself.  In my case if I give a date (and do my best to meet it), it is a best guess on my part, and because life is in itself an uncertain process, the best I can do is guess.  Being an optimist, I usually tend to guess low, and a million little things conspire to help me miss my due date.  If there is more than one optimist on your project you can be in deep... you know what!  So how do we estimate better?  Do we just say the fudge factor is 25% instead of 10%?  Well, having tried that, I can tell you it does not seem to work much better, as some people do their tasks early and others do them late, and having one number for everyone seems counter intuitive.  Also, not every project is going to have the same degree of complexity or lateness.  As a rule of thumb it might be fine, but to give your boss any accuracy on when the project will be done, it is no better than the applied fudge factor technique.

What if I ask everyone to give me a + or - for their estimate for every task.  Good idea, but could be quite an onerous processes, and you still have the problem of some people guessing low while others guess high.  I have not worked out a good way for estimating yet, but know that this area is an opportunity for project management vendors.

The final assumption is one around features and complexity.  This is usually an assumption made by the project management vendor which I call "engineeritis" and usually can be summed up as "the more features the better."  Our research shows that this is not true. As a matter of fact, just the opposite is true, when we have done surveys on the functionality of collaborative software. Ease of use has come up as the number one biggest issue for success of adoption of the technology.  What this means for  software vendors is that they have to get the 80% of the functions that everyone wants and needs, and do those well and in an easy to use way, and not fall into the trap of adding the other 20% (bells and whistles) that most people don't need, but a few vocal ones will ask for.  It is a tough balance to hit. 

In earlier blogs I have recognized 37 Signals for their Backpack and Basecamp products, noting the many hundreds of thousands of users they have.  But in digging a bit deeper and interviewing some of those that are using these tools (which really are task management rather than project management) I found that they were good initially for small projects or small companies with many small projects, but as soon as either a larger company was involved or the complexity of the project demanded more than these simple tools could provide, then the users often moved to other online project management services like Clarizen. These on-demand solutions not only provided more functionality, but kept to the ease-of-use mantra, and were able to avoid "engineeritis."

Putting the "Social" into Project Management

Given all these pitfalls and misassumptions it is amazing that we get anything done. Today we are besieged by a wide variety of new tools that support Web 2.0 characteristics, and this is fine for the consumer (who is adopting these tools quickly), but the enterprise is not.  Maybe because the enterprise is more social, and the social networking tools of Web 2.0 are not secure enough for the enterprise yet? But as these tools become more popular in the enterprise, those doing project management will begin to realize that they need to put the "social" back into project management and will begin to look for tools that actually support this.  For example, why is it so hard to find a project management tool that supports IM/Chat? It seems like a no-brainer to me, and clearly could cut down cycle time for communications about tasks in a project (which can often be 80% of a task duration) and ultimately decrease the project cycle time.  However, when asking a number of DPM (distributed project management) vendors about this over the last year, their response was "none of our customers asked for it."

To that I have two responses: 

1. "You can't drive a car by looking in your rear view mirror."
2. "Your customers don't know what they don't know."