The Frankenball (Let’s Talk Overengineering)

You know who you are. That’s why you’re reading this article. But let’s be honest, we’ve all been there. Whether it was over-engineering a project, over-engineering dinner (we’re looking at you, Heston), or over-engineering our last holiday, if you can remember that far back.

Keep it simple, stupid.

We were asked to look at taking over a project recently – we can’t tell you what it was, but for the sake of conversation, let’s assume it was a soccer ball. Said soccer ball was not only being engineered to be a soccer ball, but also a football, basketball, tennis ball, Bluetooth speaker, LED flashlight, and on hot days – maybe even a beach ball. Part of this pizza-topping style function list came from the client’s requirements. And (at a guess, a larger) part of this came from the designers they had been working with previously. Whilst the attempt to make said soccer ball with all the aforementioned functions, was indeed admirable, what it did do, was dramatically increase the time and budget being spent on developing simply a really good soccer ball.

And at the end of the day, aside from the client’s vision, there was no research to drive the need for the additional functions. Sometimes it’s better to just “keep it simple, soccer” ball.

So what causes it?

One of the main drivers of this problem of over-engineering that we quite often see, occurs when a designer or engineer is working on a project alone. Whether that be a Freelancer, or a resource as part of a larger team. Isolation in problem solving can quite often yield overcomplicated solutions simply due to a lack of exposure to other ways of solving perhaps a similar problem. It’s something that we always have to pull ourselves up on, early in the process, and stand back and ask “are we doing this the simplest, most robust and lowest risk way? Are we in fact over-engineering this solution?”

Sometimes you need the sense check to stand back and ask oneself, “Gun to my head, if I had to do it differently, how would I do it?” And 9 times out of 10, you find there is another, simpler way to solve the problem.

How do we avoid it?

We use a number of tools as part of our development process to mitigate risk. From feasibility studies, proof of concept studies, DFM reviews, DFMEAs, Boundary Diagrams, P-diagrams, FEA, and peer reviews before release. But one of the most beneficial reviews that we do, is the “can it be done simpler?” review. CIBDS. The acronym is not great – leave a note if you have a better idea for one – but the exercise is.

Because we use an Agile methodology in our design process, we’re always aiming to deliver smaller chunks of work sooner. With regular reviews at daily stand-ups, there are always multiple sets of eyes on any project. This gives our designers and engineers two amazing benefits. 1. If struggling to solve a problem, they get to ask the entire project team, “can it be done simpler?” And 2. The team has the chance to look at something as it’s been developed and say “that seems over complicated.”

The power of these questions is immense. We recently reengineered and simplified a project that originally took about 4 weeks for a first build, in 24 hours, cutting 25% of the parts, and simplifying assembly. This is the power of collaborative team problem solving.

Need a hand?

If you find your project going through a similar process and you have this gut feeling that says, this can be done simpler, trust it. Quite often it can be. And that translates very clearly to reduced costs, reduced risk, and an accelerated time to market.

Feel free to reach out if you need a hand with this sense check. We love chatting product development and problem solving.