Know your audience
Engineers are competent technical professionals, but when it comes to adding notes to a drawing or writing a design report, language may not always come naturally to some.
Knowing your audience is the key to successful writing. For engineers, documents are typically drafted to be understood by the contractor, the owner, and sometimes the judicial system. These three audiences may each have different levels of education, ranging from high or trade school to graduate level degrees or higher. You should also presume that some percentage of your audience may not be literate or have limited command of the English language. However, all parties need to arrive at the same conclusion when interpreting the drawings and specifications.
Drawings alleviate much of the engineer's communication burden as graphical depictions leave very little room for subjective interpretations. But drawings can only communicate so much. What about the quality requirements of the items depicted? How do you articulate to the client the decisions made during design?
Additionally, there is another factor in this equation. When working in an office setting, you know how to communicate with your manager and team members. You are all in the same work environment every day and likely share similar education and work experience. After the initial acclimation period, you know how to communicate: whom to address in a particular situation, those who need the long explanation, and those who are satisfied with a brief summary.
When preparing engineering documents, you don't know the audience personally or have an idea of the organization's culture or procedures, and you can't make more than a guess at their education level. That makes any sort of writing difficult.
It's no magic bullet, and there are likely other ways to do it, but here is one way I've found to be effective when writing specifications, design reports, and other engineering documents: Write for the judge.
In the absolute worst-case scenario, a highly educated person with little to no technical background is reviewing your contract documents and will make a decision based upon his or her interpretation of those documents. The judge may not know the difference between single phase or three phase electricity or a tack coat and a finish coat, but their understanding of your documents will result in a legally binding opinion.
The chance that your engineering documents will be involved in litigation may be slim, but it is rising. According to the Fulbright 9th Annual Litigation Trends Survey, 80% of the engineering and construction companies surveyed were involved in litigation, with 57% of the surveyed engineering and construction companies annually spending $5 million or more on litigation fees (pg. 19). Twenty percent of the engineering and construction companies surveyed have more than $20 million at stake (pg. 14). Engineering and construction companies also had the highest anticipation of more litigation – 31% of engineering and construction companies forecast more arbitration and higher legal fees for 2013 (pg. 9). The American Bar Association even has a Construction Litigation Committee – you get the idea. Note that fees don't cover settlements or judgments, so the total cost may be significantly higher.
Getting back to writing, to many, writing for a judge instead of a contractor goes against the grain. But think about it for a moment. As engineers, we are tasked with preparing construction documents that become legal documents upon signing and sealing or submitting them per the client's requirements. Once those documents enter the judicial system, there is no requirement for those involved in litigation to have specialized training, experience, or background in the subject matter of the documents. Sure, some lawyers may have a degree from an engineering school or a professional engineer license, but they also may have neither.
A judge or lawyer is skilled at picking apart documents to find inconsistencies, conflicts, and holes. It would not be difficult to see that the description of a system in a specification does not match what is shown on the drawings, or to notice that the design report scrupulously describes certain parts of the work but completely ignores other elements. This isn't anything different than what a contractor looks for in a bidding situation.
It is your job to describe the system(s), assemblies, and desired performance in language that is able to be interpreted by all parties in the same manner. This doesn't mean the documents should be "dumbed down" or simplistically written. The documents should use appropriate terminology and be written in a manner that clearly, concisely, correctly, and completely (we'll discuss the 4 C's another time) addresses the work. The documents should also be consistent in their language, presentation, and style.
Ultimately, if a judge, who is well versed in learning about and assessing a situation, is able to understand your documents with minimum outside help, not only have you succeeded in presenting your case well, but the likelihood of a contractor reaching the same conclusion is very good.
I'll present some examples in future entries. In the meantime, there is a wealth of resources available for engineers who want to work on their writing. Taking courses in engineering law or technical writing are an excellent way to meet continuing education requirements. Professional societies such as ASME, IEEE, and ASCE all have resources on writing for engineers.
Feel free to add resources or share your experience writing as an engineer below.
Michael Heinsdorf, PE, LEED AP, CDT is an Engineering Specification Writer at ARCOMMasterSpec. He has more than 10 years' experience in consulting engineering, and is the lead author of MasterSpec Electrical, Communications, and Electronic Safety and Security guide specifications. He holds a BSEE from Drexel University and is currently pursuing a Masters in Engineering Management, also at Drexel University.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.