March 3 issue of eWeek - Jim Rapoza's article on PM software

In the March 3 issue of eWeek, Jim Rapoza reviews some SAAS project management software, and states that "over the years, we've seem many interesting applications that have attempted to bring new methods and processes to project management..." There's more to his introductory generalizations, and I think Jim's point is that MS Project has been so dominant that not much innovation has been successful in the PM software arena.

The article prompted me to e-mail Jim, and to post here and elsewhere on one of my favorite soapboxes: Process before tools. As practitioner and academic in the PM field, I must again state to all that project management starts with development of good and repeatable process and then looks for the appropriate tools to automate and streamline a good process.

A good PM can excellently manage projects with a whiteboard and an abacus. Most PMs I know still consider Excel to be the ultimate PM tool. Many, many people make the mistake of thinking that because they have selected and implemented MS Project (or some other PM software) they are "doing project management."

My point - the article seems to infer that new PM software applications should drive change in the way projects are managed - not so. Good project management practices are independent of software. The software selected should support a PM specialization/practice area or organization's successful processes, not determine or drive them.

Jim's article talks about how one of the new programs (LiquidPlanner, which I really like the look of) addresses project management's general intolerance for uncertainty despite constant experience that the dates and estimates we PMs give with such confidence are in fact given with varying degrees of uncertainty. This is not by choice.

Project management does not generally tolerate uncertainty because the people paying for projects do not tolerate it. The key here is that there are process efforts in place, especially around software development planning, scheduling and control, that emphasize experiential estimating. These new tools seem to support this, but development of good process is still king.

Once project sponsors learn to accept some inherent uncertainty and PM processes evolve to manage and communicate this effectively, then the software can help support and streamline the management process. Software cannot and should not drive the way projects are managed.