Participation, Education, and Cooperation: A model for overcoming organizational barriers to change

Home/Publications/Best Practices Newsletter/2010 – Best Practices Newsletter/Participation, Education, and Cooperation: A model for overcoming organizational barriers to change


February 2010

Participation, Education, and Cooperation: A model for overcoming organizational barriers to change

CIDMIconNewsletterTerry Barraclough, Symitar, a Jack Henry Company

Too often technical publications groups operate in isolation. In a typical process, product development teams design a new product, software engineers perform the coding, quality assurance teams test the product, support departments prepare their staff to support the release, marketing departments create brochures, and sales staff begins to pre-sell the product. When everyone else is done with their part of the process, someone thinks to ask, “What about the documentation?” Where is the technical publications department in this process? The technical writers have been working behind the scenes, starting from design documents, interviewing subject matter experts, and if possible, testing the documentation against the software. But few outside the technical publications department know what technical writers do, how they do it, or how long it takes. Products are designed and deadlines set without input from those tasked with documenting the product.

That model doesn’t lend itself to quality documentation and never has. How do you break down the barriers between technical writers and other groups? How do you get other departments to see the technical publications department as an equal partner in product delivery and support? How do you ensure that sufficient time for documentation is allowed in the product plan? In short, how does technical writing come out of the dark and into the light?

This is the story of how a small technical publications department has managed to overcome organizational barriers to increase their participation in product delivery, raise awareness of the requirements and benefits of quality technical publications, and encourage inter-departmental cooperation. Although this article describes the experiences of a small technical publications department in a relatively small organization, the principles apply to departments and organizations of any size.

The Department’s Vision

How do you get everyone in the company to assist in developing XML/DITA documentation for users and staff? How do you counter the misunderstandings and get other departments to take technical publications seriously? “We need documentation, but that’s their job.” “All they do is write!” “It’s not as important as development.” How do you gain understanding by and cooperation from other departments to make better documentation?

The challenge of any technical publications department is to get people to divulge their secrets: to get developers, trainers, and anyone else willing, to help create the best user documentation possible. This challenge is immense, but the opportunities are also immense, and it’s been very rewarding to see the department’s vision come to fruition.

So, how did we get where we are today? By applying three simple principles:

  • Participation
  • Education
  • Cooperation

But there’s another principle not yet mentioned: persistence. Our efforts weren’t an overnight success. We’ve been applying these principles for almost 20 years. We didn’t immediately get Development, or Support, or Training to jump right in and help us create better documentation, but we had small successes, and we’ve built on those successes to where we are now.

Taking a step backward for a moment, you have two choices to get things done, to get the people and tools you need to do them:

  • You can be the squeaky wheel, always complaining, or even building business case after business case to prove you need more resources, better tools, or
  • You can be the grease that helps everyone in the company succeed.

We chose to squeak as little as possible and grease as much as possible.


Let’s turn to the first of our three principles: participation. Just what does that mean?

  • Be everywhere.
  • Extend your tentacles throughout the organization and learn where other departments and management need assistance.
  • Determine your staff’s skill sets and how they can help others who might not be aware of the resources contained in the technical publications department.

Gain respect and credibility for your technical publications group, services, and projects by helping other departments. Participation helps bring you out of the background and into the consciousness of the company and other departments. Demonstrate your staff’s abilities and dedication to the company. Let everyone know what you have to offer, and offer it!


Show that you want to help. We have an annual client conference. Don’t you? Help is always needed (and appreciated) to assist in such a massive undertaking. At Symitar, all technical publications staff members assist with our conference:

  • Editing presentations
  • Assisting physically by running errands, picking up guest speakers at the airport, monitoring rooms (running sound checks, starting recordings, counting attendees, even simply holding doors for attendees)
  • Giving presentations (leverage the skills of the frustrated actors and trainers on the technical publications staff)
  • Running information booths to inform clients about current documentation and planned changes

There’s a bonus here: clients and vendors get to know you, too, and you get to know them.

Participate fully and wholeheartedly in company events, whether internal, such as company picnics, or external, such as charitable activities.


Offer the abilities of technical publications staff to assist with internal and external company communications. Start up or assist with company newsletters (internal). Start up or assist with developing and maintaining a corporate website (external).

Planning & Development

Help out where your help is least expected: Participate on product review committees. Offer your help with QA testing. If there’s a product under development that you know something about, offer to help with design specifications. Help with new employee orientation; ask for a chance to tell new employees about your documentation, and show them how to use it.

We have an ex-programmer on staff; he develops and teaches a course for new programmers. We have a certified business continuity planner on staff; he helped develop the company’s business recovery strategy and plans and runs mock disaster drills for our clients at our annual client conference.

I’m sure you can identify other areas where you can help the rest of the company.


Offer services to other departments, such as editing, designing documents and forms, creating templates, writing training—even voice talent for marketing webinars and training videos.

Working with Vendors

Don’t neglect your vendors. Treat them as partners. Provide feedback on your use of their products: what’s good, what’s bad. Give them your “wish lists” for enhancements to their products. Ask for training, advice, and demos on new products. And keep your vendors informed of your progress.

Results of Participation

What’s all this participation gotten us? Development now gives us early access to design documents. QA gives us their test scripts so we can develop our own test plans for our documentation. Other departments have offered assistance, even loaned us staff… but more about that later. One of our vendors, Just Systems, wrote an article about our department, and that increased our visibility both within and outside the company.


Next principle: education. Teach yourself. You’re heading off in new directions, so you need to teach yourself and your staff how to get there. Teach others. You need the support of management, other departments, your clients, and your vendors to achieve your vision.

Your goal is to increase understanding of XML/DITA writing, including completed, ongoing, and upcoming projects, and to continuously expand the understanding of what you’re doing, why you’re doing it, and what the benefits are to your own technical publications staff, to the company, to other departments, and to your clients.

Train yourself on writing in XML to the DITA standard and educate others on the benefits of XML/DITA documentation.

Self Education

You’ve got to train yourself to develop the vision, clarify goals, and identify tools. Train the technical publications department on XML, DITA, and minimalism. That includes all of your technical publications staff, so they can help you in these efforts as you move forward. Your staff needs to understand the value of this big paradigm shift, as well as how to use the new tools and techniques.

So, how do you train yourself? Attend conferences like those sponsored by CIDM (I don’t know of any others as relevant). Attend workshops and seminars on topics of interest. Read. Read a lot. Ask for vendor assistance, advice, and training.

Client Education

Train your clients about what you’re doing and make them feel comfortable with offering their suggestions. Inform clients of the advantages of XML/DITA documentation from their perspective. Take every opportunity to let your clients know you’re up to something:

  • Establish a forum at your annual client conference where you can share your vision directly and get client feedback.
  • Get in touch with user groups, and watch the knowledge spread.
  • Establish a client focus group

The best way to involve clients is to keep them informed, listen to what they say, and act on that input. And remember to keep them informed with announcements of your new deliverables. Be sure to cite the benefits to them and inform them how to use each new deliverable.

Staff Education

Keep other departments aware of your efforts and educate them on the benefits of XML/DITA documentation.

How can you educate the staff of other departments? Now that you’re participating on those product review committees, use that forum to inform the other members of the committees about the benefits of single-sourced information: “It would have taken us longer to deliver documentation for our new user interface, but since we’re now single-sourcing, we can reuse pieces of our existing documentation and not have to write this new documentation set from scratch. In fact, since the only real differences are in the interface and navigation, we’ve already got 80% of it written!”

Wangle an invitation to other departments’ weekly meetings, both to share your vision and to preview and announce your new deliverables.

Management Education

Educate your management on the benefits of XML/DITA documentation; inform them of your vision, your long- and short-term goals, and the benefits of single sourcing; and keep them informed of your progress. Ask for time at your monthly management meetings to get up there and share your vision, your plans for new deliverables, and your progress. Provide regular progress reports, emphasizing new deliverables and client and internal staff reaction.

Ongoing Education

Make the vision come alive to everyone in the company. Keep the vision out there for everyone to see. Use every means at your disposal, from the corporate website to published articles to everyday communications such as emails, phone calls, and water cooler conversations. Identify potential evangelists and provide them with “insider” information they’re bound to share. By continuing to communicate, make your vision a shared vision.


Where does that lead us? To our final principle: cooperation. Let other departments and groups, your users, and your vendors know you’ll continue to help them move forward with their initiatives, and ask them to help you move forward with your XML/DITA initiative.

How do you enlist the cooperation of others? Through education, if you’ve done it right, you already have them sharing the vision. Now they know where you’re planning to go and the benefits to them when you get there. Your vision of getting everyone in the company, your users, and your vendors to assist in developing XML/DITA documentation is truly shared, and you begin to get the assistance you need.

Quid Pro Quo

Remember those services you’ve been providing to other departments? The down side: Those services are now expected, and more and more departments want to use them. But is it really a down side? You may have increased your workload, but you’ve also increased your visibility and boosted respect for your efforts within the organization. Those other departments become allies in securing additional staff, or even loaning you theirs in a pinch … more in just a bit.

You’ve increased the volume of your editing workload by offering those editing services, but your writing training and the templates you created for other departments are improving the quality of the materials they submit to you for editing, and it’s taking less time to edit them.

You’ve not only gained the design specifications early on, but Development involves you earlier in the decisions on projects and considers your input more valuable than they did previously.

Other departments begin helping you gather requirement specifications for your documentation projects. Conversion trainers, Sales, and Support start telling you what they think your clients need in the way of documentation. And because they have closer ties to the client base than your department, you can better target your projects to meet real client needs.

Software engineers recognize your expertise and ask for your help designing and creating a searchable XML knowledge base. You tell them you’re going to need the assistance of their staff designing, creating, and maintaining that knowledge base; that you don’t have the resources to do it all for them. And they say “Sure!” because you have credibility. You’ve increased your resource pool without affecting your budget.

Sharing Staff

Share human resources among departments to complete projects more quickly and efficiently. Now talk about turning crises into opportunities! This horrible economic downturn has slowed sales, so some departments now have more staff than necessary to keep up with the installation schedule. Implementations of add-on modules are also falling off. Some unexpected things begin to happen:

  • The Conversion Training manager offers to loan you an experienced trainer for two months to help out with that new Teller Guide.
  • The Implementations manager asks if you could use one of her staff members for three months.
  • Your director calls you to ask if you’d like the services of an experienced project manager to help with that inter-departmental knowledge base project.
  • The Support manager gives you access to SMEs to assist in your development of user documentation. (They don’t have a staff surplus, but they see the value in what you’re doing.)
  • When you go to the next monthly managers’ meeting, you ask for SMEs to help QA test your new documentation deliverable. You tell the managers they’re going to have to commit their staff for at least half a day for a full week. The offers start coming in that day. In fact, on the way upstairs after the managers’ meeting, a manager offers the assistance of two of his staff. The QA test is a resounding success, with a number of corrections and additions made on the spot on the advice of the SMEs.

Securing Client Feedback

What about your clients? Are your new deliverables giving them what they need?

We’ve had in place for a number of years a “gotcha” program, in which we encourage staff to submit corrections or additions to the documentation set. The staff member submitting the most corrections in a given month is awarded a certificate of recognition and a couple of movie passes.

We extended that program to our clients a few years ago, awarding a recognition certificate and two movie passes to the client submitting the most gotchas in a month. Now the clients are helping us improve the existing documentation.

And, through communicating with client winners of the gotcha program over the past several years, we have identified those clients with a sincere interest in the quality of our documentation who are willing—even eager—to preview and critique our new documentation sets.

Our next step is setting up a client feedback group, and we’ve already identified our best candidates through the gotcha program.

Working with Vendors

Treat your vendors as partners. Provide feedback on how you use their products. Request enhancements to their products based on your needs. Now that we’re working as partners, when we request enhancements to their software, they listen, and when our requests make sense, they deliver those enhancements. Ask your vendors for referrals to other vendors with needed products. Provide referrals for your vendors. We stress our satisfaction with the vendor’s products to other departments… even to representatives of other companies we meet at CIDM conferences. And we’re not shy about endorsing their products in print.

How It All Works Together

Let me summarize this model for you:

Participation secures respect. It brings the technical publications department out of the darkness and secures respect from management, other departments, clients, and vendors.

Education keeps everyone “in the know” and helps us gain the tools we need to move forward.

Cooperation speeds progress, especially when it becomes true collaboration, as in our documentation QA testing.

It’s a continuous self-reinforcing loop. Keep participating, educating, and cooperating and the results are amazing! Here we are, just a few years later, and our contributions are known and valued within the company and by our clients. We’re seen as innovators, both within and outside the organization. We get help when we ask for it.

The organizational barriers to change are, for the most part, down and no longer an impediment to the progress of our DITA initiative. We’re no longer the red-headed stepchild. CIDMIconNewsletter

 Barraclough_Terry (groupshot)

Symitar Technical Publications (back row, left to right): Vince Gomez, Lisa Reyes, Ron Fauset, Geoff Crews, Chris Weber, Kathryn Showers, Vanessa Campbell; (front row, left to right): Todd Herrick, Kara Church, Terry Barraclough

Barraclough_Terry Terry Barraclough

Symitar, a Jack Henry Company

Terry Barraclough is Manager of Technical Publications at Symitar, a Jack Henry Company providing software to the credit union industry. He has over 40 years of in-the-trenches publishing experience, from preparing and marketing class notes in his college years at the University of Oregon, through composing abstracts of educational research studies, writing voter pamphlets, preparing documentation for community-based schools, and eventually writing, editing, and publishing technical documentation for computer software applications. He is a staunch advocate of XML authoring, DITA standards, and minimalism and has evangelized these subjects for more than three years.