The process of capturing, documenting, and agreeing on requirements for product change or development takes on an entirely different scope for companies engaged in Engineered to Order (ETO) businesses. While these requirements are generated internally for Make to Stock (MTS), Assemble to Order (ATO) and Configure to Order (CTO) product lines the ETO business relies on external sources. While everyone is familiar with the formal Request for Quote (RFQ) process, very few engagements will adhere to this. More likely, is a process of starts and stops requiring many man-weeks, months and years. The ability to efficiently; quote, process, develop and ultimately deliver an ETO solution is dependent on the enterprise’s ability to capture just enough information at the project’s inception to describe the product criteria, but not overly constrain the design team. Many a post-mortem analysis has revealed very small or non-existent margins from “specials”. By attending to the requirements at the project’s inception and ensuring that those requirements are of sufficient depth and breadth to quote and create specifications, scope creep can be prevented and margins preserved.

A requirement is a capability which the product or project needs to incorporate. For standard products, these are developed over time by internal teams during the ideation phase of product development.  The design and associated intellectual property are then developed as the project moves from ideation to fulfillment.  While this may describe the development of Intellectual Property (IP) for an ETO business, a different front-end is followed for ETO solution delivery.  As soon as the opportunity is identified by the sales team data (requirements) capture begins.  At an advanced maturity state, this data will be entered into the Customer Relationship Management (CRM) application with the correct associativity and visibility to the downstream (application engineering, procurement, etc) functions.  More often than not the customer contact data and a subset of the original notes will be entered. Another set of data is now stored in notebooks from phone calls and meetings. As more people become involved during the wooing and quoting phase more set of notes are created and NOT captured or associated formally to the opportunity.  Eventually, a quote is generated for the solution and delivered to the potential customer.  It is at this point where the troubles can really begin.  As the quote is iterated the data behind the iterations and the associated cost implications do not have as stringent review as the originals. When the project is finally won the margin has usually been eroded significantly from the original intent even before development starts.  During the quote iterations, technical oversight of the requirements is minimal.  This causes the potential solution being quoted to deviate from a variant of a previous design to the requirement to develop entirely new designs.  The effect is that the time estimates for the original design are now terribly inaccurate and the project won have been underbid.  If aware, most companies will choose to “eat” some of this as development time.  The problem is that most companies are not aware of this and schedule resources around original project estimates instead of the last iteration of the quote.  Now the pressure on the development team is substantial, to meet the new product deliverables at the same time allotted for the original quote.

To combat this, rules and guidelines governing the boundaries for the solution need to be put in place. These guidelines can be as simple as size and complexity constraints or for often quoted, complex designs, configurators can be employed to accurately capture application data.  At the very minimum templates for customer data need to be developed and used to accurately capture the customer’s data. The templates need to be established with clear boundaries so that the correct oversight is employed as the quote is developed.   As important, is maintaining the data as the quote is iterated.  All data needs to be readily available to the enterprise for use during all phases of the project as well as reference material for similar projects.  Associating the original customer data to the quote and any subsequent design files will enable the organization to comprehend the effects changes will have on the overall project.  This data associativity and transparency will help to maintain the intended margin and ensure the project stays on track.

You may or may not have heard of the term Extensioneering. We believe it was coined by one of our customers when he explained how we work with his internal engineering team. We literally became an extension of his group. Little did we know at the time, but it says a lot about how the Design and Engineering group at EAC approaches projects and working relationships with customers.

We now like to refer to what we do as ‘Extensioneering’ rather than consulting or outsourcing as these terms tend to have a stigma attached to them.

Outsourcing your Engineering Projects

In reality, what do you think of when you hear outsourcing;

• Why would I let someone else do my work?
• I don’t want to tell someone how to do it or explain what I need when I can do it myself.
• They won’t get it right.
• Outsource… doesn’t that mean to send it off to China or overseas?
• Toss it over the wall and see what comes back.

Some of the comments or statements may be true in certain situations. Some of these ideas stem from poor experiences in the past. And the worst may just be due to job security. Most of the bad rap that outsourcing or consulting gets is due to poorly set expectations. You should never have to lower the expectations of what you will be getting from your outsource partner, but do discuss expectations with them from the onset before any work is actually performed.  Doing this early will ensure you get a project completed and the deliverables will meet your needs.

I can’t tell you that outsourcing or extensioneering is the right solution for your company or project and I would like to tell you to send all your overflow, R&D type of projects to us (this is what we do) but that’s not the point of this post.

Design and Engineer Outsourcing Options

So here are some simple things to think about when choosing a design outsource (Extensioneering) partner;

• What is the communication schedule that you will have on the project?
• How responsive were they when you approached them on the project?
• In the discussion of the project, were they truly interested in the project? Will they provide some amount of potential education back to you (if needed) or vice versa?
• How many resources can be applied, both from your company and the potential design partner?
• What have they worked on before  It’s not always a bad thing if they haven’t done “what you do”. This allows for some out of the box thinking and fresh approaches.
• What software is to be used? Not just the CAD, but the data and project management aspect as well.
• What is the expected timeline for the project? Remember that the design partner schedule may also be dependent on what you can provide them in regards to communication and reviews.

Check out more about our Design and Engineering Services here.