Recently, I hired professionals to cut down some large, dead trees near my house. I then used a chainsaw to cut the trees into smaller, moveable pieces that I could chop for firewood. I was making slow progress when the chain pinched and broke a few teeth. I was about to head to the hardware store to get a replacement chain, when my wife pointed out that the chainsaw I was using worked best on trees below a certain maximum radius. The trees I was cutting up were considerably larger. As a result, I invested in a new chainsaw that was better able to handle the task at hand. With the new tool, my progress was faster and less strenuous.

The right tool for the right job. That adage applies to most everything we do, whether cutting up trees or developing new products. A lack of tools or poor tools are not necessarily bad—if you have sufficient time and energy to overcome those limitations. For cutting up large trees, a suboptimal chainsaw is better than an axe or nothing at all, but it’s not better than a chainsaw designed specifically for the task.

Over the years, I have worked with organizations that have all sorts of tool challenges. Sometimes, these companies have tools that their teams do not use or that only some teams use. One company had a software tool for managing the process of testing new products. It kept track of test artifacts, product revision levels, test cases and test results. The tool also had space for recorded data, the engineer conducting the test, and the best person to resolve any problems that may arise. In short, the tool provided everything engineers would need to make informed decisions about the disposition of any product revision.

No one used it.

A tool that is not used is not helpful. It was difficult for the project manager and executives to learn anything from the tool. Many test teams tracked test results using their own Excel spreadsheets, and their data was not reported in the tool. With no defect reports to be found in the tool’s data base, management might conclude that no problems were found during testing. That was not accurate.

A companywide effort to encourage engineers to use the tool improved clarity of the testing results, producing actionable information and enabling project managers and executives to know what was going on.

Another common story is when teams have disparate tools that do not facilitate the work. Consider a large manufacturer that consists of several smaller companies or divisions that are expected to work in synch with each other. Too often, their tools (and even their processes) are not aligned. Sharing information is not easy, there are multiple tools that require support, and a person performing a function in one company will not know how to do the same work in a sister company.

There are benefits to this organizational structure. For example, it can facilitate specialization and development of expertise. On the other hand, it is often difficult to communicate between organizations or siloes.

There are solutions to this communications conundrum. Product life cycle management (PLM) software can facilitate communication between siloes. Modern PLM software provides a hub for information that is accessible to all. It is not effective or efficient to have multiple tools for handling one portion of the product life cycle. Product management processes work best when they are interconnected.

Tool Selection

Before assembling a toolbox, we need to identify what we want to accomplish. Then, we can look for tools that will help us achieve these objectives. First, assess the current state. How do we work now? How do we want to work? How do we envision that changing over time? What information is needed and who needs it? What are the present and perceived future obstacles? Then, identify a list of tools that show promise of meeting your needs. Evaluate the cost and benefits of each tool via demonstrations and experiments. Once a tool has been decided upon, make implementing it a priority.

All stakeholders should be involved in the process. To go from a product idea to finished assemblies coming off a line requires a host of team members and a variety of departments and disciplines. These team members and areas of responsibility are often distributed throughout the company and not in a single office or even geographic region. Function-specific software tools can help—remember that software for tracking product test results?—but they can also separate that function from other development areas. Making communication logistically more difficult is not an improvement.

Tools can help us work more effectively. Tools can help with communication across the breadth of the organization or even between organizations. This is important for product development and manufacturing. Material changes, process changes and even functional changes to the product can and do occur in the course of developing a new product. Creating and delivering a product from idea and development through to manufacturing are not a collection of discrete steps, but rather the result of an interconnected network. Your tool selection must recognize this.