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!

[More:]

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 initially built for professional project managers who used to do it all with paper and pencil, so moving up to the computer ( int he 70's) 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 big 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 we had the right tool for the problem (project management), but for the wrong population.

In My Estimation...

Our third mistake was in estimating tasks and time. When working with Microsoft 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 23th 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% (if working on software projects that is usually a 100% fudge factor), 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 a task is dependent on the ones before it 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 team you can be in deep… (you know what)! So how do we estimate better? Do we just say the fudge factor is 25% or 100% 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 a big 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 successful 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 tools) I found that they were good initially for small projects, small companies, or a small number of relativley simple projects,but as soon as either a larger company was involved or the complexity and number of the projects demanded more than these simple tools could provide, then the users often moved to other online project management services like Clarizen. These new Web 2.0 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 any projects done at all. Today we are besieged by a wide variety of new tools that support Web 2.0 characteristics/functionality, and this is fine for the consumer (who is adopting these tools quickly), but the enterprise does not seem to be adopting these tools at the same rate. Maybe because the enterprise is more focused on acountability and security, 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.”

For software vendors, especially vendors of project management tools this is a delicate balance, but if you are able to strike the right balance, there can be huge rewards for all involved.

Key words: project management, social networking, distributed project management, project estimation, collaboration, Web 2.0, IM, Chat, Microsoft Project, Clarizen, 37 Signals, task management, time estimation, task duration, ease-of-use, Backpack, Basecamp, product roadmap.