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

24 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!


The Pilot Project Team and Mission

Now I’ll backtrack a bit to focus on the pilot project team members and their mission. I’m assuming that you’ll eventually be implementing your new software, so you might as well run your pilot project in a way that will allow you to learn as much as you can so eventual implementation will be easier.

First comes the question of who should be on the pilot project team. You'll need to pick your best and brightest — the users who are eager to learn. In addition, you'll want a responsive IT representative on the team.

Why are these choices important? Because these are the people who will give you the best chance for success during the pilot project. Also, they'll help you communicate with, train, and assist other users as they learn the new tool later on. Another reason is that you’ll be able to say, “It took us six weeks to figure this software out — and that was with our best users!”

Next, there is the question of the pilot project team's mission:

  • To execute a real-world project using the new software.
  • To collect information about how to best learn, standardize, and use the software.
  • To verify that client requirements can be met.

By clearly defining the mission, you can tell your management that you didn’t just do some trivial little test. Instead, you verified that the software can actually deliver what clients expect while gaining a realistic understanding of IT and training expenses.

Note: For more detailed information about how to create a sustainable system in your company to use pilot projects to your advantage, see my two-part series explaining how to "Build a CAD Proving Ground."

Ending Tool Worship for Good

Using my pilot project and proving ground concepts, you should be able to rid your senior management teams of tool worship and artificially rosy expectations for once and for all. Here’s how.

After your pilot project is concluded and you’ve documented your findings, arrange a briefing session so you can report to your senior management. The key points to communicate are as follows:

  • There is no "Easy button"!
  • This will require effort. It can work, but it won’t just happen on its own.
  • This will require training and standardization — which management must fund.

As you have the conversation about new software and how it might be used in your organization, stress the human factors (training, ramp-up time, user hesitancy to change tools) rather than software features. You’re trying to make the point that the software tool will require effort to learn correctly, so keep the conversation on that topic as much as you can.

Wrapping Up

Throughout my career as a CAD manager, I’ve often had to deal with senior management staffs who thought that new CAD technology was somehow magic. But just as CAD didn’t automatically replace the drafting board, new CAD software can't replace your existing tools without time and effort.

As you strive to gather the resources necessary to implement new software the right way, I hope you find this discussion about eliminating tool worship useful. Until next time.

About the Author: Robert Green

Robert Green

Add comment

Note: Comments are moderated and will appear live after approval by the site moderator.

AutoCAD Tips!

Lynn Allen

Autodesk Technical Evangelist Lynn Allen guides you through a different AutoCAD feature in every edition of her popular "Circles and Lines" tutorial series. For even more AutoCAD how-to, check out Lynn's quick tips in the Cadalyst Video Gallery. Subscribe to Cadalyst's free Tips & Tools Weekly e-newsletter and we'll notify you every time a new video tip is published. All exclusively from Cadalyst!
Follow Lynn on Twitter Follow Lynn on Twitter

At your company, who has the most say in CAD-related software purchasing?
CAD manager
CAD users
IT personnel
vice-president/department manager
CEO/company owner
Submit Vote