|
The Commerce of Content
|
Project Management | People Management | Business Management | Information Design Models, Processes, and Techniques | Home |
|
How can you help others in your organization see technical communication products and services as a strategic part of your business effort? Begin each projects by identifying the business objective that the communication effort should achieve. This article, originally published in the third quarter 1998 issue of Technical Communication, the journal of the Society for Technical Communication, is a tutorial that describes how to develop such objectives. Note that this article is reprinted with permission. Saul Carliner |
If technical communication products are ultimately intended to contribute to an organization’s business performance, why doesn’t our methodology have a means for explicitly stating how these communication products are supposed to do that?
Through my article, "Demonstrating the Effectiveness and Value of Technical Communication Products and Services: A Four-Level Process," (third quarter 1997 issue), I started suggesting ways that we might start to do so. Specifically, the third level of that model assesses client performance, or the way in which a technical communication product has an impact on the bottom line of an organization. For most technical communicators, our clients are internal to the organization, such as the programming group or the marketing group that funds our services. For the rest of us, our clients are external to the organization. Whether we work internally or externally, we work in a client-provider relationship.
In that article, I stated that an assessment of client performance
assumes that, before we began developing the communication product, we identified the business goals it was trying to achieve and attempts to measure the extent to which the communication product was able to meet those goals....
[That is,] we [must] identify a business measure when we first plan a communication product for a client. Once we identify the measure and the client agrees to it, we must also follow the changes in that measurement. We usually begin doing so before publishing the communication product and continue doing so long after publication. We measure changes over time, rather than at a single point in time, because the purpose of most business goals is facilitating a change over time, such as an increase in revenue or a decrease in expenses. Unless we track the trend in these measurements for a period before publishing the communication product, we cannot, with any credibility, assert that introducing the communication product caused a change in business performance.
Although I made these assumptions, I knew that little had been written for technical communicators on how to identify the business goals of the projects we work on, or how to write those goals in observable, measurable terms. When we prepare goals in observable, measurable terms, we call these goals objectives.
This article is intended to fill that gap. It first describes the challenges of setting business objectives for a project, next describes the three ways that a performance improvement program can contribute to the business performance of an organization, and then explains how to write a business objective. Last, this article describes the benefits of writing business objectives.
Let’s be honest. Most clients¾ whether the internal departments that most of us serve or the external customers that the rest of us serve¾ rarely think in terms of the bottom line when initiating a technical communication product. Instead, they’re thinking of an immediate need.
In some instances, clients initiate a request for training or another performance improvement program as a reflex action. For example, when software developers design a new application, they automatically initiate a request for a new user’s guide and help system. When human resource administrators initiate new policies, many automatically design a new form and a management briefing. When a nonprofit organization wants to initiate regular communication with its members, it usually launches a newsletter. These choices might not be appropriate, but have become so ingrained that they are as automatic as breathing. In such instances, clients often view technical communication products as collateral: a cost of doing business, rather than a potential contributor to the bottom line.
In other situations, clients request technical communication products to solve an immediate crisis. For example, when users overuse a support line, organizations hope to fix problems with the software or other product by improving its documentation. In such situations, clients certainly recognize that poor performance affects their bottom line, but rarely calculate the exact amount. Their businesses are hemorrhaging and they want the hemorrhaging to stop.
Because clients rarely think in terms of the bottom line when initiating a technical communication product, neither do we. Instead, we only focus on the tasks that the program is supposed to address, not the impact of those tasks on the bottom line of our client’s businesses. Because we fail to show the relationship between these tasks and the bottom line, our clients rarely know how to do so.
Technical communication products can have one of the following relationships to the bottom line of organizations.
As part of our initial investigations of situations, we need to assess the primary type of business impact intended for our technical communication products. Will they generate revenues? Contain expenses? Help the client comply with regulations?
We can best ensure the success of a technical communication product by establishing a single business goal for it. Clients often hope that a single body of information can serve several purposes. But the two business goals might be incompatible with one another and ultimately jeopardize the success of the program.
After clarifying the intended business impact of the technical communication product, we need to state it as in clear terms or SMARTly: specific, measurable, attainable, realistic, and trackable. When we state a goal in such terms, we call it an objective.
As we identify tasks when we first develop technical communication products, so we should write business objectives before we develop them. By writing the objective before we develop the communication product, we always have the end in sight when we bury ourselves in development.
Similarly, we should write business objectives before we identify the tasks. By writing the business objectives first, we can always keep the business goal in mind and more likely align the content of the communication product with the needs of the business.
Business objectives contain three elements.
Also state other conditions that affect the ability of a client to achieve a business goal. For example, if the technical communication product tells users how to use certain application software and the application software is not ready on schedule, then the technical communication product cannot have the intended impact on the stated schedule. Another term for "condition" is a dependency; that is, when the ability to achieve our goals is dependent on some other event or activity that is out of our control. Naming that dependency when we state a business objective not only identifies the conditions necessary for success, but also educates our clients about that their work is interrelated with ours.
An example of a business objective is:
Increase sales 5 percent by June 30 through sales representatives’ use of "The Calculator Program."
The goal is "increase sales ... through sales representatives’ use of ‘The Calculator Program.’" The condition is "by June 30" and the level of performance is "5 percent."
Examples of good and bad business objectives.
Immediately after writing business objectives, we should identify business measures that we can track to determine whether our communication products meet their business objectives. By identifying these measures immediately after writing the objectives, we provide ourselves a mental image of business success to guide us when we design and develop the communication products.
We can use existing measures of business performance to quickly assess the business impact of our work. For example, to assess the objective "increase sales 5 percent by June 30 through sales representatives’ use of "The Calculator Program," we could track sales records from a time before the Calculator was introduced to June 30 to see if sales did, indeed, increase by 5 percent.
Using existing measures of business performance has two advantages. The first is practical: it reduces the work we have to perform. Someone already tracks this measure; all we need to do is follow it. The second is political: we track the business performance of our work using the clients’ own business measures: the clients’ own value system.
Using existing measures of business performance also presents concerns. The most significant concern are the following.
These concerns are valid, and should be directly addressed in the plans for the assessments, so that clients are aware of the limitations.
As mentioned earlier, clients rarely think in specific terms about the business impact of technical communication products. (OK, they whine about the expense, but they hardly ever assist in developing the measures.)
Let’s provide business objectives anyway.
Doing so serves two purposes. First, it helps us focus align our work with the business needs of our clients.
Second, doing so educates clients. Providing business objectives in our instructional designs is one of many ways we can tell clients that our success is mutually entangled: only when our clients succeed in meeting their goals do we succeed in ours. Our technical communication products are ultimately intended to help clients achieve their business goals. The more effectively we demonstrate that link, the more likely our clients will transform their view of our work as an expense to a critical asset.
(Also see the case study for a real world example of the use of business objectives.)
Project Management | People Management | Business Management | Information Design Models, Processes, and Techniques | Home
(c) Copyright. 1999, 2000, 2001, 2002. Saul Carliner. All rights reserved.
