One of the most important aspects of the project manager’s role is the use and application of tools in performing the job.  Wikipedia has an interesting definition of the word tool.  It defines it as follows:

A tool is a device that can be used to produce or achieve something, but that is not consumed in the process. Colloquially a tool can also be a procedure or process used for a specific purpose. Tools that are used in particular fields or activities may have different designations such as instrument, utensil, implement, machine, apparatus.

When I first entered the profession, I spent a huge amount of time learning about tools and looking for tools to help me better do my job.  This ranged from finding good templates to implementing automation for project selection.

I suspect that I was not in a unique position, as most new entrants to the profession encounter the same issues with trying to apply the principles found in the PMBOK Guide.  This is certainly not because the PMBOK Guide is lacking but rather because the experience level of the individual, as was the case with me at the time, is not high enough to enable them to use their knowledge to build their own tools.

As I progress in the profession, I find that my reliance on tools diminishes. However, that is not to say that I don’t have a general appreciation for automation tools that are aimed to make my life simpler.  After all, I have never had to manually calculate critical path, except when I did it for the PMP exam.  In fact, while most of us take for granted scheduling tools, only recently have software vendors started expanding their products to include other knowledge areas within the PMBOK Guide.   Many commercially available packages and custom-made products can now address areas such as scope management, risk, quality, and configuration just to name a few.

In reflecting on some of the development of PM tool automation along with the advancement of technology, there are some points that need to be taken into account.  I would consider them the golden rules of using automation:

  • A fool with a tool is just a fool
  • Garbage in equals garbage out
  • There is no need to over buy

To help better illustrate what I am talking about and how they are relevant, I will address each point separately.

Many years ago I was working in an organization that was introducing a new project management methodology along with tools to be applied across the enterprise.  We were meeting with some senior executives to generate the needed support to help in the implementation.  One executive stated that while he liked the new methodology we needed to remember that “a fool with a tool is just a fool.”  He further expanded that if we did not actually take into account the necessary training and practice that the PMs needed to become proficient with the new tools, we were not going to be successful.  Think about it this way.  If I gave you a notepad and a pen and asked you to write a novel would you be able to do so without the necessary training and skill to do so?  Similarly, if someone put me behind the controls of a jet plane, even though I consider myself intelligent, I would not be able to operate it.  Tools are there to support humans not to replace them.  The adoption of tools must take into consideration the complexity of transforming human behavior and details of organizational culture.

Another point that needs to be addressed is the data that goes into tools.  We are as good or as bad as the information that we have when it comes to decision making.  Consider, for example, an enterprise tool that helps portfolio management and organizational executives in selecting and prioritizing projects. If the team does not have access to relevant data or worse has the wrong data in the system, the tool will be rendered useless.  Several years ago I was involved in developing the business case for an automation tool in the marketing department of an organization.  As part of that effort, we were conducting process mapping and data collection to try to understand how the automation would save the organization money.  We were operating under the premise that the new tool would reduce the number of staff.  As we started adding up all the potential cost savings from the different departments, it became quickly apparent that there was something wrong.  The cost savings in total were greater than the current process.  Amazingly the net present value calculation looked great, but the system was fed with garbage.  What added insult to injury was the fact that the assumption of time savings was based on the fact that human resources would be reassigned to other departments.  After talking with stakeholders, we discovered that none of the department heads were willing to do that.

The third point I referred to is over buying or as some would call it “gold plating.”  The idea of gold plating goes back to the auto industry when manufacturing were introducing cars with gold-plated vanity hood ornaments.  The gold plating had no functional value but added to the cost of the car.  Let me use another example here.  If I needed to travel from New York to Chicago, I have a variety of options available.  Some of them may not be realistic such as walking or riding a bicycle.  On the other hand, some options such as taking the bus, riding the train, or flying all present viable options.  However, what truly matters when it comes to making a decision are the requirements that I’m presented with along with the constraints that I am facing.  For example, if I had to be in Chicago for a meeting the following day, it is most likely not reasonable to take the bus or train.  As such, flying is the only option.  If on the other hand, I am going to Chicago to see a friend and I have a limited budget, I may decide to drive.

What is important to understand is that tools have to not only meet the requirements of the given organization, but also be bound by the constraints that it faces.  Let me illustrate further using the airplane example.  Assuming that air travel to my destination is the best option, I still have to decide the method of air travel that is best for my needs.  I could fly on a commercial airline, fly my own plane (if I had one and I knew how to fly), or take a private jet.  While each of the above options will meet the requirement of getting to my destination quickly, not all will likely overcome a budgetary constraint as the cost of flying my own plan or taking a private jet is significantly greater than flying on a commercial airline.

Unfortunately I have seen many project management automation tool implementations that ignore the rules that I mentioned.  In particular they tend to over buy.  They forget to ask a simple question like “do I really need to automate this process or is it easier to do it manually.”

As I close this post, I will leave you with a final thought.  Would you buy a Boeing 747 for your daily commute if you live 2 miles away from work?  On the other hand, if you were the President of the US and you had a need to basically transport the White House with you when you went on a business trip, a 747 is the rational choice for your travel.