Reorganising Information Developers to Support Topics
Xylem (a company spun-off from ITT) has been running a very successful implementation of structured authoring since 2007. During this period, we have managed to reduce translations costs per language by approximately 90 percent, reduce external consultant costs by a similar amount, and generate a huge amount of additional output with a similar number of resources. However, our success has come from always striving to stay on the leading edge in terms of processes.
Since 2007, we had changed how we worked, the technology we used, and rewritten a large amount of our content. But these changes had never been supported by a true organisational change or realignment. In many ways we had succeeded in spite of not carrying out these important structural reforms. We had a central team of five people supporting training, tools development, support, global content, and localisation. But the technical writers were part of the many local sites and organisations that make up our business. The people who worked on the structured writing implementation believed that a change was needed. The change was to bring together the technical writing resources that had been working on our DITA implementation under one global organisation, instead of reporting into each of their local organisations. The main goals for the change were
- more efficient scalability
- maintenance of quality and cost savings
- improved motivation
- improved delivery and efficiencies
More Efficient Scalability
Xylem owns a large number of brands, most of them leaders in their various segments and markets. However, each of these brands often operates almost as a separate company within Xylem. As a result, to spread our structured writing implementation throughout the organisation, we in effect needed to repeat an implementation project for each of these brands. Whilst we have the technology and processes to bring these sites quickly up to speed, in our old structure we required a person or team at each of these brands to take the role of technical writer, documentation manager, and information architect. These sites were often small and did not have even one full time resource dedicated to technical writing. We could not provide this support centrally as we had no technical writers in the central group. As a result, an implementation would require a heavy use of external writing consultants—creating a significant barrier for us to spread our benefits throughout the business. In the new organisation in which we have a pool of writers, we can flex the central organisation and share resources across brands more easily and thus bring new brands on board more quickly and efficiently.
Maintenance of Quality and Cost Savings
We managed to increase the quality of our documentation by ensuring that writers follow a very well designed set of processes and guidelines. These processes also ensured a high level of smart reuse. As the group of people working on our system grew, ensuring people followed this way of working and enforcing it became harder. This problem threatened, gradually over time, to undo all the benefits we had achieved. By forming one global organisation, the whole team now feels the responsibility to drive the processes and promote reuse—it is no longer solely the responsibility of the central team. Furthermore, there is now accountability. If someone does not follow the processes, we have the authority to enforce compliance because the writers report to a global team as opposed to local organisations.
The writers at the business organisations had limited growth potential. By forming a global team, they now have the ability to expand their knowledge and responsibilities, if they wish, to other areas, such as development of the tools, refining of guidelines, and expertise in graphics. These opportunities ensure that people continue to be challenged to grow, and it helps retention rates. It also means that we can better use the skills and resources available by matching interest and ability to the functions required across a larger group of people.
Improved Delivery and Efficiencies
In spite of the significant cost savings and efficiency gains we had made, we were looking at the next level of improvements we could deliver. On-time delivery was the number one concern for the business. By creating one global team and having each writer focus on more than one group of products, we will be able to work collaboratively on documentation and treat the work as a series of projects.
The Project Approach—Lean Manufacturing
By having the team focus their work on topics and not products, we can now have multiple writers working on one documentation project at a time, hence reducing the calendar time required to deliver a project. Reducing the project times in this way is at the heart of lean manufacturing philosophies. By implementing some of these principles, we will be able to gain the following advantages:
- Start development work on projects later—by starting later on the projects, we can actually be confident that there will be fewer changes requested by the subject matter experts because the product should be much more stable at a later stage. This practice reduces the wasteful and unproductive multiple updates to the same content before release.
- Improve quality feedback loops—shorter projects mean we remember and apply any learnings from each project more rapidly and effectively to the next project.
- Optimise resources—we can ensure we have the best people for each project task.
- Improved control—working collaboratively on projects forces us to have a much more controlled and disciplined approach to planning the documentation, which ensures that we better meet our internal customers’ needs and are better able to keep them up to date on progress.
Convincing senior management that this was the correct approach is out of the scope of this article. However, moving into a new organisational model and updating our processes required significant change management to ensure true success and internal buy-in of the change. Here are some of the key steps we took:
Joint Development of the New Organisation
The new team decided together what we needed to do, how to combine, and how our new processes should look. It was NOT a top-down approach, but a true collaborative effort. Consequently, there was no need to sell the idea to the team—they owned the concept from the start. We held a number of meetings and workshops to understand why we felt a change was needed, what we wanted to achieve, and how our new world would look. The team developed the new process and the new role descriptions. Each member of the team was able to decide what roles they were most interested in and most were able to take on at least some of these roles in the new organisation—aligning skills, wants, and needs.
To help us understand the impact of the new roles and processes, we set up a number of role playing activities to see how a development project in our new world would look. The role playing consisted of one-hour sessions in which the team would pretend to develop a manual and have to deal with a number of scenarios to collaborate effectively and deliver to the customer on time. The role playing was an eye-opening experience that let us refine our processes and roles.
We worked together to identify the risks to our new plan and put actions in place to minimise and address these risks. Risk analysis was a key tool to ensure that our senior management had confidence in what we were doing.
We realised that our change would impact not only us, but also our partners and customers. As a result, we developed a robust communication plan and executed it in parallel with the formation of the new team. The communication plan focused first on identifying who our stakeholders were. From there, we decided what the opportunities and challenges our change would pose to these stakeholders. Based on this analysis, we developed key messages that we agreed we wanted to deliver to each of these groups. Only then did we decide what medium to use to communicate with them and developed the content for it, following the same user-centric approach that we use for our documentation.
We are still in the process of moving our way of working to a true project philosophy. But the changes we have made in this direction have already started to pay off with greater collaboration, control, and visibility of the work we do.
Vikram Nanwani, CEng, is the Manager of the Technical Documentation Group at Xylem (a company recently spun off from ITT). He has driven the maturity of DITA at the organisation through pilot, implementation, migration and production phases to the core business process it is today. He has used his background in Manufacturing Engineering, international project management and Lean Six Sigma to bring new perspectives to the documentation processes at Xylem.