Developing a Communication Strategy for a Research Institute
Bill Pollak
Anne Humphreys
For an organization with a broad mission to improve the state of the practice in a domain, effective communication is essential. Our team developed a communication strategy for creating clear and consistent messages and for making the best use of resources for communication work. Our communication strategy defines products and internal processes for optimizing communication with our most important stakeholders, organizational decision makers in the software engineering community.
Background
The Software Engineering Institute (SEI) at Carnegie Mellon University is a federally funded research and development center with a broad mission to provide leadership in advancing the state of the practice of software engineering to improve the quality of systems that depend on software.
In early 1997, shortly after completion of an institute-wide strategic plan, the SEI changed sponsorship from the Defense Advanced Research Projects Agency to the Office of the Under Secretary of Defense for Acquisition and Technology [OUSD (A&T)].
When a team from OUSD A&T reviewed SEI work, the team expressed strong support for the SEI strategic plan and for many of the products and tools that the SEI produces. However, many review team members observed that they previously did not know that these products and tools existed (1).
To some extent, it was not surprising that our new sponsor would not be as familiar with our work as our previous sponsor had been. But the sponsor’s concern with communication also alerted us that we had to do a better job of telling our story and making sure that the story was heard by the many constituencies we serve.
The SEI’s new director, who had begun his tenure the previous year, concluded that the SEI needed a communication strategy, and he formed an SEI Communication Strategy Team. The purpose of the team was to
- Develop a strategy for creating a clear and consistent message to our stakeholders and for making the best use of resources for communication work.
- Understand the needs of stakeholder communities and provide them with an array of products tailored to those needs.
- Simplify our core messages and present complex technical work simply and consistently.
In this paper, we will (1) explore the nature of a communication strategy in the context of technology transfer; (2) briefly summarize the process that we followed in developing a communication strategy for the SEI; and (3) share lessons learned that we hope will be useful to others involved in strategic planning efforts.
Communication and Technology Transfer
Communication is central to the SEI’s mission of technology transfer, the process by which a new technology gains acceptance from potential users. To improve the state of the practice, it is necessary to understand—and if possible, influence—the state of the art. But if technology transfer is to succeed, effective communication about the benefits of innovative practices is essential.
Geoffrey Moore has popularized a useful model for thinking about technology transfer (2). In Crossing the Chasm, Moore identifies five categories of technology adopters: innovators, early adopters, early majority, late majority, and laggards (Figure 1).
Figure 1 - The adoption curve
Moore’s "chasm" is the gulf between early adopters and the early majority. Because they recognize the potential payoff of new technologies, innovators and early adopters tend to be willing to invest the time required to adapt a core technology to their needs. But the early majority, late majority, and laggards on the adoption curve require what Moore calls "whole products"—the core technology plus accompanying support materials such as documentation, validation data, installation instructions, tailoring instructions, and customer support.
Decision makers in organizations are rarely innovators or early adopters. Improving the state of the practice usually requires influencing the communities that determine organizational adoption—the early and late majority. Effective communication with these communities about the business case for adoption is critical to successfully crossing this chasm.
How is a communication strategy different from a strategic plan?
Potter (3) defines a communication plan as "a written statement of what communication actions you will engage in to support the accomplishment of specific organizational goals, the time frame for carrying out the plan, the budget, and how you will measure the results." The SEI strategic plan defines the SEI’s technical work; the SEI communication strategy defines how best to communicate about that work.
In 1996, managers at the SEI collaborated on the SEI Strategic Plan (4), which describes 11 initiatives around which we are now organized. These include initiatives to help software organizations improve network security (Survivable Systems), improve software capability through application of the Capability Maturity ModelSM (CMM®) framework for process maturity, improve the accuracy and efficiency of individual software engineers (Personal Software ProcessSM), improve systems composed of previously built and commercial off-the-shelf (COTS) components (COTS-Based Systems), and identify the consequences of decisions about software architectures (Architecture Tradeoff Analysis).
As the SEI began implementing these initiatives, we sometimes appeared to operate as a confederacy of separate businesses. This initiative-centered organizational structure was reinforced by a cost-center system in which central services such as writing, editing, graphic design, and instructional design within the Technical Communication (TC) Team were funded mostly by initiative cost centers rather than by central funding.
There were clear advantages to having initiative managers control all of the resources needed to accomplish their objectives. However, it seemed inarguable that some core set of communication products and services could be more effectively and economically planned, produced, and maintained if it was centrally funded and managed. Such a set would support the work of all the initiatives and serve to distribute cohesive, timely information about the entire organization. Identifying this set of products and services was to be the primary activity of our team.
The Process
Model from which we worked
We followed a typical strategic planning model consisting of the following stages: (1) Information gathering - customer analysis, analysis of strengths/weaknesses/opportunities/threats, research, focus groups; (2) Conception - problem statement, draft mission/vision statements, draft goals and strategies, performance audit/feasibility analysis, draft internal guidelines, review with management; (3) Prototyping - select and refine content, define success criteria, plan for contingencies, draft action plan, review with management; (4) Production of final deliverables - baseline of current state, strategic communication plan, action plan.
Believing ourselves to be well trained and experienced in project management, we drafted a project plan based on these stages, mapped meetings to the project plan, and prepared to develop the strategy in a rational, top-down fashion, confidently promising deliverables on specific dates. As we began to meet, however, we learned that developing a strategy can be more complex than expected. Coming to a common understanding of the problems that we needed to solve took much longer than we thought it would. In retrospect, we have learned that it was necessary for us to deviate from the plan when the top-down process had us at a standstill, and that there was no way to avoid confusion, ambiguity, and some contention on the way toward developing consensus.
Early Findings
We agreed that, like all strategic plans, a communication strategy must provide guidance in allocating resources effectively. It must answer the question "What will we do, and what won’t we do?" (5)
To force ourselves to make choices, we set the following goals for our work: (1) identify the most strategically important subsets of our customers; (2) identify customer needs that are not adequately being met by our existing products; (3) focus resources on those products that are most pertinent and useful to our most important customers; and (4) identify and eliminate effort currently being spent on products and customers not critical to the mission.
During the information-gathering stage, we reviewed what had been done in the past to identify the audiences that held a stake in the SEI’s broad mission. We also surveyed all of the products that were currently being used to communicate with these audiences.
This initial review of the "as-is" state was at first overwhelming. We had the sense that we were six blind men describing the same elephant in different ways. Since the SEI’s mission is to improve the entire field of software engineering, its audiences are numerous, diverse, and difficult to classify. What’s more, our survey of communication products currently in use unearthed more than 80 communication products.
To help us get our minds around this complexity, we devised a matrix of audiences and products. We first agreed on high-level categories. For audiences, the categories were (1) policy makers and oversight groups, (2) practitioners, (3) current customers, (4) potential customers, (5) transition partners (organizations licensed to distribute SEI-developed technology), and (6) SEI staff. For products, the categories were (1) general marketing activities, (2) marketing products, (3) participation products (how to work with us), (4) public information, (5) technical information, and (6) sponsorship, administrative, and contractual products. We then assigned specific audiences (e.g., software engineers, middle managers, systems engineers) and specific products (e.g., calendar of courses and events, public course brochure) to categories and noted the intersections between audiences and products.
After we had a clear picture of our current state, we conducted focus groups with interested SEI staff members to find out which communication products they considered most useful in their interactions with SEI customers. We learned that many staff members were unaware of existing products that could have been useful to them. This provided our first insight into the inefficiencies of attempting to meet corporate-level communication needs with division-level funding.
Although the matrix exercise was time consuming and tedious, the team needed to come to a common understanding of the problem. In the end, we concluded that (1) we had too many products; (2) there were no specific products coming out of the corporate office; (3) the audiences for many of the products were blurred; (4) many similar products were being developed separately; and (5) products designed for one division’s purposes could be made more widely useful with minimal additional effort.
Decisions About Scope
Based on the matrix exercise and focus groups, we made the following decisions about scope:
Aim at the highest levels of software organizations. Since the success of the SEI mission is measured by influence on the early- and late-majority communities, executive-level decision makers in software organizations represent the SEI communication strategy’s most important audience. This audience is more concerned with the effect of technology on the bottom line—cost and schedule—than with the technical details of how a technology is implemented (the sort of peer-to-peer communication that is typical of most of our technical journal material, and with which engineers tend to be most comfortable).
Focus on "marketing" communication. Although the
"crown jewels" of the SEI—its technical outputs such as reports, instructional
products, handbooks, and consulting arrangements—are communication products,
we decided to consider them outside the scope of our strategy. For the
most part, this sort of communication was working very well and did not
require our attention. Instead, we would concentrate on communication that
highlights the potential benefits of our technical outputs—what commercial
organizations call marketing, as opposed to intellectual capital.
"Marketing" |
Intellectual Capital |
Communication about technical content |
Technical content |
Popular magazine articles; press releases; high-level descriptions of initiatives and available products, services, and tools |
Technical reports, handbooks, maturity models, monographs, briefings, peer-reviewed technical papers, instructional products |
Summaries in plain English |
Peer-to-peer communication (some technical language OK) |
early majority, late majority, laggards |
innovators, early adopters |
Materials that entice the customer to open the box |
What the customer finds inside the box |
The Result
The final document that resulted from the team’s work identifies high-level goals, strategies, recommendations, and specific actions to be taken by the TC team.
The final strategies are
- Ensure that communication resources are available and funded to develop 11 new and revised products that are most likely to advance SEI communication goals.
- Increase awareness about the options that those at the SEI have when they want to create communication products other than those referred to in strategy (1), and the tools that are available.
- Develop and publish guidelines for SEI corporate identity, messages, and early adoption of new communication technologies that have been proven to enhance the quality and effectiveness of communication.
- Create communication plans for each initiative, from a standard template, that include tactics for using already existing communication channels to disseminate information about SEI work.
- Create a function that performs benchmarking, feedback, continuous improvement, oversight, and budgeting for this communication strategy.
Lessons Learned
We offer the following lessons for other technical communicators who engage in similar efforts:
- Begin by documenting and fully understanding the problem, and work hard to achieve consensus on the solutions. Although we all experienced discomfort with the complexity of the problems that we were trying to solve, our commitment to achieving consensus led to a more credible strategy.
- Prepare for implementation by including all the people whose support you will need in focus groups, document reviews, and other feedback loops.
- Practice good meeting management and carefully document decisions. We maintained an Intranet site for our minutes, transcriptions of flipcharts, interim drafts, and working papers. This greatly simplified the drafting of the final deliverables.
- Resist the pressure to go to the action plan before the strategy is complete. When we were nearly finished with our work, management began to focus almost exclusively on the products for which we were requesting funding, and we found ourselves negotiating budgets before the strategy was complete. Since we felt that we owed management a complete report based on our best perception of the problem, we resisted this pressure. When we finally presented our product proposals in the context of all of our findings, management supported all of them. With these corporate communication products, including a hard-copy newsletter and an online magazine, we believe that SEI technologies will have greater whole-product support that will make adoption of these technologies by early- and late-majority decision makers far more likely.
References
- Hickock, John. "PM Interviews Dan Czelusniak, USD (A&T)’s Director, Acquisition Program Integration." Program Manager xxvi, 141 (Nov-Dec. 1997): p. 8.
- Moore, Geoffrey. Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers. New York: HarperBusiness, 1991.
- Potter, Lester R. The Communication Plan: The Heart of Strategic Communication. San Francisco: International Association of Business Communication, 1997.
- Software Engineering Institute, Carnegie Mellon University. SEI Strategic Plan: 1997-2001 (CMU/SEI-96-SR-006). Pittsburgh, Pa., August 1996.
- Porter, Michael E. "What Is Strategy?" Harvard Business Review, November-December 1996: 61-78.
Bill Pollak
Team leader, Technical Communication
Software Engineering Inst., Carnegie
Mellon University
Pittsburgh, PA 15213-3890
412268-5656
wp@sei.cmu.edu
Anne Humphreys
Technical Coordinatore, Distance Education
Software Engineering Inst., Carnegie
Mellon University
Pittsburgh, PA 15213-3890
412268-3420
Bill Pollak is a senior writer/editor, member of the technical staff, and team leader of the Technical Communication Team at the Software Engineering Institute at Carnegie Mellon University. Pollak received his MA in professional writing from Carnegie Mellon in 1991.
Anne Humphreys is a project manager for distance education in the School of Computer Science at Carnegie Mellon University and technical coordinator for distance education at the Software Engineering Institute. Humphreys holds MAs in professional writing (1994) and communication planning and design (1996) from Carnegie Mellon University.