Concurrent Engineering

In 2010, my career took me to the Middle East, and I lived for a year in Dubai. Some key team members, and key customers, were based in Abu Dhabi, a ninety-minute drive away, and I made that drive many times. If you are approaching Abu Dhabi from Dubai, one of the first things you see as you approach the city is a remarkable building that looks something like a coin stood on its edge – the headquarters of Aldar, a United Arab Emirates real estate development company. This building was completed shortly before I lived there and to a very tight timescale with a fixed end date: it had to be completed in time for the inaugural Abu Dhabi Grand Prix in November 2009.

This only allowed thirty months for design and construction – a schedule that would have proved challenging for any building, doubly so for one with such an unusual design and where the loads on the structure were not known and could not be calculated when it was designed. The building was completed on time, but only because of a strong collaborative effort between architects, engineers, and builders. Counter to the principles of a traditional waterfall project management approach, whereby design would be signed off before construction began, the foundations had to be poured before design and analysis were complete – in fact, foundation work began only a month after the initial sketches of the design were approved. The unusual design of the building, combined with its height, meant that wind loads were unknown until extensive wind tunnel testing had been completed and analysed. The foundations were deliberately over-engineered to take account of this, deliberately trading additional cost against schedule improvement. Parts of the building, including the bathrooms, were manufactured off-site in modular form to save time. And the special triangular glass elements required to clad the spherical external faces were manufactured on-site to reduce transportation time and optimise the schedule. The building was completed on time, but only because the engineering and construction functions found ways to work together to compress the schedule. As such, this is a great example of concurrent engineering.

It is much harder to succeed if you insist on doing things sequentially. Smith and Reinertsen (1991) noted something similar. They saw that what they termed a “phased project planning approach, with checkpoints” (for checkpoints, read gates in a waterfall or “stage-gate” system) constrains us in that the project cannot proceed past any given gate unless all the work in the preceding phase is complete. They saw the need to be able to work in parallel on different activities and thereby blur the boundaries between stages. I mentioned this to a friend of mine, and he pointed out that it reminded him of old-fashioned Christmas tree lights that were wired in series, and it turns out that this is a good analogy. Some older readers may remember them, probably with a grimace. One broken wire and the entire string of lights was off. If they are wired in parallel, as is more often the case nowadays, a broken wire throws out one bulb, but the rest still work.

You won’t get there fast enough unless you can identify activities that can be done in parallel, and you will need to have different functions working concurrently with each other – so-called “concurrent engineering”. There must be a continual back-and-forth between functions who need to cooperate from “Day One” of the project. This means that functions that would typically be thought of as being at the “back end” of the project, or to whom designs or other documentation might be “thrown over the wall”, must instead be involved from the beginning. For example, your supply function might need part numbers and/or bills of materials (BOMs) to procure even simple experimental parts. If they do, you will need to build the ability to provide these into your thinking as you set out.

It is as important to have manufacturing, supply, distribution, operations and service involved as you write your requirements specification as it is to include inputs from sales and marketing. Lines of communication must be good enough to have a continuous flow between functions so that problems can be identified and ironed out as rapidly as possible. In a similar vein, opportunities can also be identified. One of the forces that I have seen have the most transformative effect on mechanical design in recent years is the coming-of-age of additive manufacturing, also known as “3D printing”. Removing the bias that design engineers had because of their understanding of historic manufacturing processes (where items had to be cast, milled, or turned) has allowed them significantly more freedom to create what would previously have been considered “hard-to-make” geometries and thereby improve performance. This manufacturing technology also creates opportunities, for example, to print spare parts at the point of use.

Leadership must understand this need for effective cross-functional communication and must make it happen. Organisations that can master this will always beat organisations that cannot.

In his 1998 book Clockspeed, Charles Fine identified what he called key steps in concurrent engineering. He noted that, unsurprisingly, a lot of work needs to be done at the front end: for example, identifying alternatives for product design and manufacturing processes and estimating, from the outset, the likely costs and resource requirements associated with these different options. He also noted the importance of alignment: aligning design requirements with those of process design and organisational capability and aligning incentives across the organisation. And he reiterated that supply chain is as important a consideration as manufacturing when practising concurrent engineering.

In a similar vein, you must also be prepared to order critical parts early – before the design is complete – to expedite the timescale. You must accept that there will be an attendant risk that some of these parts may never be needed, or may not be correct, and you must be prepared to accept the cost to optimise the schedule. It’s important to realise that the cost of doing this is almost always significantly less than the cost of not having parts that you may not have ordered in time but that, it turns out, you inevitably need.

If you want a good example of an organisation that believes in concurrent engineering, Steven Johnson provides one in his 2010 book Where Good Ideas Come From, where he described how Apple includes all interested parties – design, engineering, manufacturing, sales – in continuous discussions from the start of a project. Johnson stated that this makes the process “noisier” and more contentious than it might be in a more traditional company, but, as he wrote, “the results speak for themselves”.