In Part 1 of the Shortfall Series we introduced the topic of educating our Managers on what they need to know about S1000D to ensure you achieve the most from the technology. In Part 2 we discussed that the first and essential item to a solid implementation of S1000D is the BREX or Business Rules EXchange data module and Part 3 we reviewed the benefits and purpose of utilizing Common Information Repositories (CIRs) as soon as you kick off your S1000D Project. In Part 4 we discussed what you need to know about stylesheets for your S1000D Project and Part 5 was understanding the purpose of Applicability.
In this final week of the Shortfall blog series we are looking at how a review cycle in S1000D would work compared to the traditional print publication cycle of the past.
Within the project, the management team need to consider what is to be the Review Cycle that will be used for the project.
In the traditional publication environment the process is to write the content until a publication is completed and then Quality Assurance (QA) commences their review. As the review is completed the information is returned to the authors and they need to make the required changes as per the review cycle. The biggest issue with this process is that by the time QA returns the content to the authors, the authors may be on another project and they need to “flick the switch” back to the project. The review and update cycles are basically long!
With an S1000D project, the QA process can commence as soon as the first Data Module has been completed. We need to remember that a Data Module is a self-contained piece of information that specifically relates to the topic. Therefore you need to be aware if the Data Module is a specific procedure, then this is the only information that is contained in the file and delivered for review, i.e. Your reviewing person may not have the opportunity to read a procedure in the context of surrounding or referenced information, until those other content items are complete.
Again, as with all of our other topics, the QA process must be clearly documented in your project’s Business Rules. The QA process is not just your internal procedures, such as how the subject matter expert reviewers will review the content and provide feedback. Additionally the project should identify the quality/review process between the prime (yourselves) and your subcontractors vs suppliers and yourselves and your customer.
The review cycle needs to cover all of this information and how the communication will be achieved. We need to make sure that we include the methods that are to be used for the communication between all levels of the project. You do not want to have all members of the team communicating with all parties that are involved in the project. You want to have it clearly documented as to who are the authorised people that are able to communicate with the different parties involved in the project, and what automated tools such as Workflow and S1000D ReViewer tools that may speed up the review cycle even further.
So closing with our opening question from the first in this blog series – Does your manager know what your new challenges are when it comes to your S1000D deliverables? Do they understand the new methods of working in S1000D and what project decision and/or tools need to be decided upon before you start authoring?
Make sure we are educating our Managers on what they need to know to help US make decisions and tool choices that add value early!
