New Characteristics for the IPMM


June 2010

From the Director

CIDMIconNewsletter JoAnn Hackos

New Characteristics for the IPMM

Since its inception in 1992, the Information Process Maturity Model (IPMM) has focused on eight key characteristics to evaluate a publications or training organization. Those eight key characteristics were, for a long time, sufficient to distinguish immature from mature organization practices. However, in 2006, when I published my most recent book, Information Development: Managing Your Projects, Portfolio, and People (John Wiley & Sons), I evaluated the need for additional characteristics, among them collaboration and change management, and added them to the model.

Change Management

It was clear by 2006, that change management had become central to the challenges faced by managers in implementing new processes and technology in their organizations. At the same time they pursued innovations to improve quality and decrease costs, managers faced pervasive change as a result of staff resource cutbacks and an increased reliance on global resourcing for staff. An assessment of management’s readiness to handle change and to institute reliable change-management techniques have become critical to their organization’s success and even its continued existence.

As a result, we chose change management as a theme for the 2009 Best Practices conference, referencing John Kotter’s A Sense of Urgency. At least one senior manager, recognizing the importance of encouraging staff members to embrace change, purchased 40 copies of Kotter’s book and used it to guide a change initiative.

In the IPMM assessment process, we reserve discussions of change management to our interviews with publications, training, and senior management. A more mature organization has instituted mechanisms to
help manage change and ensure the success of new processes and technologies.


In parallel with the introduction of change management to the IPMM, I recognized that the traditional organization of publications and training development was no longer viable. A traditional organization relies largely on individual contributors who were independently responsible for the development of a document or a training course. Staff writers and instructional designers generally work alone, responsible for all the planning, development, and production to complete their deliverables. In a few cases, larger departments employ production specialists to help get final products out the door. In training organizations that add multimedia to their course work, additional team members might create part of the course material. But, by and large, the organizational model that has dominated the field relies heavily on individual contributors.

Given the rapid reduction of staff resources in many organizations in the past few years and the pressure to “do more with less,” the traditional model of the “individual contributor” is no longer viable. Staff members must assume multiple responsibilities. Managers ask them to adopt new technologies, employ structured writing techniques, learn the DITA/XML standard to write topics, share content among deliverables, and work together to produce content more efficiently. Collaboration is inevitable.

Through our continued study of DITA XML/Content Management projects, we know that the most successful implementations are those that recognize that collaboration is a necessity. Without a collaborative work environment, return on investment is severely limited, primarily because nothing has really changed. New tools and technologies are used to replicate the existing work practices. As a result, little efficiency is introduced or actually put into effect. The most an organization might gain is reductions in translation costs, but those reductions are often countered by decreases in productivity for all the other activities.

With a collaborative work environment in which team members work closely together to plan, develop, review, and produce content deliverables, real change occurs. The return on investment can be spectacular. We have examples in our case studies of 80 to 90 percent reductions in the cost of development.

However, it is also important to handle collaboration correctly. In her presentation at the 2009 Best Practices, Charlotte Robidoux of Hewlett-Packard points to three kinds of collaboration:

  • Serial collaboration—each person contributes to a project in sequence
  • Parallel collaboration—each person contributes to a project in parallel
  • Collective collaboration—each person contributes to a project in concert with all the others

Serial and parallel collaboration are more commonly found in the traditional publications process and generally support a book paradigm. Organizations that have writers, editors, reviewers, and production specialists working on projects through a set of sequential activities practice serial collaboration. Organizations that have writers working independently on their own parts of a project practice parallel collaboration. However, collective collaboration is necessary if work is really designed, planned, and created by an integrated team. I refer to collective collaboration in the IPMM and for work associated with the effective use of a single content repository for multiple projects.

Collective collaboration is critical. It leads to increased innovation, because more ideas become available to the team. It leads to increased productivity, because work practices are optimized among team members, reducing duplication of effort. It forces teams to decide what work will deliver the most value to customers, so they are less likely to waste effort on information that no one cares about.

At Comtech, we used collaborative work practices with our information-development teams from the early 1980s through the mid 1990s, when we moved entirely to our consulting practice. One of my most memorable projects was strictly collaborative. We were called on a Thursday morning by a company that needed multiple user guides written for a series of new products. The problem – the user guides had to be ready by the following Tuesday. Luckily, the new products were online games developed for pre-schoolers. The user guides were intended for the parents.

How could we get this project off and running as quickly as possible, complete it on time, and develop an innovative standard for the parental guides? The CDs arrived on Friday morning. There were no guidelines for the user guides (the company hadn’t produced any before). The team of 6 writers, an editor, and the project manager held a short meeting to develop a plan of attack. With 18 games to review, each writer took three. The first assignment? Play each game and sketch out a user guide. Spend the morning on the sketches and meet after lunch to develop a standard.

The afternoon meeting took a few hours. Everyone presented ideas for the user guides. Together they decided on a standard approach that everyone would follow. Back to the games, each writer produced three user guides, which were reviewed by the editor and the project manager. By Monday afternoon (with some weekend hours required), we had 18 user guides ready to go, a day early. Just in time for a call from the company announcing that 18 more games were on the way.

The project was fun. I remember walking through the office to the tune of 6 preschool jingles playing at the same time. The project was 100 percent collaborative. The solutions were innovative and completed in record time. The software developer was very pleased.

Updating the IPMM Assessment

Although the original IPMM addressed collaboration as a goal of hiring, I believe that building a collaborative working environment must be addressed more specifically in our assessments in the future. The practice in which information developers work alone, responsible for defining and creating content based upon their interactions with subject-matter experts, can now be evaluated as a characteristic of an immature, Level 1 organization. A lack of collaboration is a key characteristic of an organization that develops information using ad-hoc processes. Given the need to share content among deliverables (single sourcing) and the need to ensure that customers receive consistent and complete information to guide their performance with a product or process, information developers must become increasingly collaborative in their working environment. It is no longer acceptable for writers to work in isolation on their proverbial mountain tops.

In Chapter 20: Managing in a Collaborative Environment, in my Information Development book, I present business best practices for establishing a collaborative environment at the project level. These best practices suggest that by working together to plan, design, and develop content, we both reduce development costs and increase quality.

Change management offers another opportunity to develop a new key characteristic for the IPMM. Because I expect mature organizations to be continually innovating, challenging the status quo, and embracing continuous process improvement, managers must understand how to manage change effectively. Without change management in place, organizations risk having team members refuse to embrace innovations or deliberately avoid adopting an innovative practice in their own work. When people do not understand the business necessity behind a new practice or design and do not understand how the innovation will affect their personal work practices, they reject or undermine the change.

A mature information-development organization must be prepared to manage change effectively if they want the pursuit of innovation to become a hallmark of their work. CIDMIconNewsletter



JoAnn T. Hackos
Information Development: Managing Your Documentation Projects, Portfolio, and People
2006, Hoboken, NJ
John Wiley & Sons, Inc.
ISBN: 9780471777113

John P. Kotter
A Sense of Urgency
2008, Boston, MA
Harvard Business School Publishing
ISBN: 9781422179710