Dennis D. McDonald (ddmcd@outlook.com) is an independent consultant located in Alexandria Virginia. His services and capabilities are described here. Application areas include project, program, and data management; market assessment, digital strategy, and program planning; change and content management; social media; and, technology adoption. Follow him on Google+. He also publishes on CTOvision.com and aNewDomain.

When to Buy Project Management Tools?

by

Dennis D. McDonald, Ph.D.

I'm an Information Technology (IT) management consultant, also a project manager. I belong to the Project Management Institute (PMI).

I’m reviewing the PMI’s formal definitions for relating project management to concepts like portfolio management, program management, and process management. I understand these from my consulting and project experience but greatly admire the thought that has gone into defining these terms in the context of managing IT and other types of projects.

I’m also aware that there seems to be a growing number of software tools designed to support improved project management, to help with everything from developing an initial project justification to creating a software “dashboard” for reporting “key performance indicators” for measuring progress against business goals.

I’ve also come across a couple of instances recently where companies seem to have purchased such management tools BEFORE they have thought through all the business process changes that implementation of such tools can create.

Is this "buy tool first, change processes later" happening because managers know it's easier to buy software than change business processes? Or are people consciously using tool implementation projects to "drive" business process change?

Based on some online conversations with people I’m finding that starting with the tool in some situations may actually be a rational approach to creating organizational change, even if it does in the short term lead to some organizational flaps when people find they have to change their practices.

Where I was originally coming from is based on managing system integration projects. You wouldn't make a major change to a complex software application without planning for and thoroughly testing all the interfaces the application has to other systems. Shouldn't the same be true when implementing a tool for managing projects and processes -- planning for all the processes that will be impacted?

For example, if you wanted to make an enterprise wide shift and standardize on how corporate (not just IT) projects are managed and reported, you should understand what's involved in changing the processes related to the new project management system.

This seems intuitively obvious. What led to my original question was my wondering if some people may actually be purchasing certain types of management tools without a complete assessment of how much process change will be necessary in order to take full advantage of their benefits. In some cases that may be totally justified.

Another Question for Amazon about Copy Protected Music CD's

IFPI Publishes CD Piracy Report