Project Management and the Importance of the Engineering Specification

The Engineering Specification

In part two of this blog series, I will be addressing the project management element:  The Engineering Specification (Engineering Spec).  The Engineering Specification is engineering’s official response to the Market Requirements Document (MRD).  Once approved, it replaces the MRD as the “go-to” reference for the project team and is the yardstick against which the final result is measured.

How This Process Works

Imagine an interaction between a homeowner and a contractor.  The homeowner says, “I want a new deck” and points to the area in his back yard where it will be built.  He may then proceed to pace off the area in question and talk about steps, levels, lighting, and the desire that it have an “Asian Style” and be built for “not a lot of money”.  This is the homeowner as the Customer/Marketing Department.  All the hand waving and the laundry list of features represent the MRD.

The contractor must listen carefully and attempt to codify the requirements into something that can be realized within the budget, while also meeting local building codes.  His response to the homeowner will probably be a sketch with a list of materials and features as well as a price and delivery estimate.  The contractor has presented the homeowner with an Engineering Specification coupled with a preliminary project plan.

Apply This Process to Project Management Engineering

The process a contractor uses to create an Engineering Specification, is identical for a systems engineer within a design firm or an engineering group.

The goal of an Engineering Spec is to nail down the details of the design project.  It is a negotiation process between the engineering group and the customer, represented typically by the Marketing or Product Management group.  Usually the Systems Engineer is the chief negotiator.

As an experienced systems engineer, I find it useful to think like the contractor in our example.  Here is my mantra: “Tell me what you want, and I’ll tell you what it costs”.  It is not up to the engineering department to decide which features or functions should stay or go.  Once the customer is presented with the tally, he can make an informed decision as to the priority of the requests in the MRD.  By the way, “cost” does not only mean money.  Cost can also be resources or time.

Elements of a Good Engineering Spec

• Propose a Model:  The model embodies the final product and communicates in a way that words cannot.

The system engineer, in collaboration with a small group of development engineers should convene to review the MRD and imagine a system design that will satisfy as many of the requirements as possible, and sketch up a model of the proposed solution.  In the days before 3D Computer Aided Design (CAD), it would actually be a sketch.  Now, the model can actually be like a maquette (a french word for scale model), complete with color and shading.  A word of caution, resist the urge to make the model really finished looking.  We want to convey the essence of the solution, NOT the actual implementation details.

• Respond to Every Requirement in the MRD:  Do this line by line.  Each response should describe a deliverable feature or function as well as a performance specification against which it can be measured.  Make sure that features quoted carry the appropriate level of accuracy and tolerance for later verification.

If the team agrees to an MRD item, then parrot back the original requested value.  Otherwise, respond with a counter offer as to what the engineering department proposes they can achieve.  Also, make a first estimate of Time, Resources, and Cost for each item.  This is the “I’ll tell you what it costs” part of the process.

• Include Implied Specifications:  The specification must include details related to environment, safety, and human factors.  These items add cost to the project and must not be glossed over.
• Provide a Preliminary Project Timeline:  While this is technically not a formal part of the Engineering Specification, it is a critical part of the negotiation between engineer and the customer.  It is another part of the project cost and allows the customer to prioritize and potentially pare down the original MRD wish list.
• Don’t Promise What You Cannot Deliver:  Treat the Engineering Spec like the contract it is between the engineering group and the end customer.  If you say OK, you had better deliver.

Finalizing the Engineering Specification

Negotiations as to the final content of the specification can happen formally or informally, but in the end, it is the written and signed-off speck that will drive the project.  Resist the temptation to rely upon verbal agreements.  Get it on paper and get it signed off!

At this point in the project, the Engineering Specification becomes the reference document and replaces the MRD.  It is the responsibility of the project engineer/systems engineer to formally maintain the document and see that any “creeping features” requests are either killed off or added to the specification.

Back to our example…

Once the homeowner and contractor agree on the details contained within the contractor’s plan, work proceeds and the final result is compared with the contractor’s plan NOT the original laundry list.  Having a written plan helps to avoid unpleasant conversations about that fire pit the homeowner thought he had asked for.  The plan shows what is to be delivered-if it is not there, it does not happen.

Once the Engineering Specification is finalized, the next step in the process will be for the systems engineer to develop the Work Breakdown Structure and actual Project Plan.

Part three in this series will discuss the Work Breakdown Structure and actual Project Plan.

If you want information how to effectively use a requirements document in project management, check out part one of this blog series Project Management Elements Part One: The Requirements Document