Technical writing does not have to be boring.
Technical writing does not have to be difficult to read.

Architects, Engineers, and Contractors often write technical information. As an AEC marketer, you have the task of taking this technical writing and translating it so non-technical readers will understand it. Here are three improvements you can share with your technical writers to move from boring and difficult to interesting and easy!

1. Break up long sentences
2. Eliminate unnecessary words
3. Create bulleted lists

That's it! Simple to advise, but maybe a tad difficult to execute. So let's practice.
Here's an example of a difficult to read technical scenario.

"The improvements included addition of additional dewatering and conveyance equipment, storage and load-out systems, SCADA improvements, and a new operations facility to include lab space, control stations, and restrooms. This project was executed by the Construction Manager at Risk (CMAR) Alternative Project Delivery Method to facilitate a completion date one year earlier than traditional project delivery approaches.”

This scenario has a Flesch-Kincaid Reading Ease score of "0"! That means the paragraph is virtually incomprehensible. Applying the three improvements, here's how this same information can transform from difficult and boring to easy and interesting.

"We improved several systems. These included;

• Dewatering and conveyance equipment,
• Storage and load-out,
• SCADA,
• New operations with lab space, control stations, and restrooms.

The Construction Manager at Risk (CMAR) Alternative Project Delivery Method was used. This method was chosen to facilitate an earlier completion than traditional approaches."

We broke up two long sentences into four shorter sentences. We eliminated unnecessary words like, "addition, additional, systems, improvements, facility, project, executed, date one year earlier, project delivery." We took a list of seven items separated by commas and made a bulleted list of four items. By completing these three improvements the Flesch-Kincaid Reading Ease score jumped from "0" to "26." The grade level improved from "20.0" to "11.0."

BONUS
If you want to take technical writing to the next level, consider how you can make the data tell a story. Using the same scenario above, consider the following improvement in creating a story from the data.

"The owner of the wastewater treatment plant needed many improvements in a short timeframe. We quickly joined forces with a capable contractor and suggested a Construction Manager at Risk (CMAR) Alternative Project Delivery Method. This method reduced the schedule by nearly a year. Together, our team delivered the needed improvements within the owner's tight schedule. These improvements included;

• more efficient sludge handling with better dewatering and conveyance equipment, storage and load-out,
• better control and management of the plant with an improved SCADA system,
• improved operations with increased lab space, new control stations, and restrooms."

 
Notice how compelling and interesting a short story can be. In less than 100 words, we not only uncluttered boring data, but we made the data support what really matters. The owner's improvements were achieved in a shorter timeframe. 

Communicating process is about letting others know where you are in the process of delivering requested information or in completing a task. Most never think about communicating process because they do not see the value in it. However, when you communicate the process, it lets those who are depending on you know that you are working on what they need and whether you are on target or running behind. This is true for both external clients and internal colleagues.

Let’s consider a few scenarios to tease out what communicating process looks like.

• You have a report due to a client in 3 days. You recognize you will not be able to deliver the report on time. What do you do?

1. Option 1 – do nothing and simply deliver the report whenever it is complete, even if it is a few days late.
2. Option 2 – call the client on the due date to let them know you will be a few days late delivering the report.
3. Options 3 – call the client now to let them know you are running behind on their report, but you have a plan to complete and deliver it 1 week late. You will call again if that plan changes.

Option 3 is the best option for communicating process. You have communicated to the client early that their report will be late, you have a plan to complete it, and you’ve shared the new due date when you expect to deliver.

• You gave an engineering estimate for a project. You receive bids and the lowest bid is 15% over your estimate. What do you do?

1. Option 1 – call or meet with your client to describe what has happened and your best answers as to why you think the lowest bid was 15% over your estimate. You also share what their best options are for moving forward.
2. Option 2 – email the bids to the client with your recommendation to award the project.
3. Option 3 – sit on it for a week before deciding to do anything.

Option 1 is the best option for communicating process. You let the client know not only what has happened but why you believe the low bid was so high and the options for moving forward.
 
In both scenarios, talking to the client frequently and with full disclosure is your best option. It is not always the most comfortable option, but it is best for the client. Leaving a client in the dark and wondering about what is going on is never a good idea. Communicating the process is your best practice for keeping clients engaged and informed, even when the news is bad.
 
Additionally, communicating process with your colleagues is a good idea. When someone internally is waiting for you to complete a task or deliver information, communicate your process. Keep each other informed as to your progress or lack thereof. If someone emails you a request, let them know you received it and what your plan is for delivering. ​

The best technical engineers are not always the engineers chosen for a project. This is because even project owners buy experience. And they do not all buy the same experience, similar to coffee drinkers who may buy convenience, vibe, or flavor.
 
So, the marketing goal is to learn what experiences our clients desire most and find ways to deliver that experience. To gather this information, we must ask. We must have regular conversations with our clients and learn to listen to their preferences. Some clients prefer regular interactions and quick responsiveness. Others prefer technical accuracy and detail. Still, others prefer delivery on time and within their budget.

We have several avenues of discovery for client experience data.

1. Client debriefs – having a sit-down chat with our clients asking them specific questions about their experience.
2. Client surveys – an occasional email that gives clients an opportunity for a brief response about their experience.
3. Client meetings – while working on the project, listen for clues in what the client says about their experience working with you. Take note of their preferences.
4. Client emails – how does a client interact with you? What are they consistently most concerned about?

Taken together, debriefs, surveys, meetings, and emails should tell us a story about what our clients experience and what they prefer. The next step is gathering that data in our CRM as a database full of client experience. ​