What Needs Fixing - Program or Process?

November 28th, 2010

The CAD Manager has to make choices all day long. Which task to work on first. What can be set aside and what must be done today. When to roll out software upgrades. How to fix someone’s problem. These choices often tend to fall into two categories: Program fixes and Process fixes.

Program fixes are software related and technical in nature. Technical fixes involve fixing things that are not working right. The other category is Process fixes. These are issue related to the way something is done.

Let's compare the concept of a problem with the functioning of a car. If the car were not running right, you would take it to a mechanic and get it fixed. Now if the car were not being operated correctly, the mechanic would not be able to fix the problem. Let's say that the brakes were constantly wearing out on the car. If they were faulty or cheap and wore out too quickly from normal use, then the fix is technical in nature and has to be addressed with a program change. For example, get new brake pads. Problem solved. If, on the other hand, the brakes wore out too soon because your teenager frequently made hard, abrupt stops, then the fix is adaptive in nature and has to be handled with a process change. For example, teach your teen to not grind on the brakes.

In his book Understanding the Process of Economic Change, Douglass North outlines the concept of adaptive change. He states “An adaptive change is one in which a group adapts its beliefs, rules, and strategies to its environment, either because the group has become aware that its environment has changed in some significant way, learned something new and significant about its situation, or entered into a new environment.”

Conceptually this is kind of abstract, but the practical side of it is that people change when something outside of them changes and they adapt to embrace that change. It could be a new process or tool, a new method of doing things, or a complete change of environment.

In an article by Ronald Heifetz and Marty Linsky on leadership, they define the technical change as being one that is corrected by applying a technical fix. Adaptive change is when the fix is done by adapting or changing behavior. They provided the car illustration as a way to make it easier to understand.

The CAD Manager moves between adaptive and technical corrections all the time. Knowing when to apply the right fix is key to their success.

When someone uses the software in the wrong way, then adaptive fixes are needed. When the software is not performing as advertised, then a technical fix is needed. Trying to distinguish the two is sometimes tricky.

Here is a scenario. The plotter is not plotting the file correctly. Lineweights are incorrect, screening is not working and the plot is off center. This could be a problem with the plotter, the file, or even the user. As you investigate you find that it is affecting only one project. A little more digging and you find that only a portion of the files on that project are affected. More digging and you find that only one person is having the problem. More digging and you find that the person is not using the correct plot style table; instead, he or she is using one created for a prior project. Is this a technical problem or an adaptive problem? Program or Process?

It seems to be process related. The person is not doing things the right way. If the CAD Manager had stopped searching for the problem type and just started gutting the plotter, then the manager would have been chasing the wrong leads and not gotten the problem fixed.

CAD Managers need to investigate until they can categorize the problem and then apply the fix. Technical fixes are easier to do than adaptive fixes. Fixing software or hardware is often easier than trying to get someone to change the way they do something. But we are called on to do both. We may tend to try a technical adjustment like changing or upgrading software when the end users are just using it the wrong way.

Don’t start fixing until you have diagnosed the problem. Don't apply the wrong fix to a problem. It wastes your time and others. Take the time to look a little deeper and ask a few more questions, and then make your decision and move to alleviate the problem.

Join AUGI Today

Become part of the largest Autodesk community

About the Authors

Mark Kiker

Mark Kiker has more than 25 years of hands-on experience with technology. He is fully versed in every area of management from deployment planning, installation, and configuration to training and strategic planning.  As an internationally known speaker and writer, he is a returning speaker at Autodesk University since 1996.Mark is currently serving as Director of IT for SIATech, a non-profit public charter high school focused on dropout recovery. He maintains two blog sites, www.caddmanager.com and www.bimmanager.com.

 

Appears in these Categories