Article by Mark Noseworthy, Group Engineering Manager at E Tech Group
Providing accurate and timely project documentation is the backbone of excellence in the engineering world. Each engineering project may require the creation of a variety of documents during its lifespan, and each document may have several stages of release. Mark Noseworthy has written and technically reviewed hundreds of documents in his two decades of work as a senior project engineer. Here, Mark shares his insights on how to save time and produce better quality project documentation:
WHEN REVIEWING ENGINEERING DOCUMENTS, ASK YOURSELF A FEW SIMPLE QUESTIONS:
- Is this the first time that the document is being reviewed?
- Is the subject matter known to you?
- What is your role in the review?
- Are you an engineering technical reviewer?
- Are you a technical writer?
- Are you a validation or quality representative?
- What stage of the review is the document?
- Is this an initial draft to release a vendor to start or continue work?
- Is this for final approval?
- Initial release?
- Operational release?
Each of these questions merits varying degrees of engineering technical review, and are in many ways intertwined. Here are some standard ground rules that should be followed for every review.
- When using Microsoft Word, ensure that the Track Changes feature is on. Other software may have similar means to track updates and these should be used where appropriate. I know that the Microsoft Excel version of Track Changes leaves a lot to be desired, so I usually highlight cells that I’ve commented upon.
- “Don’t sweat the small stuff.1” Reviewing a document doesn’t happen in a vacuum. There are often multidisciplinary reviewers from a wide range of backgrounds and job responsibilities that will catch errors that you don’t see.
- “Don’t let perfection be the enemy of good.2” This is a quote from a peer and friend on a three-year project recently finished. If there is verbiage in a document that conveys the idea meant to be conveyed, and it is technically correct, but could be worded just a little bit better (i.e. wordsmithing), resist active change. It is good enough. If you think it merits a comment, then reach out to the author. If it is confusing then talking to the author likely will clear it up, without having to make a change.
Here is one engineer’s answer to each of the bulleted questions. Disclaimer: I am not an editor, but I have written and technically reviewed hundreds of documents over my 20+ year engineering career and have picked up a few things.
IS THIS THE FIRST TIME THAT THE DOCUMENT IS BEING REVIEWED?
If the answer is yes, then unfortunately you will need to read and review the whole document. If the answer is no, then it depends on the stage of the review that you are in as to how much of the document should be reviewed. I’ll explain the details of the review based on the stage of document development below.
IS THE SUBJECT MATTER KNOWN TO YOU?
I would argue that the more familiar you are with the subject matter, the more time you should spend on the review. As with the first question above, the effort taken to review the document should be commensurate with the stage of the document development. For instance, a technical writer reviewing an engineering document written by an engineer might not understand the technical content of the subject matter but brings value to the review by knowing how to convey complex ideas simply, as well as providing grammatical assistance.
When reviewing something that doesn’t make sense, make a comment at that point, and follow up with the author for clarification. They should be able to explain it, and that explanation likely will improve the verbiage used such that it is understandable. In some cases, however, the complexity is required to be kept due to its technical nature. This is ok; providing the audience of the document is meant to be technical in nature. This leads us to the next question:
WHAT IS YOUR ROLE IN THE REVIEW? ARE YOU AN ENGINEERING TECHNICAL REVIEWER? ARE YOU A TECHNICAL WRITER? ARE YOU A VALIDATION OR QUALITY REPRESENTATIVE?
Each of these (and other) roles are part of the review cycle as each of the reviewers brings something different to the table base on their role. Since this article is about engineering technical review, I’ll concentrate mostly on that role. Performing an engineering technical review depends somewhat on the type of document that is under review.
A Functional Specification or Configuration Specification contains lots of technical jargon, requiring an understanding of both the technical content as well as the structure of the document. Was the document written for GAMP5 processes? Was it structured for S88 batch context? Knowing these will help in your review by knowing the expectations of the document, and ultimately the project.
Compare this to reviewing a Standard Operating Procedure (SOP). An SOP is a series of steps written for an end user to follow along to operate a piece of equipment or run a process. The level of engineering technical review for this type of document requires some process knowledge, and automation knowledge if automation is involved in the SOP. An SOP should be reviewed as if the reviewer were executing the procedure. Review the steps of the SOP to ensure they flow in a logical manner.
WHAT STAGE OF THE REVIEW IS THE DOCUMENT? IS THIS AN INITIAL DRAFT TO RELEASE A VENDOR TO START OR CONTINUE WORK? IS THIS FOR FINAL APPROVAL? INITIAL RELEASE? OPERATIONAL RELEASE?
The review process for each of these options changes based on the stage of the review. Performing an engineering technical review of an initial draft of a document to release a vendor to start or continue work should be thorough enough to capture big ticket items such that the vendor understands the scope of the project without being bogged down with grammatical corrections that will be cleaned up in a more final version. The object of this stage is to get the vendor off and running with the project with a firm understanding of the scope.
INITIAL DRAFT
The level of effort of an initial draft should be reserved to a thorough review of the technical content. With automation, it is often not known what the operating parameters are at the outset of the project, as those parameters are developed for the first time in a Greenfield-style project, or simply fine-tuned in an upgrade to an existing control system, whether that be a small component or the whole automation system.
There should be considerable communication back and forth between the document writer and engineering reviewer to hash out the fine details (as available as they are) that need to be incorporated for stated work to get underway. These communications can take the form of email or phone conversations for small items, and can rise to the level of facilitated reviews, depending on the urgency of the project, the complexity of the questions and the availability of the author/reviewer. Meeting in person or via video/audio conferencing is a great way to get a lot accomplished in a short time. Prepare by providing the questions to the author first, so they will have time to craft an appropriate response.
INITIAL RELEASE
Performing an engineering technical review for approval of an initial release of a document requires, once again, a thorough and complete review. Everything is on the table, from technical details down to grammatical mistakes. Whether the vendor tracked changes to the initial draft version or not, the recommendation of this author is a thorough review of the entire document. This is the version that usually gets turned over to the customer so the vendor can start commissioning the changes to the system.
OPERATIONAL RELEASE
Performing an engineering technical review for approval of an operational release of an engineering specification requires a review focused on the changed content of the document. Even if the engineering reviewer is new to the document, the document has gone through at least one, if not many review cycles, and re-reviewing the entire document in excruciating detail is not a good use of time. Instead, review the revision history of the document to determine what has changed. Verify that each change was made per the revision history, and that no erroneous changes were made that did not make it into the revision history.
TOOLS
When reviewing a Microsoft Word document, utilize the built-in tools at your disposal. Use the Split Window under the View header to split the revision history from the rest of the document. Utilize the Next/Previous change options under the Review header to cycle through the changes to ensure all changes were captured in the revision history.
To focus the review on the content of the changes, one may want to disable the formatting option under the Show Markup drop down in the Review header, such that content changes are not buried amongst the typically numerous document formatting changes.
At the end of the review, change the Review header option from “All Markup” to “Simple Markup” which will make the document look as close to final as possible. Skim the document for other errors, such as unusual page or section breaks, document structure (GAMP53, S884, etc.), header/footer formatting, and ensure that the new revision number and date of the document are consistent throughout.
IN SUMMARY
Be smart about what is being reviewed. Everyone’s time is short, so developing a few guidelines on how to review documents will be key to continued success. Knowing which stage of the document review cycle you are in, whether you have seen the document before or not, and what your role in the review process is, will go a long way to an efficient and thorough document review. Ask questions of the author whenever possible and resist change for the sake of change. Remember; “Don’t let perfection be the enemy of good.”
Resources
1From the book Don’t Sweat the Small Stuff, P.S. It’s All Small Stuff by Michael R. Mantell, Ph.D.
2Courtesy of Voltaire.
3ISPE’s Good Automated Manufacturing Practice (GAMP) Guide for Validation of Automated Systems in Pharmaceutical Manufacture
4S88, shorthand for ANSI/ISA-88, is a standard addressing batch process control.