I recently participated in a discussion panel that was part of the AIAG Quality Summit in Novi, Michigan, September 22-23, 2015. The topic focused on software for quality in manufacturing. The panel included vendors offering software for quality improvement and quality management systems.
An important question was raised from the audience:
“When we purchase software for improving quality or any other function, we have to justify the cost. This can be difficult. Some of your solutions are complicated. They require significant work before benefits are realized. They often require multiple users to buy in to the idea that using the software will result in improvements. Can you offer any guidance on how to do this?”
Wow. This is a great question, and I have empathy for anyone in this position of justifying investment in quality improvement software. While there is no recipe that will work in every case, there are approaches that can help when you find yourself needing to do this thinking.
First, here are some things to avoid when justifying a software purchase:
- Do not immediately jump to a before/after comparison of costs. When considering a new software solution, it is common to look at your existing workflows, identify problems or inefficiencies, and begin racking up their costs in a spreadsheet. The goal here is usually the ability to say, “Look at how much this is costing now!” Next, a second spreadsheet is created where the costs are estimated to be lower after installing the software. The goal here is the ability to say, “Look at how much we would save with the software!” Of course, the hope is that in a single meeting with the financial stakeholders, you will hear something like, “This is a no-brainer…Let’s buy it.”
This analysis is usually done by one person. However, no matter how smart or experienced the person, he or she often does not see a complete picture of the system that will be affected by a software solution. People in different roles may make different estimates of both sets of costs. Cost and cost savings should be part of the analysis — just not the first part and not without input or discussion by affected workers.
- Avoid early dictatorial decisions. Leaders have to make decisions. We all get this. When considering a new software solution, making the decision too early can lead to problems later when the solution is deployed. For example, imagine an engineer saying this at the weekly meeting: “We are going to purchase an SPC system, and it will be one of these two products. Look at these and give me a cost justification by next week.” Two things have been dictated: 1) We are buying an SPC system, and 2) It will be one of these two products. Both dictated decisions might be really good decisions. However, the people working in the system have been pre-conditioned to question the decisions because they were excluded from any of the thinking. People who play a collaborative role in a decision are more likely to engage in making the decision work.
- Be cautious of duct-tape solutions. People are smart and resourceful. On more than one occasion, I’ve heard comments like this: “We don’t need software for that. I’ll create an Excel sheet showing the latest results. We can circulate it in email every morning.” For almost any software solution, there will be a computer-savvy worker willing to build the system for you. We have seen impressive systems like this over the years. We’ve also had to carefully undo some messes created by long-gone employees. Make versus buy may be part of your cost justification, but the make option should be approached with caution. Keep in mind that most of the cost of a software application is incurred after it is developed and deployed.
Now that we know some things to avoid, let’s consider some helpful approaches when justifying a software purchase.
- Identify what you want to accomplish — and do this early. Start by defining the problem or set of problems you are trying to solve. It is a good idea to make these positive and action-based rather than negative. For example, instead of stating a problem as, “It takes too long to gather and chart the SPC data requested by the customer,” you might state it like this: “Our customers want to know that we are shipping high-quality products. To meet these customer needs, we’d like a system to streamline the data gathering, SPC charting, and analysis of quality metrics important to our customer.”
- Give affected workers a look at your proposed goals. Create three or four key goals you have for the system. Test these goals on the workers likely to be impacted by the software. If you can get early agreement that the goals are worthy, the workers will feel more like collaborators for the rest of the process. Open-ended questions are good. For example: “Here are some things we want to accomplish. Do you have any thoughts about these?” Take some time to listen to what you hear. You might be surprised with great ideas or better things to have as goals. Consider revising the initial set of goals.
- Include the financial and technical decision makers early. Now that you have your goals nailed down, share them with the financial and technical workers who will play a part in the decision. Listen carefully to their concerns. If they see and agree with the importance of the goals, they become collaborators on the way to a good decision. In the past, it was common for a single worker to decide if he or she needed software, purchase it, and start using it — all without other workers being involved. Today, this is an increasingly rare event. Accept and engage collaborators early.
- Get input on ways to accomplish the identified goals. Without making it a forgone conclusion that software is the answer, seek input from your collaborators about ways to accomplish your goals. They may suggest software, or they may suggest other approaches. Often, a software solution will emerge as the way to accomplish the goals. When this happens, a vendor search can begin.
- Keep your collaborators engaged. As in the previous steps, ask your group of collaborators for vendors or solutions they might know about. If you have a vendor you are familiar with or one you think can meet the needs, see if it emerges as a candidate before you suggest it. Try to develop a short list of two or three vendors to consider. Once you have the list, make the rounds with it and listen to any feedback you get. All the stakeholders should now know the list of vendors being considered. Keep in mind that you are still doing most of this work and building up to a justification for purchase; you are just doing it in an open and inclusive way that will help any the eventual deployment.
- Imagine your way through a deployment with each vendor. Here are the questions to consider at this stage:
- What will it be like to do the initial software installation?
- How much time will this take, and who will need to be involved?
- What are the early tasks that need to be done in configuring the system?
- When will users begin daily interaction with the system?
- When will customers see any results or output from the system?
- What workflows will be in place in the first two weeks? First month? First year?
If you know the answers to questions like this, you will be well on your way to selecting the best software vendor for accomplishing your specific goals. At some point, select the vendor you think is best. Share this decision with your collaborators, and listen carefully for strenuous objections or red flags.
- Study and understand the pricing and licensing for the selected vendor. At this point, you need to look hard at the real and full deployment costs for the solution. What is the licensing model? What is the pricing? What is the initial investment, and what maintenance investment will be required in subsequent years?
- What is the cost of not accomplishing your goals? Early on, you established what you want to accomplish. Consider this question: What is the cost of not accomplishing the goals? Will you lose important customers? Will your sales decrease because you are not meeting customer requirements? Will supplier audits cause you to lose a certification required to do business with the customer? Now that you know the cost of the solution and the cost of not accomplishing your goals, you should have the raw material for a presentation to the stakeholders. Communicate to them the results and the process you went through to get them. It is important to let them know that a team has collaborated to create the analysis.
Deciding to purchase software that many workers will interact with is complicated. The success or possible failure of a deployment can be impacted by many human and social factors. Using the process described here can mitigate some of these risks. You and your financial people may not want to hear this, but the reality is that you cannot prove — beyond a shadow of doubt — that purchasing software is a good financial decision. However, you can be diligent and improve the odds of a good financial return through careful thinking and collaboration with affected workers. One of my favorite quotes comes from a book on thinking by Edward DeBono: “Most thinking is done to justify conclusions reached by some other means.”
Purchasing and installing quality improvement software can be a game-changer. It can improve quality, reduce costs, increase efficiency, and improve profitability. A deliberate and mindful approach during the cost justification phase can increase the likelihood of a good outcome.
M. Stephen Daum is director of development for PQ Systems. Prior to assuming responsibility for development, he was the lead programmer on PQ’s statistical software products. Daum has had more than 30 years of practical experience with control charts and control charting software, and has shared that experience through presentations, training, and educational sessions for organizations throughout the U.S., as well as England and South Africa.