In Implementing Onscreen Editing (Hart 2019; ), I describe how to implement or revise a writing and revision process across an organization. The book is based on my personal experience with two onscreen editing implementations (Hart 2011, 2012). However, to provide more confidence in my recommendations, I also summarized two important papers that describe how to change processes and people from a robust practical perspective. In this two-part article, I’ve broadened that perspective to include other changes in the technical communication workplace, with a focus on the essential human aspects of change.
Part 1 describes an overall framework for managing change. Part 2 concludes with a discussion of how to help people change. Thoughout both, I’ll use the word “stakeholder” because everyone affected by changes to an existing system has a stake in the results, from senior managers to non-supervisory staff.
Part 1: A Framework for Managing Change
Note: This article cannot replace formal training in organizational psychology or change management. Nor does it review alternative quality improvement and process re-engineering methods. Treat this as an introduction that I hope will motivate you to learn more.
Many organizations attempt process change using methods such as Kaizen, ISO 9000, or “six sigma”. In any subsequent changes, the managers who led those efforts become essential resources, since the organization must integrate proposed changes with their past efforts. They can also reveal organizational factors that will support or impede subsequent proposed changes.
If you and your team face process changes, you should recognize that many explicit and implicit barriers affect such changes, and you must understand them before you can work around or through them.No “one size fits all” method exists to successfully implement process change. All methods must be adapted to your unique context.
Atkins et al. (2017) studied the “theoretical domains framework”, which is based on groups of factors (domains) that promote or inhibit organizational change. Though they focused on research, their “theoretical” framework has such obvious practical implications that it forms the core of this article. If you’re contemplating a large, complex change, read their original article and create a detailed list of all factors that apply to your organization. Reading the original is important because I’ve built on, expanded, and deviated from their framework in this article based on personal experience. Those deviations may have consequences in your context.
Note: Before you try to change a system that works, however poorly, understand what each component of the system accomplishes, and how you can achieve those goals under the new process.
Overview
The theoretical domains framework was proposed in 2005, then validated by many organizations until 2012, when it was revised to account for the results of that validation. The approach is intimately grounded in real-world efforts to understand how organizations and people change.
Note: Some of the case studies they describe may be similar to your context. If so, read the paper that describes that research to learn how others succeeded and the problems they encountered.
The framework condenses 128 propositions about human and organizational behavior into 14 domains that summarize the cognitive, emotional, social, and environmental (contextual) components of behavior:
- organizational knowledge
- stakeholder skills and workplace roles
- social factors that link workplace roles
- beliefs about capabilities
- optimism versus pessimism about change
- beliefs about a change’s consequences
- reinforcement (motivation)
- intentions (justification)
- proximal and ultimate goals
- managing the burdens on stakeholders (memory, attention, time)
- the work environment (organizational context)
- social influences (e.g., peer pressure, interpersonal and inter-group relationships
- emotional factors (e.g., fear of change) that can outweigh purely logical considerations
- behavioral regulation (e.g., self-monitoring versus supervisory monitoring).
Atkins et al. break these domains into detailed components and discuss how these components have been studied or performed in practice. Though their framework supports rigorous sophistication for researchers, it doesn’t require this sophistication for implementers. For example, a simple change could be based on interviews that reveal a clear and mostly objective understanding of the current situation and how it must change. This could be achieved by talking to stakeholders until you understand their situation—with more listening than talking by you. If you’re comfortable talking with your colleagues, this approach isn’t onerous.
That being said, the greater the stakes and the greater the consequences of failure, the greater the likelihood that hiring a professional will improve the outcome.
Steps
Regardless of the size and extent of the change to be implemented, you can implement the theoretical domains framework by taking the following steps:
- Identify and define the behaviors you want to change and the factors that you must study, as well as their interactions.
- Decide how to learn enough to understand the situation you’re trying to change and the desired outcome. Methods range from stakeholder interviews to quantitative performance monitoring.
- Decide who will provide inputs into the change. In small organizations, this may be all stakeholders; in larger organizations, it may only be key stakeholders (e.g., a representative of each stakeholder group).
- Collect enough data to be confident you fully understand the existing situation and the consequences of change.
- Discuss your findings with the managers who will give permission to proceed—and who will be held responsible for the outcomes. Find ways to lower the risk of negative consequences, while maximizing positive outcomes.
- Develop supporting materials such as implementation guides and training sessions to facilitate the transition to the new process.
- Find ways to motivate resisters to embrace the change. (See part 2 of this article, Helping People to Change, for details.)
Choose what to study
How do you narrow down the many criteria for choosing the factors and behaviors you’ll study? Start by considering whether it’s realistic to change certain factors or behaviors; there’s no point investing time and money if you can’t possibly change something. You’ll need to understand the consequences of that immovable obstacle for your efforts, of course. Instead, emphasize what you can change. Prioritize factors and behaviors that most strongly affect the outcome. For each, consider the consequences for other behaviors (i.e., interactions, side-effects). Some consequences will require tradeoffs between competing objectives.
Your budget (time and money) will constrain the scope of your study, and you’ll need to negotiate this with whoever will fund your study and give you time to conduct it. Even if you don’t spend money, time away from your work has costs for you and your organization: while you’re performing an implementation study, you’re unavailable for your real job.
Consultation begins with the key stakeholders who’ll be affected by the change, or representatives of stakeholder groups. A key individual stakeholder might be the publication department’s manager; a key stakeholder group might be the technical writers that manager supervises. Interview as many stakeholders as time and money permit; within reason, more opinions is better than fewer, as this provides a more comprehensive understanding. Collect enough information to have confidence in your results; at a minimum, two is better than one.
Decide how to assess each factor or behavior, both before and after the implementation, so you can confidently describe the results. Account for both quantitative factors that are at least somewhat objective, such as the time required to edit a manuscript, and qualitative factors that are at least somewhat subjective, such as the emotional responses of stakeholders to being edited. Emotional considerations are crucial when you want to motivate people to change: someone who understands a proposed change in their head, but doesn’t accept it in their heart, will be difficult to motivate. Seek a balance between quantitative/objective and qualitative/subjective information.
Note: Interviewing requires skill. Hart (2000) provides simple suggestions. Self-reports from interview subjects are notoriously unreliable. Thus, try to validate what you hear from another perspective.
Most information you collect will come from stakeholder conversations. Design tools such as questionnaires that help you ask everyone the same questions, in the same way, to increase the consistency of your results. Develop “coding” sheets to record answers quickly so you won’t waste the interviewee’s time. For example, use codes such as 1 = agree completely to 5 = disagree completely. Before collecting data, test these tools by interviewing your colleagues to ensure they provide data you can analyze and interpret. Redesign these tools until they provide the information you need and won’t waste the time of interviewees. Whether you use paper or a computer to record responses, budget time to explore unexpected responses and the responses to follow-up questions.
Note: Recording interviews (with permission!) lets you review them later to avoid having to annoy someone to repeat a question. To help colleagues overcome any discomfort over being recorded, start with a neutral subject, such as the cafeteria food, with your recording device on. Once they’re talking freely, start your real questions.
Review your notes before ending an interview, and ask for any necessary clarification before you leave. Thank them for their participation!
Analyze and discuss the data
As you analyze your data, look for biases you bring to this process. It’s difficult to recognize biases, since many are subconscious. Discussing your interpretations with colleagues may reveal those biases. Discussing your interpretations with interviewees is better. “Active listening” is particularly powerful. Stripped to its essence, active listening begins with “what I hear you saying is…” and ends with the interviewee agreeing with or correcting or building on your statement.
You can bring more objectivity to your analysis if you encode some groups of responses numerically, as in the agree/disagree scale I mentioned earlier. It’s more efficient to encode responses after an interview, since that lets you focus on the speaker, not the codes, during the interview. When you subsequently analyze your data, divide answers into positive and negative responses (e.g., support for and opposition to a proposed change), each with a score of +1 or –1, respectively. Total these values. Large positive or negative numbers represent (respectively) strong support or opposition; responses closer to 0 require more thought to interpret. For example, if you receive 12 positive and 10 negative responses, this reveals two groups with different concerns or needs.
Much of what you learn will raise additional questions, since such research is necessarily exploratory: you don’t always know what you need to learn before you start talking to stakeholders. Thus, this research may be highly iterative, with each discovery revealing new questions. At some point, additional research becomes counterproductive; if you strive for perfect understanding, you may never achieve a good enough understanding for your purposes.
Maintain ongoing communications with managers and stakeholders. For example, consider weekly five-minute progress reports to each stakeholder or a formal monthly meeting of all stakeholders to discuss progress and solve problems. Ask stakeholders to confirm your interpretations, report flaws in your process, or correct misunderstandings before the consequences become significant. As you near the end of your research, summarize your findings and recommendations in a formal report to everyone who must approve your proposal. A business case is a common, effective tool, and you can find numerous templates and examples on the internet. Because this report determines whether you’ll succeed, ask colleagues to review your draft reports to ensure they’re complete and persuasive.
Atkins et al. (2017) mention other ways to support implementation. But the theoretical domains framework is both comprehensive (i.e., it covers all key factors) and granular (i.e., it permits considerable detail). Thus, it provides good control over your information-gathering. Its main limitation is that it doesn’t recommend specific quantitative methods, such as performance metrics, nor does it recommend more complex observational methods such as contextual inquiry. That’s also an advantage, since you can add as much or as little sophistication as you need.
References
Atkins, L., Francis, J., Islam, R., O’Connor, D., Patey, A., Ivers, N., Foy, R., Duncan, E.M., Colquhoun, H., Grimshaw, J.M., Lawton, R., Michie, S. 2017. A guide to using the Theoretical Domains Framework of behaviour change to investigate implementation problems. Implementation Science 12:77. https://implementationscience.biomedcentral.com/articles/10.1186/s13012-017-0605-9
Hart, G. 2000. Effective interviewing: get the story. Intercom, January: 24–26. http://geoff-hart.com/articles/2000/interviewing.htm
Hart, G. 2011. Uprooting entrenched technical communication processes: process improvement using the kaizen method. http://geoff-hart.com/articles/2011/kaizen.html
Hart, G. 2012. Reimagining the review-and-revision process: a case study of improving the speed and accuracy of technology transfer. Intercom February: 22–27. http://geoff-hart.com/articles/2012/kaizen-long-version.html
Hart, G. 2019. Implementing onscreen editing. Diaskeuasis Publishing, Pointe-Claire, Quebec. http://geoff-hart.com/books/implementing/implementing.html
Kegan, R.; Lahey, L. 2001. The real reason people won’t change. Harvard Business Review. November 2001. https://hbr.org/2001/11/the-real-reason-people-wont-change
Elsewhere on TechWhirl
Who Invited the Writer? Smart Techniques to Expand your Organizational Value
Technical Writing Foundations: Mastering the Art of the SME Interview
