Home/Publications/Best Practices Newsletter/2012 – Best Practices Newsletter/Moving Information Development from a Push System to a Pull System


February 2012

Moving Information Development from a Push System to a Pull System

CIDMIconNewsletterEmily Mydlowski, Hach Company

As part of a manufacturing company, lean manufacturing principles are a standard part of business and a means for continuous improvement. In the Information Development Department we looked at how we could use some of these principles to better serve our internal and external customers. We focused on moving away from a push system and into a pull system to help us produce high-quality content Just-in-Time for our customers.

A push system is one that schedules services based on projected need and is worked on whenever material becomes available regardless of the actual requirements of the next process or whether the downstream resources will have capacity to begin the work. In a push system, work is done Just-In-Case and can result in overproduction, rework, long backlogs, and increased wait times.

A pull system controls the flow of work by starting a service as the customer needs them and when the materials to produce those needs are available. In a pull system, work is pulled when the hand-off between parties is timely, complete, and accurate and when capacity is available as dedicated resources. In a pull system, every piece of the process follows others without negatively impacting another deliverable. A pull system is a Just-In-Time system and typically includes other process methodologies such as One-Piece Flow and First-In-First-Out work systems.

In Information Development, signs of living in a push system can be

  • having all work in progress with people allocated to more than one project.
  • you spend more time waiting for inputs to be delivered or tracking down your
    missing inputs than actually producing content.
  • original due dates are not met, durations are long yet the actual time spent on developing content is short.
  • there are too many changes and too much rework.
  • getting feedback from your SMEs during reviews is a challenge and you typically find yourself on the impact chain right before a product launch.

Daily work for a manager may feel like “chaos management” and stress is typically high for a content developer.

By implementing a pull system, we control the work coming into our system and only pull work into the system when the necessary inputs to do the job are delivered. Only one project per resource is assigned and work is pulled based on a First-In-First-Out policy. By implementing a pull system, we now meet our commit dates. Our throughput has increased while our durations decreased. Our durations turned to focus durations which has led to an increase in the quality of our content. Our backlog decreased and so has the wait time to pull a project from backlog into work.

By moving to a pull system, we allowed our team to understand the financial impact we had on new product development and sustaining efforts. It provided us with clear metrics that consistently assess our progress and pitfalls. The data and metrics that we collected both pre- and post-implementation helped to facilitate the business conversations and investment in a DITA-compliant Component Content Management System (CCMS) and Translation Management System (TMS) solution. It allowed the team to improve and streamline the documentation development process but most important, it provided us the reserve capacity to be innovative and focus on the customer.

Moving to a Pull System

Step 1: Collect Baseline Data

We first needed to understand our situation and collect baseline data that was meaningful within our organization. This data helped us to understand the impact we had (both good and bad) on the organization and provided the measurements necessary to validate any process or technology changes that we wanted to implement. The data that we collected included On-time Delivery (OTD), project durations (including cycle time), throughput (how many documents completed in a year), backlog wait time, translation costs and durations, and internal and external customer feedback.

Step 2: Eliminate Bad Multi-tasking

Yes, multi-tasking is not always an asset. In fact, bad multi-tasking can have a serious impact on OTD, project durations, wait time, costs, and throughput. Bad multi-tasking is defined as any multi-tasking that lengthens the duration of a task. Eliminating bad multitasking allows resources to focus on the right stuff at the right time.

To eliminate bad multi-tasking, we implemented the shopping cart priority method and started to control what came into our system. If you had everything you needed in your cart, we checked you through the department/line as quickly as possible. If you left half your groceries on the shelf, you would be asked to leave the line and return to the back of the line when you had all your goods (inputs). Like the cashier, each writer and illustrator could only be assigned one project (customer) at a time. This method also allowed us to move to a First-in-First-Out Priority Process. If your place in line was not to your liking, you needed to negotiate with those in the front of the line to trade places.

To implement the shopping cart priority, we first

  • defined the deliverables from the information development team that brought the most value to the organization and the customer
  • defined the minimum inputs necessary to produce those deliverables with high-quality and quick turnaround

By establishing minimum requirements at the beginning and controlling the funnel to one task per resource, we were able to complete work faster with better quality and eliminate the “writing by review” behavior. Instead of sending out multiple review cycles in hope of acquiring input and information, we could take the complete input package and produce an 80-90 percent-complete first draft for SME review and out-of-box pre-beta testing. We went from 5-6 reviewers per document to only two drafts for the entire document life cycle. This reduction in review cycle time also enabled project managers to plan for these two reviews so that SMEs could also be dedicated resources to that step in the development process. We started to see a significant increase in the feedback from our SMEs, and the quality of redlines increased substantially.

Step 3: Apply the Theory of Constraints

Once we had our grocery line (project funnel) flushed out, our throughput was increasing but our backlog wait time was still too long. We had an increased demand for our services; yet, we continued to be a constraint within the organization and always ended up on the critical path of a project. Once we added global launch requirements, we knew additional changes were necessary to meet the demands of the organization and to continue to operate in our pull system.

Maximize the Productivity of the Constraint To maximize the constraint (in this case, Information Development); you want to get the most out of the constraint’s process. At this point, we had controlled the work coming and going out but knew we needed to focus on how we could maximize the content being produced. We focused on three key items: (1) Translation Memory Management, (2) Minimalism with Non-Verbal Instructions, and (3) Task-based writing vs. Feature-based writing.

Translation Memory Management System (TMMS): By implementing a TMMS, we started to see our translation costs go down, but we still needed to make bigger changes to reduce the impact we had on project schedules and reduce the high costs of translations.

Minimalism: We approached minimalism from two points of view—write better text, but most importantly, focus on how we could leverage our technical illustration expertise. We implemented a non-verbal solution that has been well-received by global customers and has moved complex text descriptions into easy-to-use, step-by-step illustrated procedures. Not only did it improve our customer’s experience, it also helped reduce our translation costs. Many projects that once required text translation now turned into all-illustration projects that eliminated the need for any translation.

Task-Based vs. Feature-Based Writing: Without fully implementing a DITA CCMS, we focused our attention on turning our content into topics and started to write our content based on the
DITA structure. We focused our attention on the Task Topic. In the past, our manuals did a great job detailing all the features of a product but did not always provide the customer with the information necessary to use the product. By breaking down our content into Task-Based vs. Feature-Based writing, our engineers and product managers finally started to see the usability impacts of this content deliverable.

Subordinate All Other Processes to the Constraint Once we had moved to leaner documentation and documentation creation process, we prioritized projects in the organization based on how the constraint (information development) could pull the work through. Work is only allowed into the system at a rate that the constraint is able to pull it through. The immediate reaction was that the constraint (bottleneck) had to be removed immediately, so we moved into elevating the constraint.

Elevate the Constraint

To elevate the constraint, you increase its capacity. If the system cannot meet the task time, excess capacity is needed to accommodate variations in the system. To elevate information development, we focused on increasing our capacity by integrating a DITA-compliant CCMS that would integrate with our Translation Memory Management tool and by adding contractors to the department.

We gathered all the data that we collected by moving from a push to a pull system and applied company performance indicators. Even though we had made substantial changes in our process and had measurements to show that our OTD and throughput had increased, the impact on product development and product costs (from translations) was still too high. We built a business case that would take us off the critical path and get us to global markets 30 days faster by reducing the cost and time to deliver multi-lingual content for product launch. Because we had a clean pull system to start with, we had the reserved capacity necessary not only to meet the needs of our customers but also to implement new tools and technologies that would increase our throughout, reduce translation costs, decrease durations, and increase the quality and usability of the content.

Once a pull system was fully implemented, and we increased the productivity of the Information Development group by adding technologies and capacity, we reached our goal to get to global markets 30 days faster. Throughput increased substantially. A small team of four and a half writers and three illustrators is now producing at least 160 new documents per year with 100-150 updates to existing documents.

By elevating the constraint, it also gave us the reserved capacity to be more innovative and live in a continuous improvement environment. This environment has allowed us to integrate more quality steps into our process and continue to test-try-and-implement lean process improvements. These techniques provide us with more flexibility to meet the needs of our customers and be creative in our documentation strategies.

After all the process changes we made locally and the more end-user documentation became highlighted within the development process, our documentation became a measure for quality verification and validation of system product design. We integrated usability testing of our documentation as a key quality assurance step and a requirement to launch new products into production. In return, we have received fewer customer complaints (internal and external) about our documentation both during Beta Testing and Final Production. The product designers, quality assurance, product management, and information developers are all involved in usability testing. By involving all the stakeholders in the quality assurance step, more designers are enhancing the product rather than just adding another topic, important note, or warning into the documentation.

Summary of Results

I’ll be honest; moving to a pull system was not an easy task. It was a significant change that had to be managed and required perseverance and ownership. We didn’t start to see the buy-in until product development teams started to live through the process. Living through the process was our best influencer. It helped us gather the data necessary to show the progress of the change. We started to build support and momentum project after project.

Because we had the baseline data, we were able to measure our performance. These numbers continue to tell a process improvement success story (see Table 1).

Performance Indicator Push system Pull System
On-Time Delivery 30 percent 95-100 percent; meeting commit dates
Project Durations 2 months 15 days
Backlog Wait Time 3 months 3 weeks

Table 1: Before and After Comparison

Additionally, we started to save more than 40 percent in translation costs and reduced our translation duration from 70 days to 20-30 days.

Moving to a pull system not only enhanced the team’s performance but it also gave us the leverage to show the value that documentation can have within our organization. By enhancing our performance, we also increased the usability and flexibility of how we distribute content to our customers. Developing documentation strategies and implementing those strategies was fun and became a creative process because we had the flexibility and the reserved capacity to be innovative. The team’s happiness index is at 80 percent and still trending up. As a manager, I can say “yes” to things I used to have to turn down due to time and capacity constraints. All this was accomplished by making a few process improvements and by changing the value of when, how, and where information development is pulled into development. CIDMIconNewsletter

 About the Author

Emily Mydlowski

Emily Mydlowski
Hach Company

Emily Mydlowski is the Manager of User Experience and Information Development Department at Hach Company, which is an environmental water quality company that manufactures and distributes analytical instruments and reagents used to test the quality of water. She manages a team that delivers global documentation in 28+ languages to water industry customers. Emily has 10 years’ experience in the Technical Communications Industry. In her role at Hach Company, she has integrated project management methodologies, defined processes and implemented technologies that have improved on-time delivery, reduced costs and increased quality for Hach’s global end-user documentation.