Tools to Manage Trouble

I went back in time this week. It snowed a whole bunch, and I felt I was back in my childhood, shooting pucks into a net chiseled out of the snowbanks that were more than 8 feet high. Things would have been easier with a prefab hockey goal.

I haven’t engineered a full control system for awhile. The road from concept to completion is long and winding. However, we don’t have to step on each yellow brick in the road to be successful. Sometimes, it’s better that someone else takes responsibility for some things. Sometimes.

A client of mine has been doing its own engineering for some time. Many changes are done on the fly. Seven years ago, they hired a consulting firm for a major project. Since it was on the order of $45 million, this was a wise move.

The consultant and the main OEM supplier worked together to design and build the new system, which was a conveyance system and a third-party-built system to place a smaller shipping pallet onto a larger one. The third-party OEM built the machine and process to do this, while the main OEM prepared and built the supporting systems.

I was in charge of retrofitting the controls to accommodate this new design. I’m a software guy, so this was OK with me. The OEMs handled the hardware issues, and I learned things from these guys.

We did three projects of varying magnitude together in 18 months. It was busy.

Fast forward about six years, and the same customer has a major project in-house that it wants to do itself. As I say, there are times when it’s wise to not do things ourselves. This might turn out to be one of them. The main reason I say this is because this customer has placed no workaround or contingency into scope. Should the project hiccup in any way, the daily throughput of the business will be zero.

Without a scope document, scope creep isn’t recognized. It’s already happening. That’s trouble.

This isn’t an ad for E-CAD, but it might as well be. What happens next is like playing hockey with drift-carved nets. It works, but it isn’t optimal.

While gathering data for this project, the same document appears twice. They have different drawing numbers and descriptions, but contain the same information—an indication of the future, I fear.

There is no time to learn anything new. There are no resources that can help in preparing information for the on-site panel building. The panel layouts are done on graph paper. Bills of material are dart-boarded.

I couldn’t take it anymore. I put the brakes on by waving the biggest red flag I could. The company was too busy killing alligators to remember that the prime objective was to drain the swamp.

The project had fallen into the “git-r-done” trap. When you try something new, the nervousness starts. Time was ticking away, and things weren’t gittin’ done. So naturally, the course reverted back to the good old days—the methods that you’re comfortable with, the environment that you can work in. Tasks get completed because of this, and the nervousness goes away because something is being accomplished. Sort of.

Well, panel layouts were still done on graph paper, but we now have a true BOM and a scope document. Forward momentum.

But we have no project management tools, at least not yet. This was the first item on the agenda when I sat down with the boss.

The result of our concern has been to create standards for drawing numbering, wire numbering and device IDs. These will be used in the movement toward an E-CAD system to provide drawing management, as well as project management, since there are many other projects to do.

Sometimes it’s hard to look beyond the tip of your nose because the main objective is the daily grind. Someone has to be responsible for forward thinking and research—fundamental or otherwise.

The OEM community would not even think about engineering a project without management tools. But what else are you missing because you can’t find the plug to the swamp?