My grandfather used to say: “A bad workman always blames his tools.” His words came back to me recently when I was asked to evaluate a number of commercial software applications on behalf of a client company.
It occurred to me that no one has done any kind of independent evaluation of the various project management programs that my company uses in-house. We've been routinely upgrading our PM programs without really thinking about whether our company needs to invest in new software or simply sharpen our old tools. This is all the more absurd, given that software evaluation and development is our professional mainstay. Without evaluating your current PM software and considering new solutions, you run the risk of becoming stuck in the rut of using only comfortable and familiar tools.
Breaking out of the box
We've carefully considered and invested in appropriate integrated development environments (IDEs), along with tech support for business management and communications. So why have we continually overlooked this aspect of our own toolbox?
I suspect many of you can relate to our reasons. There's always a shortage of time for tasks outside the software projects' day-to-day strategy. It’s just too irritating to bother fixing something that doesn't appear to be broken, and it appears to be comparably affordable.
As a project manager, you may have developed an allegiance to one particular project management tool. This kind of affiliation often spreads throughout an organization, even becoming "policy" without much reasoning to back it up.
There are always costs and short-term headaches associated with any type of change. If it has taken you two years to get everyone comfortable with "Project-o-matic version 3.5.1," you might not be keen to make a shift now. You may even believe that a particular choice of project management tools doesn’t really make a huge difference anyway. They're really just an aid for bookkeeping and communication, so why make a switch?
Beware of the pace of change
Development practices are now being challenged by the open source movement and by alternative project management methodologies. Any organization or project manager that fails to stay alert to the possibilities can become a victim of the pace of change.
Adding "features" to the increasingly complex tools we use doesn’t often bring corresponding benefits. Many of these features are even redundant. Also, the frequency of genuine upgrades is low, yet license costs remain high.
Implications of changing tools
Of course, I'm not advocating that you change tools simply for the sake of change. PM tools are too important to adopt or get rid of based on trends. Even if certain new approaches become popular, it doesn't mean you have to start jumping on every passing bandwagon.
Widely used, plain-vanilla packages tend to be higher quality and facilitate migrations/upgrades. The technology is likely mature, and the vendor probably isn't going to fold in the short term.
On the other hand, your longer-term career development requires that you get some experience on the latest tools. It’s always a good idea to be experimenting "offline" with new techniques.
It's possible that my reliance on staples such as TimeWizard, Primavera, Welcom, and Microsoft Project is selling my projects short. You might even want to consider a customized version or a built-from-scratch tool. At the very least, it makes sense to evaluate demonstrator copies of tools you haven’t used.
You probably don't know how much ownership of your existing PM tool actually costs. On top of licensing costs, you should also consider the value of the time it takes to set up a new project, to interface it to your staff diary, and so on. Also, don’t forget that every upgrade you sign for has an implication in terms of training, hardware demand, operating system requirements, user support contracts, etc. For instance, do you really need a multimedia presentation facility as part of your project planning system? My grandfather would call that using a sledgehammer to crack a nut.
Free (and almost free) PM tools
Individuals can now customize their tool configuration so that the savings achieved by everyone in the company using the same tool are sometimes diminished. Team members who use a custom view may have difficulty understanding someone else's custom view. Agile project management advocates the use of nothing more than postcards and whiteboards. You should also spend some time reviewing free (and nearly free) tools for project management. (Shelley Doll has started the process for you in this article.)
However, sometimes it's necessary, and even considered a virtue, to soldier on and deliver despite "worn-out tools." But there's no benefit in doing this blindly. Evaluation techniques for any other software should be applied on roughly an annual basis to the in-house standard tool. If you have a good relationship with your tool vendor, you can ask the vendor to include or exclude features, based on your experience.
The bottom line is: Don’t live with the project management tools you’ve been given; they may be restricting your performance and even your career development.