Don't Get Caught in the Tool Worship Trap, Part 2

23 Apr, 2013 By: Robert Green

In your discussions with upper management, don't get distracted by the new software's appealing features — focus on how it will impact users and processes.

In the previous edition of the CAD Manager’s Newsletter, I pondered why so many upper management teams think that new CAD tools will solve all their problems like a magic elixir. I also offered some suggestions about how to overcome the psychology of tool worship using what I call "mission logic": focusing on the specific business objective that the new software will help your company overcome. If you haven’t had a chance to read through that column, I suggest that you do so now to have the proper context for this discussion.

In this edition, we’ll complete our examination of tool worship and I’ll provide more guidance about how you can logically address other key software implementation functions including IT, training, user team organization, and project execution. Here goes.

Before Anything Else: The Pilot Project

It stands to reason that it is easier to implement a new piece of software with a few users than with many. Before rolling out software to the entire company, I always prefer to investigate how a new piece of software will perform by crafting a well-defined pilot project.

What sort of information do I aim to capture with this pilot project? At minimum, the following:

  • How do my pilot team users like the software?
  • Is the pilot team able to use the software effectively?
  • How much training time does it take to learn the software?
  • Can the pilot team deliver a final design with the software?
  • Did the new software disrupt existing work processes?
  • How long did all this take us?

When I start putting together a pilot project, my management often asks me, “Why should we bother with a pilot project? Shouldn’t this new software just work?” My response is always, “Well, if there are problems, wouldn’t we rather find them on a small job that impacts only a few users?”

There have been a few times where I’ve been pressured into implementing a new software tool to a broad audience without a pilot project — and I’ve always come to regret it!

What Did You Learn?

Armed with what you learned from the pilot project, you can now provide a synopsis that might look something like this:

  • Our pilot team has completed a six-week project using the new software.
  • We had to coordinate software installation with IT to install required server components.
  • It took pilot team members two days of training to get started.
  • We were able to deliver a completed project after working our way around several problems.
  • The new software forced us to rework our 2D/PDF file output processes from existing project standards. We estimate that dealing with these problems caused most of the delays in our six-week time frame.
  • Ultimately, the software will be useable, given the right training and changes to our standards processes.

What becomes obvious to anyone reading the summary is as follows:

  • The software didn’t install itself.
  • The users required training to learn the software.
  • The software was disruptive to existing processes.
  • The project did not get done overnight.

If this doesn’t negate the tool worship associated with new software, nothing will. In my experience, this is exactly how companies become aware of how expensive new software really is!

1 2 

About the Author: Robert Green

Robert Green

Add comment