Tools Aren't Process, But Process Is A Tool
Scheduling apps and project scheduling tools don't equate to project management. As a consultant, I've lost count of the number of times clients have approached me with the misconception that mastering a scheduling app or tool is all they need for effective project management. They often say, “We need project management. Can you teach us how to use this scheduling app?” If I had a dollar for every time I heard that, I could retire from consulting. The reality is that scheduling apps and project scheduling tools are merely facilitators—they enable you to ‘do' project management in much the same way that a word processor enables you to ‘do' English. True project management requires much more than just proficiency with tools; it involves a comprehensive understanding of planning, execution, monitoring, and control.
To successfully use a word processor requires a number of skills. Familiarity with a computer and its operating system is a given. An understanding of the principles of the program, and what buttons do what, also has value. More important, though, is the understanding of the principles of words on a page, and the thought process behind creating them. Which means that the fundamental principles of English are essential: grasping paragraph and sentence structure, intuiting subject and object agreement, and knowing not to split your infinitives (the Oxford dictionary notwithstanding) is a fundamental pre-requisite in successfully using a word processor.
Fortunately for Microsoft et al, the majority of people that purchase their word processors have been trained in the nuances of the English language since Kindergarten or earlier. The appreciation of the printed word is innate, as is the metaphor of word processor as electronic typewriter. When someone fires up their brand new word processor, they're way ahead of the game conceptually; familiarity is a technical exercise of understanding the buttons, not the concepts.
Unfortunately, our ready understanding of the concepts of word processors, spreadsheets and the like create an unreasonable expectation around the use and usability of project management tools. In point of fact, project management software is itself a misnomer. The tool that can manage a project doesn't exist, although there is an extensive array of project administration tools available.
What is important to understand here is the distinction between tools and process: process is how you accomplish your goals; the tools just make it easier. While the process of travel will tell you how to get from point A to point B, a car simply becomes a much more efficient tool than your feet in getting there. But the car can't travel on its own; it needs someone to guide it who understands the process, the goal and the desired outcome.
The promise of automation is not that computers will do our work for us; it is that computers will allow us to do our work faster, more efficiently and more accurately. We are still integral to the process. The best project managers are those that understand the process of project management well enough that they can execute it with no automated support whatsoever. Which isn't to say you would want to, necessarily; it just isn't efficient. But if you don't understand the process you are trying to execute, there is no amount of automation that can help you get there from here.
Project software is designed to make administration easy. It cannot make management decisions; it will not be able to decide the appropriate duration or effort for an activity, who the must appropriate resource to perform the activity is, which other activities should proceed it, or even if the activity belongs as a part of the project. These are decisions that are made by the project manager without the benefit of automation assistance. Once you have established all of these criteria, however, the software makes it incredibly easy to adjust to changes. And the one truth of project management is that things will change.
Success in project management, therefore, is not a question of having the best – or even the latest – tool. The toolset you use should be a secondary consideration, and one that is made long after you have developed a familiarity and understanding of how you work as a project manager.
Choosing project management software before you have developed and established your process will not solve your problems. In fact, it will create more problems – the reality of software creates the illusion of process, which simply heightens expectations around results. Organizations and project managers need to think long and hard about how they are going to manage – individually and collectively – and what they need in order to establish that base capability before a software package can even begin to be of assistance.
Once you can write, you can use a word processor. Knowing how to use a word processor, however, doesn't mean that you can write effectively. The same principle is even more true for project management.
After all, software doesn't manage people; people manage people.
Hi
I love the analogy you use about Word Processors. It is very good. When I teach Project Management, I have a brief section defining the differences (as PMBOK outlines them) between Methodology, Tool, Technique and Process.
A Methodology is a framework.
A Process is a set of tasks where someone/something uses a tool, technique and or skill to accomplish.
Project Mangement for example can be defined as, "the application of knowledge, skills, tools, and technique to project activities to meet the project requirements." And I most definitely agree that Project Management is not and never will be a "form filling out job." I've seen a number of formal Project Management Offices that believe if they have a good Project Management Methodology - and each and every form is completed, the project will be successful.
And I firmly agree that a Project Plan is much more than a Gantt Chart or a schedule.
Methodologies -- which abound in large numbers -- are a framework in which to work, not a solution.
I usually tell students that a Skill employes a techniqe using a tool where the tool's usage is part of a procedure that is part of a process that is part of a method.
Another analogy is Accounting -- every wonder why in Account 101 classes you have to learn how to manually post things? So you can learn the underlying process that all Accounting Software Packages use.
Finally -- a favorite quote of mine (I have no idea where it originated) "A fool with a tool is still a fool."
These are all very good points. And I'd like to add that, no matter how helpful a tool is at easing project management, it won't save time unless all team members are using it, and it can't be collaborative unless it's easy enough for non-certified project management specialists to use. With one of my clients I've used Project Insight (www.projectinsight.net) and found it bridges that gap between the PMI and PMP types and the regular project staff.