First let me define what I mean by a quality engineering document. Engineers produce documents. The drawings, calculations, specifications, computer codes, reports, etc. that engineers deliver have a profound impact on the world. They result in new products and designs, they enlighten and inform, and mostly they solve problems.

Simply put, quality engineering documents meet two tests:

1. They are technically correct
2. They meet customer expectations

It has taken me some time to arrive at and accept this definition. Some might say that it has to be “right”, and the customer has nothing to do with judging quality. Others believe that the customer alone defines quality. In the end, I like the balance provided by judging quality on both technical merit (“its right”) and customer satisfaction. Most of the time the two are consistent and by meeting one the other is inherently met. However, if you don’t understand your customer’s expectations, you can produce a technically accurate document that is not what the customer needs.   Likewise, if you only focus on totally meeting your customer’s expectation, you might miss an important technical detail that the customer was not aware of.

Tips

The following 4 tips are recommended to help you always produce quality engineering documents

1       Listen to the customer

All through the development process, involve the customer to the extent practical. Invite the customer to your kickoff meeting or pre-job brief. Ask about key inputs, assumptions, and constraints that the customer needs to define. Understand how the customer intends to use your deliverable and what is important to the customer. Work through any differences in approach or mindset up front.
This is a lot easier said than done. On more than one occasion, customer comments on my deliverables have been excessive. Maybe you have experienced the same disappointment? Unfortunately, I have found no quick fix for this. It takes time to understand your customer’s expectations, especially if you have many different customers and the players keep changing. Nonetheless, the advice is to get close to your customer, discuss differences in approach, and attempt to achieve alignment so excessive comments don’t continue with every deliverable.

2       Follow the Process

Humans are fallible; that is why procedures and processes exist.   In my business, strong processes are continually being assessed and improved to produce quality deliverables. When something goes wrong, very often either a weak process or a good process NOT followed is part of the cause.

3       Care

To me, this is the most important and fundamental tip I can think of. A peer reviewer visiting our facility once told me that it comes down to two things an organization must have. Good People and Good Processes. He went on to say, if you can only have one, it is better to have good people. The critical attribute a person brings to the table is caring. People producing engineering products need to be engaged and care about the work they are doing and its impact on downstream users. People with a high “Care Factor” take responsibility to get it right, to follow procedures, to ask the next question, to anticipate obstacles, to test and challenge assumptions, to communicate across boundaries, and to relentlessly pursue excellence. Even when processes are weak, good people who care, make sure it gets done right.

4       Own it

Whether you are the preparer, reviewer, or approver of a document you need to “own it”. By that I mean take responsibility for your role and hold yourself accountable for the results. This is a personal mindset that comes naturally to some but for most of us it needs to be nurtured, encouraged, and supported by the organizational culture. I have observed in my own behavior that it is not a constant. I love the book “Change the Culture, Change the Game” by Roger Connors and Tom Smith, which gives techniques for changing your organization’s culture to achieve the results you are looking for.

Obviously this just scratches the surface of how to produce quality engineering documents. I would love your comments and feedback, as well as any related experiences you would like to share.