Sometimes you realize after a project that your efficiency boost cost more than it is worth. I experienced this on a home project and have seen it from overzealous engineers. I’ll share a few examples and explain how you can avoid falling into this trap yourself.
I ran into this on an electrical project a while ago. I went through a lot of extra effort to put in switches at both entrances to the kitchen and at the counter in two places. The thought was that no one wants to have to go far to turn on a light. As it turned out, the kitchen was small enough that the extra switches on the counter were a complete waste!
I also ran into this on a chip testing project where an engineer used a sophisticated system intended to to increase test writing efficiency. The idea was an environment that simplified boring work and could perform the same testing with less effort. The following signs, if heeded, would have prevented the failure to gain intended efficiency.
The extra features aren’t useful
Fortunately, many projects allow for course corrections early in the implementation. What seemed like a good idea doesn’t have to wait until Sheetrock is in and cabinets hung before we realize we wasted time. Early prototypes should be peer reviewed to ensure efficiency goals are hit.
Only after completing the kitchen did I realize it was too small to benefit from counter switches. The first prototype is a good time to validate efficiency assumptions versus the extra development investment. If the payoff isn’t there, it’s time to rethink how much work should go into making life easier later.
The solution is confusing
Another aspect of the electrical project was excessive switches. No one should have to label them to keep them straight! The chip testing features ended up making the environment both confusing and difficult to debug. The invention of new syntax for this ‘shortcut’ meant that no one else on the team really understood how to get things done. Worse, it meant that future efforts to augment the effort with other groups or consultants had lower productivity because the system was so confusing.
It can be hard to see how anyone could be confused by your flawless system, but this is another area where peer review is powerful. Start by presenting a plan and having that reviewed. Review again after the prototype, since nothing clarifies a vision better than an attempt to make it real.
It isn’t standard
I should have thought a 5-way kitchen circuit was a bit crazy since I didn’t anyone else with one. Instead, my thought was that builders were too cheap. Similarly, a warning sign for the chip testing project was the use of a new syntax and new flow that hadn’t been done before. There are times to do something new if the old way doesn’t work. The cost of new is that others can’t apply standard practices and have to invest into learning a unique solution.
Make sure you know the best practices and apply them to your project. If you are breaking new ground, consider doing something new to boost efficiency as well, but only after you are fully taking advantage of the best thinking available. Do a gut check and make sure your enhancements are really delivering benefit on top of best practices and not providing an escape from having to learn something new yourself!
Getting it right
The trick is to know when to stop. Be sure review plans and your work by others! So much can be avoided by early feedback, before the investment makes it is hard to go back.
What have you found as your red flags for an efficiency project that is destined to waste time? How do you make sure to make changes before it is too late?
Recent Comments