Start With the Problem, Not Your Solution

When I told the management team they needed to learn the new ERP because we were going ahead with it, the response was laughter. The reaction was essentially, “Sure—just like the last four times we tried to implement a new ERP.”

I’d been assigned to upgrade the system. I’d researched the options, worked with the owner, narrowed the search to two candidates, and selected one. I had put considerable effort into the decision.

But I hadn’t consulted the team. I hadn’t asked what was making their work difficult or what would help. I was ready to implement a solution, but we hadn’t agreed on the problems it needed to solve.

I thought I was helping

I handled the initial implementation calls myself. I also decided we should move away from paper routers and printed drawings and use tablets instead. Those devices needed management software, so I selected that too and planned to configure and manage it.

At each step, I thought I was taking work off everyone else’s plate. I would handle the research and technical setup. When we reached the point where the team needed to participate, I expected them to be interested and ready to help.

I didn’t recognize that I was making decisions about their work without their involvement.

Their skepticism was especially difficult to hear because I had already invested so much effort. They were remembering the previous attempts, and I was determined this one would succeed.

My response was to push harder.

More than a software change

I worked sixteen-hour days, weekends, and holidays. I loaded our information into the system, developed procedures, configured tablets, and created policies for their use. I held meetings and training sessions for managers and employees.

Some people helped. But much of the implementation depended on me, and I’d taken on far more than a normal working week could accommodate.

Eventually, things started working. Then I found managers still using the old system. Work and information were split between the two, and I spent months tracking down stray jobs and trying to bring everything into one place.

Employees were also having connectivity problems with the tablets. I was asking them to move away from paper, but the devices meant to replace it weren’t connecting reliably. Their frustration was legitimate.

I had bundled two substantial changes together. People were learning a new ERP while also moving away from the paper they used to run jobs and read drawings. The tablets weren’t just equipment to deploy. They changed how people accessed the information they needed to work.

I had treated that decision as another task I could handle. It deserved its own discussion and testing with the people who would use the devices.

We weren’t evaluating the same thing

I was looking at what the change was supposed to solve. They were looking at what it had disrupted.

Without a shared understanding of the original problems, we had no common basis for weighing the new difficulties against the intended benefits. I was asking people to persist with something they hadn’t helped choose while dealing with problems they were experiencing firsthand.

Working longer hours couldn’t settle that disagreement.

What helped was the arrival of new managers. They learned the business using the new ERP, saw its value, and supported it.

Their contribution was a major reason the implementation ultimately succeeded. I had done much of the work to get the system running, but other people helped make it something the business could use and support.

Even so, more than a year into the project, we were still dealing with problems and reluctance. Things eventually settled, and the team became happy with the system. Getting there had been much harder than I expected.

The meeting I should have held first

Given the assignment again, I would start with the work, not a demonstration of my preferred software.

Before deciding to replace paper with tablets, I’d ask the people on the floor to walk me through a job using the router and drawings they already had. What do they refer to? What do they write down? Who needs that information next?

Those are questions I should have asked instead of assuming the answers.

I’d ask the people planning and managing jobs to show me where the existing system helped and where they had to work around it. Which information was difficult to find or trust? What would a replacement have to preserve?

The previous attempts also belonged in that discussion. What had happened during those implementations? What would need to be different this time? Telling people this attempt would succeed wasn’t an answer to what they had already experienced.

The assignment was to upgrade the ERP. I didn’t need to pretend every decision was open. But the requirements, the workflows, the equipment, and the transition plan all needed input from the people affected.

Once we understood the problems, we could compare potential solutions. I’d still bring my research and recommendations, but they would be open to examination.

I would need to evaluate the team’s suggestions, not just look for support for my own.

For the tablets, that could mean trying the actual workflow on the floor before making it the normal way of working. For the ERP transition, it would mean agreeing on how jobs would move between systems and who would be responsible for making sure information wasn’t left behind.

Participation would also need to continue beyond that meeting. Data preparation, workflow decisions, testing, and training couldn’t all remain mine simply because I was willing to do them.

What the long hours cost

Earlier involvement wouldn’t have prevented every technical problem. We still would have needed to move information, train people, and deal with a difficult transition.

But we would have had a better chance to discover problems together, decide which tradeoffs were acceptable, and share the work of making the change succeed.

I thought doing everything myself was a way of helping the team. Instead, I left them with too little opportunity to shape a system they would have to use.

The cost wasn’t just a difficult rollout. It was months of cleanup, weekends and holidays spent working, and time with my family I can’t get back. I don’t see those sixteen-hour days as the part of this story worth repeating.

I should have asked for the team’s experience before I asked for their commitment.