COMMUNICATING PROJECT

MANAGEMENT

Communicating Project Management argues that the communication practices of

project managers have necessarily become participatory, made up of complex
strategies and processes solidly grounded in rhetorical concepts. The book draws
on case studies across organizational contexts and combines individual experi-
ences to investigate how project management relies on communication as teams
develop products, services, and internal processes. The case studies also provide
examples of how project managers can be understood and studied as writers,
further arguing project managers must approach communication as designed
experience that must be intentionally inclusive. Author Benjamin Lauren illus-
trates to readers how teams work together to manage projects through complex
coordinative communication practices, and highlights how project managers are
constantly learning and evolving by analyzing where they succeed and fail. He
concludes that technical and professional communicators have a pivotal role in
supporting and facilitating participative approaches to communicating project
management.

Benjamin Lauren is an Assistant Professor at Michigan State University in

the Department of Writing, Rhetoric, and American Cultures. He is also an
Assistant Director of the Graduate Program in Rhetoric and Writing. His work
has been published in journals such as Technical Communication, Computers
and Composition, the Journal of Technical Writing and Communication, and
Transactions on Professional Communication.
ATTW Book Series in Technical and Professional
Communication
Tharon Howard, Series Editor

Lean Technical Communication: Toward Sustainable Program Innovation

Meredith A. Johnson, W. Michele Simmons, and Patricia A. Sullivan

Scientific and Medical Communications: A Guide for Effective Practice

Scott A. Mogull

Plain Language and Ethical Action: A Dialogic Approach to Technical Content in

the 21st Century
Russell Willerton

Rhetoric in the Flesh: Trained Vision, Technical Expertise, and the Gross Anatomy
Lab
T. Kenny Fountain

Social Media in Disaster Response: How Experience Architects Can Build for
Participation
Liza Potts

For additional information on this series please visit www.routledge.com/ ATTW-

Series-in-Technical-and-Professional-Communication/book-series/ATTW, and
for information on other Routledge titles visit www.routledge.com.
COMMUNICATING
PROJECT
MANAGEMENT
A Participatory Rhetoric for
Development Teams

Benjamin Lauren
First published 2018
by Routledge
711 Third Avenue, New York, NY 10017
and by Routledge
2 Park Square, Milton Park, Abingdon, Oxon OX14 4RN
Routledge is an imprint of the Taylor & Francis Group, an informa business
© 2018 Taylor & Francis
The right of Benjamin Lauren to be identified as the author of this work
has been asserted by him in accordance with sections 77 and 78 of the
Copyright, Designs and Patents Act 1988.
All rights reserved. No part of this book may be reprinted or
reproduced or utilised in any form or by any electronic, mechanical, or
other means, now known or hereafter invented, including photocopying
and recording, or in any information storage or retrieval system,
without permission in writing from the publishers.
Trademark notice: Product or corporate names may be trademarks or
registered trademarks, and are used only for identification and
explanation without intent to infringe.
Library of Congress Cataloging-in-Publication Data
Names: Lauren, Benjamin, author.
Title: Communicating project management / Benjamin Lauren.
Description: 1 Edition. | New York : Routledge, [2018] | Series: ATTW
book series in technical and professional communication
Identifiers: LCCN 2017045381| ISBN 9781138046382 (hardback) |
ISBN 9781138046429 (pbk.) | ISBN 9781315171418 (ebk)
Subjects: LCSH: Project management. | Business communication. |
Leadership.
Classification: LCC HD69.P75 L387 2018 | DDC 658.4/5—dc23
LC record available at https://lccn.loc.gov/2017045381

ISBN: 978-1-138-04638-2 (hbk)

ISBN: 978-1-138-04642-9 (pbk)
ISBN: 978-1-315-17141-8 (ebk)

Typeset in Minion
by Florence Production Ltd, Stoodleigh, Devon
For Liz, Austen, Addie, and Skyler,
who held on until the end
CONTENTS

Acknowledgments viii
Foreword x

Introduction 1

1 Decentralization and Project Management 20

2 Rethinking the Paradigm of Project Management: From

Efficiency to Participative 39

3 Communicating to Make Space for Participation: Locating

Agency in Project Communication 65

4 On Site with The Gardener and The Chef: Project Leadership

and Communication 108

5 Managing a Reorganization Project at DTI: Participation and

Making Space for Communicating Change 134

6 Conclusion: A Participatory Rhetoric for Development Teams 163

Index 175
ACKNOWLEDGMENTS

This project began when I was a PhD student at Texas Tech University. While
at Texas Tech I received a great deal of support from Joyce Locke Carter, Steve
Morrison, Chris Andrews, Sam Dragga, Miles Kimball, Becky Rickly, Bea Amaya,
and Kristen Moore (who first introduced me to Pat Sullivan’s work). I would
also like to recognize my committee, Kelli Cargile Cook and Fred Kemp, for their
support of my ideas and for all the feedback along the way. It still resonates. As
well, my dissertation chair, Rich Rice, who invited me to keep reading, thinking,
and writing, while also reminding me to be happy in life—to find a balance and
to always think about my family’s happiness.
I also have to thank my colleagues, friends, and students at MSU (in no specific
order): Bump Halbritter, Julie Lindquist, Lizzie Oderkirk, Chris Long, David
Prestel, John Monberg, Erin Campbell, Liza Potts, Alex Hidalgo, Steve Fraiberg,
Autumn Laws, Jenn Ismirle, Howard Fooksman, April Baker-Bell, Malea Powell,
Dawn Opel, Brooke Chambers, Diana Shank, Regina Boone, Phil Deaton, Gary
Vigil, Barb Miller, Tylor Hoekstra, Scott Schopieray, Kristen Mapes, Jess Knot,
Ryan Yang, Valeria Obando, and Jackie Rhodes. All of these folks offered timely
and useful advice, support, and encouragement. In addition, I am indebted to
Dánielle DeVoss, Bill Hart-Davidson, Stuart Blythe, Mary Litteral, and Jeff
Grabill for reading drafts and giving feedback to the project. Mary Litteral
particularly deserves editorial credit—your feedback was so helpful and needed.
A massive thank you to WRAC and the College of Arts and Letters at MSU for
funding much of this project as well.
I’d also like to thank colleagues in the field who were very supportive of
this project: Michael Salvo, Kirk St. Amant, Joanna Schreiber, Keith Instone,
Peter Merholz, Emily Bowman, Lisa Welchman, Paul Feigenbaum, Emma Rose,
Laura Gonzales, Claire Lauer, Carlton Card, Cheryl Ball, Anna Dematatis, Karen
 Acknowledgments ix

Schriver, and Beth Keller. As well, a big thanks to Tharon Howard as editor of
the series/project.
Thank you to all my participants—without you this research would have not
have been possible.
A shout-out is owed to Stacey Pigg for reading and responding to this book
several times throughout the process. Her insight and generosity proved
significant through and through.
The penultimate thank-you goes to my sister and brother, Jaime Lauren and
Tavaris Thomas (the latter for the badly needed slap on the head). And Jaime,
thanks for always being there despite the highs and lows, reminding me to laugh.
Give Rid and Phin a hug.
And last, thank you to Liz, Austen, and Addie for believing in me and
reminding me to believe in myself. You inspire me every day. I truly would not
have finished without your patience, love, and support. You are my everything.
FOREWORD

Communicating Project Management: A Participatory Rhetoric for Development

Teams
Ben Lauren’s book Communicating Project Management: A Participatory Rhetoric
for Development Teams is the fifth in the ATTW Book Series in Technical and
Professional Communication (TPC), and as its subtitle suggests, this is a book
about building and maintaining development teams through the use of what
Lauren defines as “participatory rhetoric.” Like all the other books in the ATTW
Book Series, it is solidly based on research and a comprehensive knowledge of
the literature in the field. Balancing between his mastery of academic works, his
practical experience as a team lead, and his empirical observations of project
managers in workplace environments, Lauren provides TPC students and
practitioners with a deep dive into the strategies and practices which working
professionals use to cultivate and maintain lines of communication between team
members regardless of whether they are using LEAN, Agile, Six Sigma, or some
other project management model.
Lauren’s book is a useful antidote to those all-too-common situations where
TPC professionals and/or students are put into group development teams and
told to collaborate without any real guidance. Through his empirical studies of
teams in workplace environments, Lauren helps us under the skills and strategies
needed to create functional teams. More importantly, by specifically focusing
on participation, Lauren uncouples the role of the project manager from the
traditional focus on forcing “collaboration” in teams and, instead, positions
the work of development team members as a shared activity. Liberating us from
the despotism of collaboration, Lauren develops an alternative and useful
framework that shows that project management can be understood as a set of
learnable skills layered on top of effective communication. Lauren’s participatory
 Foreword xi

approach to project management makes fostering engagement, coordinating

information, and helping team members learn to refine communication skills
essential to the success of today’s project teams.
This book is an extremely timely and well-researched introduction to a
pervasive and often misunderstood topic in TPC. As such, it’s a pleasure to have
it in the ATTW Book Series in Technical and Professional Communication.

Dr. Tharon W. Howard

Editor, ATTW Book Series in
Technical and Professional Communication
October 23, 2017
INTRODUCTION

I began this book asking a deceptively simple question: why does Technical and
Professional Communication and, really, the world, need another book on
project management? After all, there is an abundance of material on project
management across disciplines, and adding another book to that conversation
might be like throwing a handful of sand into the ocean. So much of the
previously published output in technical communication has done a solid job of
walking people through project lifecycles and best practices in managing
documentation teams and communication (for example, Allen & Deming, 1994;
Dicks, 2004; Hackos, 2007). Perhaps those works are now dated, and in some ways
they are, even though they still hold a great deal of value. For this reason, I strongly
considered writing a book that would specifically update this work to make it align
with current practice. For example, a project management book that would teach
technical communicators to work with Agile and Lean development teams. For
a while, that is the book I intended to write. But that solution left me unsettled
because it assumed a relatively positivist stance on Agile and/or Lean. The “why
another book on project management?” question even lingered as I collected data,
analyzed it, and tried to understand the bigger exigence for my research. The
turning point was when I was coding the interviews for Chapter 3 and I identified
the concept of “safe spaces for communication” surfacing in the transcriptions.
I knew that finding was important. Many of the project managers I’d talked to
thought about managing the communication of project work through a lens of
safety. And safety was developed in support of communicating in ways that led
to participation with multiple audiences that have a stake in project work. So that
is how I discovered the answer to my why question.
We need another book on project management because much of the previous
work operates under a big assumption: that project management is about, above
2 Introduction

all, making teams efficient by expertly using tools and processes. However, this
view neglects to position project managers as writers. If we understand project
managers as writers, then we can understand their communication work as
inherently rhetorical because it is situated and context-specific. More, the com-
munication of project managers can be studied as writing, which can help reveal
its embedded values and beliefs as these emerge through practices. So, what
happens when we think about project managers as writers and study them as
writers? Through this book I work to answer these questions, arguing that
effective project managers help make teams efficient because they communicate
in ways that seek to cultivate participation.
Let me explain what I mean by project managers as writers a bit more. Plenty
of scholars in technical communication offer broad views of what constitutes
“writing” (Hart-Davidson, 2001; Schriver, 2012), seemingly agreeing that writing
encompasses assembling words and figures on a screen or page as well as design-
ing visuals like charts and figures. Furthermore, writing is also coordinating
networks of people, designing interfaces, assembling data, or even making grocery
lists. Writing is creating meeting agendas, and writing is also implementing the
agenda through mundane acts such as keeping people on task. Writing is also
following up after a meeting to check on someone’s perception of an interaction.
Writing is all these things, because the communicative act is intentional, designed
to elicit a particular effect and/or response, and purposefully shaped for an
audience or audiences. In this way, most of the work of project management is
writing, but the scholarship tends not to position it that way. That’s what this
book takes on, offering case studies that provide a variety of snapshots of project
managers as writers who are situated in organizational contexts and team cultures.
Please don’t misunderstand, I don’t want to argue that efficiency is unimport-
ant for project management. People are always looking for innovative ways to
be more productive and efficient at work—and that shouldn’t stop. The way our
work lives are structured in the 21st century basically demands efficiency of us.
On the other hand, I do want to put efficiency under a microscope. Efficiency,
in many team situations, is highly dependent on the participation of multiple
people. Effective participation of sometimes disparate audiences is how efficiency
is achieved. In today’s globally distributed and digitally networked workplaces,
understanding that cultivating participation leads to productivity is a fundamental
writing skill. Teams must work fast, most definitely, but they need to commu-
nicate in ways that support involvement across stakeholders and users to achieve
a swift pace. However, we have not investigated the relationship of writing to
participation in the context of project management. Nor have we addressed the
variety of communication used to support participation in the context of project
management.
Aside from the scholarly contribution this book offers, I do have practical
reasons for writing a book on project management. In Technical and Professional
Communication, books on project management are relatively sparse. We’ve
 Introduction 3

produced work that informs project management and how people practice it,
but rarely have we made our unit of analysis project management. No doubt this
is what led Stan Dicks (2013, pp. 311–312) to explain, “For an area that is as
critically important to technical communication as project management, it is
surprising that there are not more articles in the literature dedicated to the
subject.” The work that has been published focuses almost entirely on instructing
people how to be project managers; it is practice-oriented without being critical
of the project management methodologies teams adopt. And those methodologies,
sometimes having grown so popular and buzzworthy that they are fetishized,
directly influence how we manage timelines, budgets, workflow, and, most
importantly, people. Surprisingly, this emphasis on practice instead of theory is
also a problem in project management studies in general (see Morris, Pinto, &
Söderlund, 2011). This book looks to fill some of that theoretical space by
repositioning project managers as writers.
Another reason: the published scholarship has not produced little examination
of methodological histories and trajectories and how they influence project team
dynamics. For example, consider popular textbooks (Lannon & Gurak, 2017;
Markel, 2015) and single-authored books (Dicks, 2004; Hackos, 2007; Hamilton,
2009; Schwarzman, 2011) that focus on instructing people on the fundamentals
of managing information development projects and teams. To be clear, I do not
mean to criticize these books, but to point out an important observation that
our field’s interest in project management is preoccupied with knowing how to
do it or best teach others how to embody the role. This focus on doing presents
a theoretical tension, however, because

there has been pressure to better shape the theoretical basis of the subject
and to make project management more relevant to managers, sponsors,
policy-makers, and others concerned with the management of projects,
doing so without diminishing standards of academic rigor.
(Morris et al., 2011, p. 3)

This book is also a response to these observations, to extend a theory of project

management as writing. To do so, the book assembles scholarship that studies
the communication swirling around projects and project teams. And even though
technical communication has excellent books that describe and theorize
organizational communication and writing (Yates, 1989; Longo, 2000; Faber, 2002;
Spinuzzi, 2003; Winsor, 2003; Whittemore, 2014), our field has not turned its
attention to project management in these same organizational contexts.
Specifically, what follows in this book is an inquiry into the role of participa-
tion in communicating project management as a means for understanding it as
writing—as a designed system of communication that has great influence over
how people work. The cases presented in this book help demonstrate that widely
used project management systems often achieve efficiency through effective
4 Introduction

participation of multiple audiences. Further, the book demonstrates that

participation is elicited, in part, through communication. The goal of this book,
then, is to explore how project managers can approach communication in more
intentional ways to balance the need for efficiency with the need for cultivating
participation.

Project Managers as Technical Communicators

Project management has a great deal in common with technical communication
as both have a long history with scientific management. In the context of scientific
management, “Technical writing and reporting provided the mechanism for
ensuring that workers internalized the system, just as it was the mechanism
for management control of the organization” (Longo, 2000, p. 102). Longo’s work
showed us that it was the efficiency quality of technical communication work
that supported scientific management. Today, many technical communicators
regularly work as project leads. And, just like the work of technical communica-
tion, project management activities are made up of coordinating communication,
sharing information, and managing the timing and cost of work. The project
manager tends to lead these activities from the middle of an organization, using
their unique viewpoint and knowledge to move a project toward successful
completion while also ensuring it helps organizations achieve business outcomes.
The truth is I believe project managers are technical communicators. As Carolyn
Rude (2009) so clearly explained of technical communicators, project managers
also work to make complex information accessible to the people who need to
use it. Complicating matters, much of this communication work is done across
multiple projects, teams, and organizations. Further, I believe project managers
too are “technical rhetoricians,” to use Johndan Johnson-Eiloa’s (2005) words,
because they are “not merely simplifying information to make it clear, but
working within information, filtering, rearranging, transforming, and making
connections to address specific, specialized problems” (p. 19, emphasis in
original). Project management tries to keep audiences participating in tandem
so a project can get done efficiently and effectively. Sometimes that work is tech-
nical, such as working with project management systems. Other times it
is rhetorical, such as communicating with stakeholders, writing documentation,
archiving data, and facilitating meetings.
Disciplinary conversations about the role of technical communication beyond
textual production has incrementally moved the field toward conversations
about taking on management and leadership roles (e.g., Dicks, 2004; Johnson-
Eilola, 2005; Hart & Conklin, 2006; Hackos, 2007; Potts, 2014). The cases in this
book also speak to these conversations to add that effectively communicating
project management requires strategies that make space for participation.
Furthermore, I argue that the methodologies we use to manage projects contribute
significantly to what development teams produce and how they engage in
 Introduction 5

communicative activities at work. These methodologies are designed. While

technical communication has produced scholarship on organizational manage-
ment that speaks directly to these issues (Yates, 1989; Winsor, 2003), we have
not yet investigated the communication of project management in these ways.
Even more poignant a point, as we see movement toward the new kinds of
organizational structures Spinuzzi (2015) describes, we are in danger of over-
looking the importance of project management methodologies on our work
processes and procedures. Many project development methodologies directly
inform project management, such as Agile, Lean, and/or Six Sigma. These
methodologies promote specific ways of organizing, working, and thinking while
diminishing or overlooking others. One of the goals of this book is to explore
what is gained and what is lost when these new methodologies are adopted by
teams.
Although, in articulating that project management communication is technical
communication, I do not mean to suggest the professions are one in the same.
Rather, I am arguing that the work overlaps a great deal, particularly because
managers spend most of their time at work communicating.1 As Chapter 4 will
further explain, both project managers and technical communicators have been
described as “gardeners” or cultivators (DeMarco & Lister, 2013; Hart-Davidson,
2001). Of course, every technical communicator will not become a professional
project manager, but technical communicators are entering a workforce that
requires an understanding of how to effectively negotiate participation across
project teams, stakeholders, users, and other involved groups of people, regardless
of context. And many people might be surprised to learn they are already project
managing their lives by setting goals like planning social engagement, learning
a new instrument, getting a job, exercising regularly, or balancing their personal
and professional life. In the workplace, technical communicators will need to
understand how to coordinate communication because the work they do on a
daily basis is often dependent on the participation of others. In other words, both
project management and technical communication rely on writing to support
their work.

Distinguishing Between Participation and Collaboration

It is important to note in this Introduction that in this book when I refer to
participation, I do not mean collaboration. There is a tradition of scholarship in
technical communication that focuses on both participation and collaboration.
The scholarship on participation tends to focus on engagement with people,
especially in the context of civic life and discourse (Blythe, Grabill, & Riley, 2008;
Simmons, 2007; Simmons & Grabill, 2007) and design (Johnson, 1997; Salvo,
2001; Spinuzzi, 2005; Agboka, 2013; Potts, 2014). Scholarship on collaboration
is more widespread, and has focused on areas such as the workplace (Burnett,
1991; Burnett & Duin, 1993; Friess, 2011; Jones, 2016), the classroom (Paretti,
6 Introduction

McNair, & Holloway-Attaway, 2007; Flammia, Cleary, & Slattery, 2010),

intercultural communication (Brewer, 2015), partnerships between academia
and industry (Bridgeford & St. Amant, 2016), and so on. The scholarship on
participation tends to focus on relatively egalitarian views of work and design (I
mean this not as a criticism, but an observation). However, participation in project
work is often more pragmatic. While I do not wish to dismiss participation as
important to democratic work processes, there are also functional and logistical
limits to how people can participate in a project.
Let me unpack that last statement a bit more. Someone may participate in a
team meeting just to ensure they understand a project’s goals and scope so they
can give feedback, but this person is not necessarily a collaborator. A collaborator
is one who works with others to do the work of the project. It requires different
kinds of labor, expectations, and communication than participation. As Rebecca
Burnett, Andrew Cooper, and Candice Welhausen (2013) depicted it,

collaboration involves substantive interactions between and among people

who share goals and exchange information as they work toward those goals
in a variety of settings and with a variety of tools, either because the task
size or complexity is too great for a single person or because the task will
benefit from multiple perspectives.
(pp. 457–458, emphasis in original)

Collaboration infers people work together on a project in “substantive” ways.

I do not see coordinating information across a team, for example, as collaborating
per se, but is a communicative activity that facilitates collaboration. For example,
people collaborating on a document write it together, no matter if the division
of labor implies people work side-by-side as an integrated team or contribute
separately as individuals (see Killingsworth & Jones, 1989).
Collaboration infers participation because people working together must be
involved in the project in some meaningful way. Project managers have
sometimes called negotiating this sort of involvement as getting “buy-in,” where
individuals up, down, and across an organization understand and believe in the
aims of a project, both in its approach and intended business outcomes. Project
managers work for buy-in as a means for involving people that have influence
over the success of a given project. These people often exist on multiple levels of
an organization (or even outside of an organization), and they generally are not
involved in the collaborative work of the project.

A Bit About Scope

Because I position project managers as writers, the research herein is not limited
to the study of project management practices only in technical communication.
This distinction is key because it helps to clarify the context of the data that informs
 Introduction 7

the research cases later in this book. In some instances, the cases focus on the
organizational and team context of user experience while in others the cases occur
in the context of government or healthcare information technology. Each of the
participants, however, are positioned as writers because they engage in project
management activities that require communicative interaction and involvement
with teams, internal and external stakeholders, and so on. As a result, the cases
offer a rich and broad array of writerly experiences and contexts.
Additionally, it would be impossible to study all existing forms of project
management in this book. For instance, it is arguable that content strategy or
translation activities involves a kind of project management, but this book does
not investigate these connections. Furthermore, construction project manage-
ment is very different than managing development and creative teams. In this
research, I am particularly interested in how people communicate and participate
in project management in organizations that develop digital technologies and
services. These organizations are often multinational and employ people all
around the world. Throughout the book, I introduce research participants, their
differing roles, and titles in each chapter, but what unites them is their role as
technical rhetoricians that somehow are involved with managing or co-managing
projects with development teams.
Finally, this is not a “How-To Manage Technical Communication Projects”
book. As stated earlier, my goal is not to instruct readers about the nuts and bolts
of managing projects in technical communication. There are better places to go
for that sort of training. Rather, this book examines how project management
is communicated in the context of development teams, and works to understand
participation in the writing philosophies, strategies, and practices that people and
teams use. While I believe readers will find the results of this work instructive
and the cases presented valuable for thinking about project management and how
to practice it, this book’s primary focus is on offering a critical, humanist
perspective to managing projects—an area where writing studies excels. That said,
I would like to note that to balance research and practice, I do work to include
takeaways for practitioners in each chapter. While this is not a book focused only
on instruction, I do hope there are practical takeaways for all readers.

My Background with Project Management

While I continue to discover frequent connections between my life experiences
and project management, there are two particular professional experiences that
have influenced my understanding of the research presented in this book. To a
degree, these experiences clarify my researcher stance, or relationship to the topic
and data, because they explain the lens through which I understand how project
teams function.
In my first career, I was a musician. I was the de facto leader of the band. My
days were spent in what seemed like constant dialogue about our music and the
8 Introduction

business of our music. One phone call would be with someone from our
management or record label, while the next would be with a radio station. Often,
after greeting fans before a show, I would be called to a meeting with our
management team to talk over an unexpected development that suddenly needed
to be problem-solved. An important part of my role as the leader was to facilitate
communication across different groups (i.e., the label, the management team,
the band, the radio stations, the producer, and the fans). Complicating things,
these groups were often distributed across wide swaths of space, and had
different—oftentimes diverging—motivations, histories with each other, and in-
the-moment exigencies. At the time, I didn’t think of myself as a project manager,
but I was one. And like many project managers, I felt as if I was making it up
(and messing it up) as I went along. I knew all of these groups were involved in
some way with the band, but I wasn’t always sure how I could persuade them to
participate with each other effectively.
As a (former) musician, I also understand managing project teams as similar
to participating in a jam session. Musicians riff off each other. People have roles,
yes, but when the guitarist begins a solo, everyone else understands it is time to
step back into more of a support role. Musicians do this by listening for subtle
communicative clues. For example, a cadence one person plays may lead to a
hand-off from the guitarist to the horn player. Or, someone may signal a hand-
off through a kind of phrasing that resolves musically, inviting the next person
to step in and play. Jam sessions have very clear rules (keys, timing, space) that
musicians internalize and understand, so they don’t have to stop playing to remind
someone, “hey, follow the rules!” In the context of project management, Demarco
and Lister (2013) describe this phenomenon as jelling, explaining, “Jelled teams
are usually marked by a strong sense of identity” (p. 136). Experienced musicians
jell by reading and reacting in the moment to where the music is leading and
following along by actively listening to each other. Listening is one essential way
bands support participation in playing music. Without the right kinds of
participation, there is no music. I think project management works in comparable
ways.
A second professional experience grew out of my time working as the
coordinator of a media lab in an English Department early on in my career. In
this position, I was responsible for managing the role of the lab in supporting
projects. If being a musician taught me about the importance of jelling as a team,
then coordinating the media lab taught me important lessons about the role
of environment (emotional and physical) in doing project work. To be useful to
other instructors, the media lab had to be a flexible environment. If an instructor
designed a project that required our support, I had to arrange the environment
to align with that specific assignment. In practice, that meant there was very little
static space in the lab. Every project that came in the door was different, and
required something different from me and from the lab. One day I might be
facilitating an audio recording session where students were remixing previously
 Introduction 9

developed work for a new genre. The next day I might be helping students finish
an interactive mapping project. I came to understand that different kinds of
facilitation required varied communication strategies and practices that had to
be applied and adapted to different situations.
The work of facilitating communication as a musician and in the media lab
made jelling and the role of the environment important considerations for me
as a scholar of project management. These experiences especially showed me how
communication helped build the kinds of relationships essential to doing the work.
To make sense of these experiences today, I turn to research on the importance
of psychological safety on teams (Edmondson, 1999) and distributed cognition
(Hutchins, 1995). As people work and take risks, teams tend to succeed more
often when the work environment is a kind of safe space, where risk-taking,
pitching ideas, and learning can occur publicly without harming individual
credibility or reputation. Structures must be developed for this kind of participa-
tion to productively occur. Additionally, Edmondson (1999) demonstrates
the role of effective coaching in helping teams develop psychological safety,
particularly through facilitating internal communication about work processes
and procedures. In other words, facilitating psychological safety seems to be
systemic and structural. Managing team dynamics amid workplace systems
and structures is an important role many project managers must fulfill. My view
of psychological safety is that project managers support it through effective com-
munication—through activities that help teams and audiences jell. I do recognize
this is a relatively egalitarian view of collaboration and teamwork that is not
necessarily always practical or efficient. I’d counter, however, that project
management is already a social activity, and that sometimes the inefficiency of
social participation is actually the most efficient path forward.

Terms
So far, I have deployed a number of terms without explaining them in more depth.
In this section I preview a discussion of the terms I will use and refer to through-
out this book. While many of the coming chapters will explain many of these
terms in depth and practice, I introduce them here to make sure readers
understand how I deploy and position each one.

Project
I understand a project as containing both technical and human elements (Levin,
2010). The technical elements include activities like estimating, scheduling,
and budgeting. The human elements consist of the interpersonal dynamics that
exist across teams of people or even just a single person. In addition, I also
understand projects as being a unique work situation that exists over a clearly
defined period of time. According to The Project Management Body of Knowledge,
10 Introduction

which is the resource used by many to become certified project managers,

“A project is a temporary endeavor undertaken to create a unique product, service,
or result” (Project Management Institute [PMI], 2013, p. 3). Important to this
definition of project is it has a definable time frame with a clear beginning and
ending, which is called the project lifecycle. Each part of the cycle represents a
new phase of the project. However, “Temporary does not necessarily mean the
duration of the project is short” (PMI, 2013, p. 3). Projects can last days, weeks,
years, and in some cases, a lifetime. Walt Whitman, for instance, famously
continued to revise Leaves of Grass until his death. Comparably, continuous
product development is used by many organizations to release the latest versions
of many popular products on an ongoing basis, such as we’ve seen with smart-
phones.

Project Manager
When I refer to project managers, project leaders, or project management, I am
referring to what Scott Berkun (2008) called “project management activities.”
Project management activities are made up of both the technical and human work
that individuals and teams do across a project lifecycle. Berkun noted that the
role and responsibilities of project managers, just like project management,
is often tied to an organization. As a result, sometimes there is one person in
the role of project manager and sometimes project management activities are
shared across a team, as Spinuzzi (2015) described. Due to the influence of
development models like Agile and Lean, many organizations hire Scrum
Masters, Agile Coaches, and so on, in lieu of a de facto project manager. Still, in
other organizations, no project manager exists. Instead, a digital management
system (such as a ticketing system) is the engine of project management. People
on the team are responsible for taking the lead at different times when/if needed.
In these situations, project leadership has more to do with an individual’s
specialization and how it complements a project or a problem than it does with
that person’s title.

Efficiency Models
Efficiency models are approaches to managing projects that intentionally seek to
eliminate waste and implement workflows that emphasize individuals, team, and
organizational productivity. Joanna Schreiber (2017) explained, “I use efficiency
management philosophies as an umbrella term to include philosophies, methods,
models, and frameworks focused managing people, resources, and projects in
terms of quality and/or speed” (p. 27). Historically, efficiency models were
developed to support the management of factories (e.g., Taylorism and Fordism).
Over time, efficiency models were adopted by managers in a variety of business
roles (Saval, 2014), including in the development of Lean (Gothelf & Seiden, 2013),
 Introduction 11

Six Sigma (George, Rowlands, Price, & Maxey, 2005), and Agile (Ratcliffe &
McNeill, 2012). Efficiency models exist under a scientific management paradigm
that has continued to be used to guide the activities of project management. For
example, Gantt charts—still used by many teams and project management
systems today—were introduced to help track progress and productivity (Gantt,
1903).

Development Teams
When I refer to development teams, I mean cross-functional teams that work in
tandem to solve problems for people by developing products, services, and
experiences. My definition of a development team is purposefully broad as a
means to include a range of people across disciplines who may participate in
project management activities. Some have referred to these kinds of teams
as creative teams (Brown, 2009). Others refer to them as cross-functional. As noted
previously, development teams can self-organize or have a designated project
manager (Berkun, 2008). In some organizational structures and situations,
development teams share in project management activities (Spinuzzi, 2015) as
a means for moving quickly to solve problems.

Decentralization
As a management phenomenon, decentralization is when decision-making and
control are delegated to other groups and people in an organization. While
Chapter 1 will describe decentralization in more depth, it is important to note
that when I refer to decentralization I am invoking the history of scaling organiza-
tional management (Yates, 1989), which introduces a spatial consideration to
development work. By spatial consideration, I mean how work is organized
internally at a company (e.g., Marketing handles promotional materials and
Human Resources hires and fires), but also where work occurs as many
organizations expand and add offices and workers across the world. In Yates’s
work, management activities, including decision-making and controlling, were
assigned to different parts of organizations as the business (or in this case, the
railroad) grew and became disbursed. When I discuss decentralization, I am
also referring to the current practice of self-organizing teams like we’ve seen
depicted in recent scholarship in technical communication (Spinuzzi, 2015).
Sometimes these teams are geographically disbursed, and other times they are
collocated, using workplace networks to communicate. These teams often have
some decision-making capabilities so that they can work faster. As well, decen-
tralized teams may use elements of Agile and Lean development methodologies,
which influence how they manage projects. Decentralized teams tend to engage
in project management activities together, with people taking the lead at different
times when/if needed.
12 Introduction

Participation
Johnson (1997) called our attention to “the audience involved” because they are
“an actual participant in the writing process who creates knowledge and
determines much of the content of the discourse” (p. 363, emphasis in original).
Johnson’s conception of involvement is closer to Participatory Action Researcher
Alice McIntyre’s (2008, p. 15) idea that true participation in projects is reliant
upon a sense of ownership over the work. McIntyre also suggests that effective
participation should be defined by the community where work is being done. In
the context of civic participation, Stave (2002) complicates this discussion by
arguing that the mechanisms used for involving people in decision-making are
what matter most, but the systems usually in place are not effective. She explained
what I suspect is true of many project managers who work to communicate
in ways that facilitate participation across multiple audiences, “We know what
we need to do; we just do not have good mechanisms for achieving it” (p. 142).
In this book, participation refers to all the audiences working with a project team
(including internal and external stakeholders), not necessarily a group of end users
dictating individual needs or technological requirements to the team. As noted
earlier in this Introduction, participation should not be compared to collabo-
ration, as coordinating participation represents a different communication
need in the context of project work. Also, participation as I conceive it no doubt
has a conceptual history in Scandinavian Design and Participatory Design
(Kensing & Greenbaum, 2013), and in Lawler’s (1986) work in high-involvement
management, but deviates from these traditions by specifically focusing on
project management in networked organizations.

Participatory Communication
When I refer to participatory communication, I mean composed exchanges and
interactions, serendipitous and improvised, between networked actors in the
workplace. As well, when I refer to participatory communication I also mean
exchanges or interactions that are intentional. In other words, actors that inter-
act with other actors purposefully, and with specific logics and with particular
goals in mind. There are several potential uses for a communication, such as
persuasion, sharing information, or coordinating work. Additionally, participa-
tory communication depends on the social coordination that Stacey Pigg (2014)
described as literate activity. That is, the ways in which people coordinate infor-
mation and work across personal and professional networks. In this way, I view
participatory communication as networked and relational.
In Chapter 3, I explain three overlapping concepts that characterize partici-
patory communication. Here I introduce these elements as a preview. The first
is that communication is reactive and intentional. By that I mean people often
read (analyze) and respond (compose a purposeful message) to a given situation.
 Introduction 13

The second is participatory communication tends to focus on future action,

a term I borrow from Pigg (2014). So, when analyzing and composing a response,
people tend to think about how this will influence future work situations and
opportunities. Lastly, participatory communication is systems-based, which
means it unfolds across flexible organizational networks made up of relationships,
behaviors, and feedback loops. The system is the context of participatory
communication, and provides a foundation for the first two characteristics.
Additionally, the system allows for what Spinuzzi (2015) calls “mutual
adjustment” (Chapter 2, Section 5, para. 2) or working in ways that is responsive
to communication situations and environments.

Organization
In this book, organizations are made up of multiple human and nonhuman
networks. Spinuzzi (2015) describes organizational networks operating as a kind
of adhocracy supported, in part, by information communication technologies.
Additionally, he explains these organizational networks as nonhierarchical,
temporary, flexible, and, as a result, adaptive. To illustrate, workers are not always
connected by bureaucracy, but by a nonhierarchical network of ties often
maintained and sustained by information communication technologies. In
organizational networks, “individuals coordinate their own work, by commun-
icating informally with each other” (Mintzberg, 1980, p. 324).
Central to the concept of organizational networks is networked individualism.
Networked individualism is a “social operating system,” which can be contrasted
with “the longstanding operating system formed around large hierarchical
bureaucracies and small, densely knit groups such as households, communities,
and workgroups” (Rainie & Wellman, 2012, Chapter 1, Section 2, para. 2). The
networked individual operates from the center of their own network that they
maintain and sustain by multitasking and simultaneously communicating
with multiple people across different conversations (Rainie & Wellman, 2012,
Chapter 1, Section 2, para. 2). Networked individuals use information communi-
cation technologies to exchange information with others and coordinate work
in ways that supports mutual adjustment.

The Research in this Book

The research cases illustrated in this book were specifically designed to help answer
a series of questions related to how development teams use communication in
order to participate in project management activities. While the research
methodologies and methods are briefly addressed, a more detailed account can
be found in Lauren (2017). There I explain how the research was conducted and
especially, how it was analyzed to produce the findings for this book. Table 0.1
demonstrates how the research was split up into phases for organizational
14 Introduction

purposes, although, following the recommendation of Yin (2009), the results were
analyzed broadly across cases.
The first case asked how do project managers and leaders talk about their
communication practices, strategies, and philosophies. To answer this question,
I arranged interviews with 14 participants (seven men and seven women) that
identified in some way as a project manager or leader. Upon completion, the
interviews were transcribed and coded. As mentioned earlier in this chapter,
an important point discovered across the interviews was that communication
was discussed in terms of safety. Although the participants I spoke with did think
a great deal about communication, they did not often reflect on it as a set of
integrated practices. They reflected on unexpected situations and circumstances
that were unexpected. Yet, many of the participants were able to name certain
moves or strategies previously used to create safety, but when asked for a guiding
philosophy, they struggled to come up with an overarching framework of their
own. The interviews also produced an essential concept of Chapter 4, which is
the importance of making space for people to participate in project management.
The second case focused on how two people experienced communication as
they managed projects in the moment. A common notion reported during the
first case study is how workplace communication is often situational, so a more
thorough examination of how people make decisions on-site was the focus of
the second case. When designing the second case, I recruited two participants
from the first case to participate in experience sampling, or a diary study, which
focused on certain communication events at work as they managed projects. Each
week we discussed the reports that were filed in an interview session. Through
this work I learned the role of leadership philosophy in approach to participatory
communication.
The final case describes a team at a multinational software development com-
pany as they adopt a change in workflow, and how it influences their perception
of safety. The team struggled through a workflow reorganization that suggested
new methods (e.g., journey mapping) and methodologies of working (e.g.,
Design Thinking) and new information communication technologies meant to
support this work in participatory ways. This case explains the disruptions and
contradictions the team faced, noting especially how participation can be

TABLE 0.1 Research Phases for the Book

Research Data Collected Sample Size Duration

Phase 1 Semi-structured interviews 14 participants Approx. 1–2 hours

Phase 2 Experience sampling 2 participants Approx. 4–5 weeks
Phase 3 Survey, semi-structured interviews, 6 participants Approx. 3–4 months
naturalistic observations, social
media analysis, activities reporting
 Introduction 15

challenging to arrange, sustain, and maintain. The case also ties together results
related to safety uncovered in Case 1 and Case 2. As the concluding case study
in the book, its results support and round out the discussion of the role of parti-
cipation to balance efficiency in project management.

What Is to Come
In the first chapter I describe a trajectory of decentralization and its influence
on project management. To do so, I discuss decentralization in the context of
organizations, development teams, development methodologies, project manage-
ment activities, and communication. The chapter explains how decentralization
has made it possible for teams to move more quickly and self-organize. As well,
the chapter explains the ways in which decentralization has shaped the work of
project management and project communication in meaningful ways. Decentral-
ization is an important context for participation as an exigence of communicating
project work in today’s development teams.
The second chapter frames a central concept in the book: participation. I argue
that project management is in the midst of a paradigm shift from an efficiency
model to a participative approach. To support this argument, I provide examples
of efficiency models in project management and explain how these approaches
now rely on communicating to gain the participation of teams and stakeholders
connected by an organizational network. In this view, efficiency and productivity
are outcomes of participation instead of the other way around. Furthermore,
the chapter argues that project management is a system and a methodology
for working that must be adapted to teams. I end the chapter introducing a parti-
cipative approach for communicating project management.
The third chapter argues that making space is an essential communication
concern of sharing in project management based on the results of the first case
study. By making space, I argue that project managers communicate to extend
a symbolic invitation to participate in project work. The invitation serves as an
opportunity for people to exercise agency. The case assembles the themes of the
interviews into factors project managers consider when making space as work-
place writers, and the strategies they use to invite teams and stakeholders to
participate in project work.
In the fourth chapter, I describe the role of leadership values in shaping com-
munication practices and strategies. To do so, I focus on two metaphors used to
describe project management: gardening and cooking,2 and describe the values
of each leadership approach. The chapter forwards the argument that leadership
identity relies on a project manager’s positionality on their team and in their
organization. Furthermore, I argue that project management leadership is a
rhetorical performance that relies on engagement from teams to be effective.
The fifth chapter demonstrates how participation works across a development
team that is managing a large-scale change project. Through focusing on the team’s
16 Introduction

workflow, readers get a sense of the disruptions and contradictions that surface
in a participative framework. The research presented in this chapter also builds
off the cases in the previous chapters to demonstrate how participation is essential
to managing change. An important takeaway from this chapter is that disruptions
in workflow can prove productive if they lead to participation and improved
efficiency.
The final chapter, Chapter 6, summarizes the chapters of the book and offers
a rhetorical framework for the communication strategies and practices discovered
within and across each case study. The chapter discusses the role of agency and
kairos in communicating project management and explains the importance of
communication aims that focus on coordination genres in participatory
frameworks. As such, the takeaways in this chapter are particularly noteworthy
for practitioners and instructors of technical communication.

Conclusion
The goal for this Introduction was to introduce this book. Specifically, I explained
the motivation for writing this book—to better understand and theorize
the relationship between efficiency and participation. I also introduced the con-
nection of my work to technical communication, noting that project management
is a form of technical communication. I also explained how I relate to the topic
of project management, particularly highlighting the importance of team jelling
and the influence of the physical and emotional environment on project work.
Then I reviewed important terms and situated them in the literature of project
management and technical communication. After reviewing the research in this
book, I also previewed the chapters to come.
While there will be more substantial takeaways for practitioners in future
chapters of this book, in this first chapter I hope it was clear that project managers
often work as technical communicators. That is, project managers work within
information and make it accessible to people who need to use it. As a result, it
is important to understand the work of project management as audience-
involved, and that those who are leaders understand their role as “technical
rhetoricians” (Johnson-Eilola, 2005). This view of project management is key to
balance its focus on efficiency with participation because it gives presence to the
human elements of managing projects.
In the next chapter I begin with a question: how did participation become so
important to managing projects for development teams? To answer this question,
I explain how decentralization, a process key to scaling organizations, plays an
important role in how people participate in project management. As such, I
assemble histories of decentralization and its influence on organizations, teams,
project management methodologies, and communication.
 Introduction 17

Notes
1 Mintzberg (2013) suggested managers spend 80% of their time communicating.
2 I’d like to acknowledge Bill Hart-Davidson, who initially helped me develop the meta-
phors that brought about The Gardener and The Chef as we talked over the research
in this book.

References
Agboka, G. Y. (2013). Participatory localization: A social justice approach to navigating
unenfranchised/disenfranchised cultural sites. Technical Communication Quarterly,
22(1), 28–49.
Allen, O. J., & Deming, L. H. (1994). Publications management: Essays for professional
communicators. Amityville, NY: Baywood Pub. Co.
Berkun, S. (2008). Making things happen: Mastering project management. Sebastopol, CA:
O’Reilly Media, Inc.
Blythe, S., Grabill, J. T., & Riley, K. (2008). Action research and wicked environmental
problems: Exploring appropriate roles for researchers in professional communication.
Journal of Business and Technical Communication, 22(3), 272–298.
Brewer, P. E. (2015). International virtual teams: Engineering global success. US: IEEE
Press.
Bridgeford, T., & St. Amant, K. (2015). Academy-industry relationships and partnerships:
Perspectives for technical communicators. Amityville: Routledge Ltd.
Brown, T. (2009). Change by design: How design thinking transforms organizations and
inspires innovation. New York: HarperCollins.
Burnett, R. E. (1991). Substantive conflict in a cooperative context: A way to improve the
collaborative planning of workplace documents. Technical Communication, 38(4),
532–539.
Burnett, R. E., & Duin, A. H. (1993). Collaboration in technical communication: A
research continuum. Technical Communication Quarterly, 2(1), 5–21.
Burnett, R.E., Cooper, L.A., & Welhausen, C.A. (2013). What do technical communicators
need to know about collaboration? In J. Johnson-Eilola and S. A. Selber (Eds.), Solving
problems in technical communication (pp. 455–477) [Kindle version]. Retrieved from
Amazon.com.
DeMarco, T., & Lister, T. R. (2013). Peopleware: Productive projects and teams (3rd ed.).
Upper Saddle River, NJ: Addison-Wesley.
Dicks, R. S. (2004). Management principles and practices for technical communicators. New
York, NY: Longman.
Dicks, R. S. (2013). How can technical communicators manage projects? In J. Johnson-
Eilola and S. A. Selber (Eds.), Solving Problems in Technical Communication (pp.
310–332) [Kindle version]. Retrieved from Amazon.com.
Edmondson, A. (1999). Psychological safety and learning behavior in work teams.
Administrative Science Quarterly, 44(2), 350–383.
Faber, B. D. (2002). Community action and organizational change: Image, narrative, identity.
Carbondale: Southern Illinois University Press.
Flammia, M, Cleary, Y., & Slattery, D. M. (2010). Leadership roles, socioemotional
communication strategies, and technology use of Irish and US students in virtual teams.
IEEE Transactions on Professional Communication, 53(2), 89–101.
18 Introduction

Friess, E. (2011). Politeness, time constraints, and collaboration in decision-making

meetings: A case study. Technical Communication Quarterly, 20(2), 114–138.
Gantt, H. (1903). A graphical daily balance in manufacturing. Transactions of the American
Society of Mechanical Engineers, 24, 1322–1336
George, M. L., Rowlands, D., Price, M., & Maxey, J. (2005). The Lean Six Sigma pocket
toolbook: A quick reference guide to 100 tools for improving quality and speed. New York:
McGraw-Hill.
Gothelf, J., & Seiden, J. (2013). Lean UX: Applying Lean principles to improve user experience.
Sebastopol, CA: O’Reilly Media, Inc.
Hackos, J. A. T. (2007). Information development: Managing your documentation projects,
portfolio, and people. Indianapolis, IN: Wiley Technology Pub.
Hamilton, R. (2009). Managing writers: A real world guide to managing technical
documentation. Laguna Hills, CA: XML Press.
Hart, H., & Conklin, J. (2006). Toward a meaningful model of technical communication.
Technical Communication, 53(4), 395–415.
Hart-Davidson, W. (2001). On writing, technical communication, and information
technology: The core competencies of technical communication. Technical
Communication, 48(2), 145–155.
Hutchins, E. (1995). Cognition in the wild. Cambridge, MA: MIT Press.
Johnson, R. R. (1997). User-centered technology: A rhetorical theory for computers and other
mundane artifacts. Albany: State University of New York Press.
Johnson-Eilola, J. (2005). Datacloud: Toward a new theory of online work. New York:
Hampton Press.
Jones, N. N. (2016). Found things: Genre, narrative, and identification in a networked
activist organization. Technical Communication Quarterly, 25(4), 298–318.
Kensing, F., & Greenbaum, J. (2013). Heritage: Having a say. In J. Simonson and T.
Robertson (Eds.), Routledge International Handbook of Participatory Design (pp. 21–36)
[Kindle version]. Retrieved from Amazon.com.
Killingsworth, M. J., & Jones, B. G. (1989). Division of labor or integrated teams: A crux
in the management of technical communication? Technical Communication, 36(3),
210–221.
Lannon, J. M, & Gurak, L.J. (2017). Technical Communication (14th ed.). Essex, England:
Pearson Education Limited.
Lauren, B. (2017). Experience sampling as a method for studying in situ organizational
communication. Journal of Organizational Knowledge Communication, 3(1), 63–79.
Lawler, E. E. (1986). High-involvement management. San Francisco, CA: Jossey-Bass.
Levin, G. (2010). Interpersonal skills for portfolio, program, and project managers. Vienna,
VA: Management Concepts, Inc.
Longo, B. (2000). Spurious coin: A history of science, management, and technical writing.
Albany: State University of New York Press.
Markel, M. (2015). Technical communication (10th ed.). Boston, MA: Bedford/St. Martin’s.
McIntyre, A. (2008). Participatory Action Research. Los Angeles: Sage Publications.
Mintzberg, H. (1980). Structure in 5’s: A synthesis of the research on organization design.
Management Science, http://dx.doi.org/10.1287/mnsc.26.3.322.
Mintzberg, H. (2013). Rise and fall of strategic planning. Riverside: Free Press.
Morris, P. W. G., Pinto, J. K., & Söderlund, J. (2011). Introduction: Towards the third wave
of project management. The Oxford handbook of project management (pp. 1–11).
Oxford and New York: Oxford University Press.
 Introduction 19

Paretti, M. C., McNair, L. D., & Holloway-Attaway, L. (2007). Teaching technical

communication in an era of distributed work: A case study of collaboration between
U.S. and Swedish students. Technical Communication Quarterly, 16(3), 327–352.
Pigg, S. (2014). Coordinating constant invention: Social media’s role in distributed work.
Technical Communication Quarterly, 23(2), 69–87.
Potts, L. (2014). Social media in disaster response: How experience architects can build for
participation. New York: Taylor & Francis.
Project Management Institute (PMI) (2013). The project management body of knowledge
(5th ed.). Newtown Square, PA: Project Management Institute, Inc.
Rainie, H., & Wellman, B. (2012). Networked: The new social operating system [Kindle
version]. Retrieved from Amazon.com.
Ratcliffe, L. & McNeill, M. (2012). Agile experience design: A digital designer’s guide to Agile,
Lean, and continuous. Berkeley, CA: New Riders.
Rude, C. D. (2009). Mapping the research questions in technical communication. Journal
of Business and Technical Communication, 23(2), 174–215.
Salvo, M. J. (2001). Ethics of engagement: User-centered design and rhetorical
methodology. Technical Communication Quarterly, 10(3), 273–290.
Saval, N. (2014). Cubed: A secret history of the workplace. New York: Random House.
Schreiber, J. (2017). Toward a critical alignment with efficiency philosophies. Technical
Communication, 64(1), 27.
Schriver, K. (2012). What we know about expertise in professional communication. In
V. W. Beringer (Ed.), Past, present, and future contributions of cognitive writing research
to cognitive psychology (pp. 275–312). New York, NY: Psychology Press.
Schwarzman, S. (2011). Technical writing management: A practical guide. Publisher:
Author.
Simmons, W. M. (2007). Participation and power: Civic discourse in environmental policy
decisions. Albany: State University of New York Press.
Simmons, W. M., & Grabill, J. T. (2007). Toward a civic rhetoric for technologically and
scientifically complex places: Invention, performance, and participation. College
Composition and Communication, 58(3), 419–448.
Spinuzzi, C. (2003). Tracing genres through organizations: A sociocultural approach to
information design. Cambridge, MA: MIT Press.
Spinuzzi, C. (2005). The methodology of participatory design. Technical Communication,
52(2), 163–174.
Spinuzzi, C. (2015). All edge: Inside the new workplace networks [Kindle version]. Retrieved
from Amazon.com.
Stave, K. A. (2002). Using system dynamics to improve public participation in
environmental decisions. System Dynamics Review, 18(2), 139–167.
Whittemore, S. (2015). Rhetorical memory: A study of technical communication and
information management. Chicago, IL: University of Chicago Press.
Winsor, D. A. (2003). Writing power: Communication in an engineering center. Albany, NY:
University of New York Press.
Yates, J. (1989). Control through communication: The rise of system in American
management. Baltimore, MD: Johns Hopkins University Press.
Yin, R. K. (2009). Case study research: Design and methods (4th ed.). Thousand Oaks, CA:
Sage Publications.
1
DECENTRALIZATION AND
PROJECT MANAGEMENT

Communication in an organization . . . is not a means of organization. It is the

mode of organization.
(Drucker, 2009, p. 267, emphasis in original)

There is no one best way to organize. The right structure depends on prevailing
circumstances and considers an organization’s goals, strategies, technology,
people, and environment. Understanding the complexity and variety of design
possibilities can help create formal prototypes that work for, rather than against,
both people and collective purposes.
(Bolman & Deal, 2013, p. 67)

After losing to the Dallas Mavericks in the 2011 NBA finals, Miami Heat Coach
Erik Spoelstra spent his off season rethinking the team’s offense. Spoelstra spoke
with a number of renowned sports coaches, but it was after talking with Chip
Kelly (at that time the Head Coach of the Oregon Ducks college football team)
that he developed the idea of the “pace and space” offense that eventually helped
propel the Heat to back-to-back championships in 2012 and 2013. Spoelstra
wanted the team to play at a fast pace—to change the rhythm of the game in
ways that would take advantage of the players’ athleticism. To make that kind
of space, he wanted the team to spread out across the floor because it would
empower them to be creative—to read and react to what was presented by an
opponent’s defensive scheme. For a pace and space offense to work, the coaching
staff had to prepare players to make good decisions. Coaches also had to let go
of more traditional ways of controlling the team, such as always calling a timeout
during the final moments of a close game. A pace and space offense can also
be characterized as a decentralized approach to managing teams because it
 Decentralization and Project Management 21

empowers players to make decisions based on their read of the moment, and as
a result, the team is held accountable to each other for mistakes or poor choices.
At many organizations and institutions, comparable forms of decentralization
have become so pervasive that they have changed the work of development teams
and the implementation of project management communication. In many ways,
decentralized decision-making at the managerial level is used to produce the same
sort of outcomes Spoelstra wanted for the Heat. For example, decentralization
is used to create a faster rhythm for project work, to make space for creativity
and innovation, to avoid micromanaging decisions, to empower teams to
innovate on their strengths, and to make people accountable to each other. The
goal of this chapter is to explain how decentralization provides an important
context for understanding project managers as writers. This chapter explains
the impact of decentralization on teams and teaming, project management
methodologies, and project managers in general. The chapter begins with a
more detailed explanation of decentralization and contrasts it with centralization.
Then, the chapter explains how decentralization has influenced development
work. The chapter continues by discussing how project management method-
ologies were developed from scientific management to support decentralized ways
of organizing work. The chapter ends by overviewing the effects of decentraliza-
tion on communication at the project level of organizations.

Decentralization
The structure of an organization often depends on its size and its business goals.
Organizations with thousands of employees must decentralize managerial control
as no single person or group could realistically oversee the work of each person
in the company. On the other hand, start-ups with just ten employees may not
need to decentralize decision-making and control for the company to meet its
goals, unless it is positioned as a strategy for growing or evolving a business. At
root, decentralization is about structuring an organization to delegate control
(or decision-making) to other units or teams. Such organizational structures are
not limited to businesses, however. Democratic governments, like the United
States, generally operate under a decentralized model. Elected officials at the state
or local level proceed over laws and regulations in each state, county, province,
or city. In these instances, those in power are expected to involve people in
decisions about legislation, regulations, elections, and services (or they may be
voted out of office).
Decentralization can be contrasted with centralization, which is a more
concentrated form of decision-making and control. Centralization tends to grant
power for decision-making and control with a single person or group. While some
might bristle at the idea of a single decision-maker because of the power impli-
cations, centralization has practical applications that are useful for many
organizations and institutions. For instance, a judge oversees hearings to ensure
22 Communicating Project Management

the law is interpreted and followed appropriately. Yet, in the context of

organizations that develop products and services, management centralization and
decentralization can be understood as points on a continuum, not an either/or
classification. Mintzberg (2013) detailed this continuum from maximal (mostly
centralized control) to minimal managing (mostly decentralized control) (see pp.
102–107), noting that the management extremes at either end of the continuum
can exist, but are not common. That is, many organizations are purposefully
structured with both centralized and decentralized forms of control and decision-
making in different units or departments. As a result, an organization’s use of
decentralization is generally strategic and practical, meant to help a business meet
fiscal, productivity, or quality benchmarks.
As a mechanism for oversight and management, decentralization also enables
organizations to scale, making it easier to acquire new companies that have their
own management team. As well, it helps organizations hire remote or distributed
employees. When a company decentralizes decision-making and control to
different groups inside the organization, the structure forwarded suggests flatter
hierarchies and less oversight will improve productivity, quality, and/or efficiency.
There are a range of case studies about how decentralization functions in different
workplace contexts. For example, Richards and Culp (2001) described how the
Richards Group decentralized to encourage a culture of creativity and innovative
thinking, while Brafman and Beckstrom (2006) provided a series of case studies
about how the internet facilitated more radical forms of leaderless decentraliza-
tion, such as file-sharing and other online communities.1 In the latter, organiza-
tion of people relied heavily on technology and on the motivation of those
participating in the communities to self-organize around a given topic or interest.
Conceptually, decentralization draws from a systems approach to organizing
work. In a systems approach, management of organizations is achieved through
understanding relationships and processes holistically instead of separating
companies into individual parts or units (Ackoff, Addison, and Carey, 2010). A
good example of a systems view of management in practice is demonstrated by
organizational charts. Organizational charts show how companies operate as an
interconnected, hierarchical system. Figure 1.1 illustrates a traditional organiza-
tional hierarchy. To make decentralization work, managers use reporting
meetings and schedule regular “check-ins” to discuss ongoing work, particularly
to problem-solve specific obstacles of interest to upper management. The degree
to which decentralization and centralization oscillates in organizational
hierarchies is highly dependent on company culture, business goals and mission,
and the kinds of problems that surface.
If we compare Figure 1.1 to Figure 1.2, there is a clear difference in the intended
hierarchy. In Figure 1.2, the hierarchy of the system is much flatter, and so
power is decentralized. Everyone, aside from the owner of the company, exists
on the same level. There are many examples of companies today that use both
approaches successfully in theory, but as systems thinking reminds us, every
 Decentralization and Project Management 23

FIGURE 1.1 Traditional Organizational Hierarchy

FIGURE 1.2 Flat Organizational Hierarchy

hierarchy produces certain behaviors that influence the way decentralization and
centralization are practiced. In other words, Figure 1.1 and 1.2 demonstrate how
companies organize to decentralize decision-making and control, but the figures
do not capture the social factors of organization, such as company culture. An
organizational chart cannot capture how decentralization is implemented or how
24 Communicating Project Management

it propagates relationships across implied hierarchies of influence and creates

alliances across groups of people. However, project managers often have a unique
view of these conflicting hierarchies and social systems.
Decentralization is an important starting point for our inquiry into communi-
cating project management because it introduces what has become a common
work structure for development teams. Decentralization also helps to explain why
writing is so important to the work of project managers. Structures alone cannot
cultivate participation across all the different audiences at work. Winsor’s (2003)
work extensively documented the power relationships present in the mechan-
isms and artifacts used by managers, particularly demonstrating how they used
specific genres to reinforce their positions of power. And, as Bolman and Deal
concluded:

A team structure emphasizing hierarchy and top-down control tends to

work well for simple, stable tasks. As work becomes more complex or the
environment gets more turbulent, structure must also develop more
multifaceted and lateral forms of communication and coordination.
(Bolman & Deal, 2013, p. 112)

Project management, often made up of learning and knowledge-making and

relating communication activities, can certainly be described as complex because
so much of it is nonlinear, which can appear messy. Project managers tend to
communicate most often through and around the work of development teams
in the role of mediator and advocate.

Decentralized Development Teams

Many of today’s technology companies have expanded operations across the world
in part to be competitive in the global economy, and to take advantage of a global
talent pool. For these organizations, decentralization is a way of survival. In
globally distributed companies, for instance, teams are comprised of people
who may live in different regions, think in different languages, and work in office
spaces with vastly different social dynamics. Alone, the challenges of working
across such distance is difficult, but when teams self-organize across such cultural
and physical distance, another layer of complexity is added to communication
and participation (see Brewer, 2015). Operating in such complex circumstances
results in many organizations and institutions decentralizing control to depart-
ments, divisions, and teams out of necessity. By control, I mean “the mechanism
through which the operations of an organization are coordinated to achieved
desired results” (Yates, 1989, p. xvi). Project management activity often works
to control the scope of a project (the work that will and will not be done). It also
controls other project-related tools and resources, such as content management
systems, schedules, budgets, meetings, development methodologies, and so on.
 Decentralization and Project Management 25

To support coordinating the work of globally distributed teams, decentralization

is indeed useful.
Control over team processes and procedures is essential to project manage-
ment practice, but decentralization influences how control is communicated. As
teams share in control of project management activities, a more democratic
process of decision-making theoretically takes hold. To help show how this
democratic process works, Spinuzzi (2015) explained that traditional command-
and-control approaches to managing these teams may not be useful. Rather, he
cited Malone (2004) to argue these teams may better respond to coordinate-and-
cultivate approaches (Spinuzzi, 2015, Chapter 2, Section 5, para. 6). Coordinating,
in this instance, means communicating in ways that help people share information
in reliable and efficient ways. Cultivating, on the other hand, means communi-
cating as a facilitator of project work, such as arranging meetings, developing
action plans, or soliciting feedback. Decentralized teams that share in project
management activities require different kinds of support. Sometimes the support
is finding an automated system that help keep teams organized. In other
instances, shared control is achieved through co-writing project documents, like
charters.
While managers in the 1900s believed that decentralization had the potential
to breed satisfaction at work (Yates, 1989), the autonomy it provides also
positions organizations to rethink how to support decentralized project teams.
No doubt the affordances of mobile technology and the internet support
innovative approaches to communicating project management through informa-
tion communication technologies. Brown (2009) and many others have explained
how the decentralized nature of the internet forces companies to rethink how
organizations structure work in general. Thus, decentralization is useful for
organizations from a functional standpoint because it affords employees the ability
to manage their own schedules, which is useful for companies with many
divisions and projects. In other instances, decentralization can be implemented
as a flattened structure for cultivating innovation and creativity to help develop
new products or services, or to solve particularly challenging problems. In this
way, the mobile affordances of the internet also contribute to how project
managers communicate to support decentralized work.
Even so, decentralized teams can sometimes be criticized for being trendy or
even unnecessary. For example, Mintzberg (2013) essentially suggests that decen-
tralized power is an illusion because executive managers can always take control
back. As well, Goldratt and Cox (2014) explain that companies seem to go
through a constant process of centralization and decentralization, referring
to these organizational shifts an ever turning “merry-go-round” (p. 285) that
starts by

arranging the company according to product lines and then changing it

according to functional capabilities and—vice versa. Deciding that the
26 Communicating Project Management

company is wasting too much money on duplicated efforts and thus

moving to a more centralized mode. Ten years later, we want to encourage
entrepreneurship and we move back to decentralization. Almost every
big company is oscillating, every five or ten years from centralization to
decentralization, and then back again.
(Goldratt & Cox, 2014, p. 286)

Treating centralization and decentralization as an ongoing process perhaps

suggests self-organizing is more of a trend than a transformation—a recycling
of ideas that we see organizations and institutions engage in on a regular basis.
And not every organization uses self-organizing teams for all their work. As
explained earlier, decentralization is not an all-or-nothing phenomenon. But,
many organizations use it for certain kinds of work and activities. Specifically,
decentralization has had an important effect on how development projects get
managed and are organized.
Goldratt and Cox (2014) also characterize decentralized teams as entrepre-
neurial. At the organizational level, the term used to describe entrepreneurial work
is intrapreneurial. Intrapreneurial approaches are useful for helping organizations
innovate from the periphery (Antoncic & Hisrich, 2003). We’ve seen companies
like Google offer programs like “20% time,” where employees are granted one-
fifth of their work hours to innovate and develop their own ideas (although
the program is not without controversy2). While this scholarship characterizes
decentralization with different terminology, it seems clear that many companies
that develop digital technologies, services, and products have, for quite a while,
decentralized control and encouraged innovation by creating a variety of
structures (e.g., work groups, committees, intrapreneurship programs) to various
ends that support business goals. These mechanisms require writing in partici-
patory ways to be successful.
It is also important to note that market trends have also changed in recent
years, which has influenced development team processes as well. To be com-
petitive today, companies that develop technologies, products, and services must
continuously upgrade and develop their business model and quickly get products
on the market. As Spinuzzi (2015) explained, working at this rapid a pace
requires self-organized teams that are structured to move quickly. Decentralized
teams become essential to the business’s success because of how efficient they
can be. And as Yates (1989) documented, organizations also decentralize to
become more internally efficient. Interest in efficiency, higher levels of market
demand, and ongoing development of innovative technologies also led to the
rise of methodologies to support decentralized teams. As we see in the next section,
decentralized methodologies also come with a set of challenges related to
participation.
 Decentralization and Project Management 27

Decentralization and Development Methodologies

As organizations decentralized control and decision-making to help scale their
work, methods were developed to make labor more efficient. Initially, this man-
agement work was done in factories in the early 1900s and was eventually
conceptualized as “scientific management,” a term coined by lawyer and Supreme
Court Justice Louis Brandeis in 1910 (Lepore, 2009). Scientific management
focused a great deal on cultivating efficiency. As Longo (2000) recounted,
Frederick Taylor began by thinking about carrots and sticks. That is, “Workers
were paid according to their individual performance” (Longo, 2000, p. 100). The
political cartoons at that time often depicted Taylor with a stopwatch and
exhausted workers under his constant surveillance. As the principles Taylor
forwarded were taken on and developed by others, some debate surfaced about
the ways in which people were participating in the management of business. Jill
Lepore (2009) recounted these conversations, noting that Frank and Lillian
Gilbreth favored more democratic input from workers, despite also being
champions of efficiency. Lillian Gilbreth’s work, in particular, proved important
because it used efficiency as a guidepost for living life at work and at home to
maximize “Happiness minutes” (as quoted in Lepore, 2009, para. 24). In her work,
Gilbreth balanced the need for efficiency with the toll of fatigue, a critique many
of Taylor’s workers leveraged regarding his management system (Lepore, 2009).
The early work of scientific management presented an interesting contradiction:
while organizations were decentralizing control and decision-making to scale
their work, they were also operating under a centralized model within newly
created departments. In other words, scientific management was undoubtedly
preoccupied with centralized control as a means for creating efficient processes,
but heavily relied on participation from well-trained employees across an
organization to do so.
As noted earlier, Yates’s (1989) works also accounts for how the American
railroad industry faced several organizational challenges as their business
operations expanded around the turn of the 20th century. A solution to some
of the challenges was to decentralize management to help scale the work of the
organization as it grew. Yates accounted how much of this work was done
through creating access to information through information communication
technologies, filing systems, and standardizing internal forms and reports. The
coordination that decentralization required was far more difficult to arrange at
that time because it took several days for information to securely travel by horse-
back from one office to the next. The need for organizations like the American
railroad to scale operations through decentralizing control in part led to the need
for project managers, which “grew out of the practical problems raised by
coordinating activities in complex undertakings” (Söderlund, 2011, p. 39).
When project management as a practice began to formalize in the 1950s, it
was “by the US Air Force to integrate the engineering and production of its
28 Communicating Project Management

technologically complex, urgent missile development programs” (Morris, Pinto,

& Söderlund, 2011, p. 1). From the beginning, the work was heavily invested in
writing. As Söderlund (2011, p. 39) explained, “Initially, Gantt charts, work
breakdown structures, and planning techniques played key roles which rooted
project management in an operations management tradition that was principally
developed for practitioners who needed tools and techniques to improve
efficiency of project implementation.” As practices evolved, there was still a very
clear interest in writing to breed efficiency as many organizations developed tools
and processes for improving project management, including the United States
Military (e.g., Program Evaluation Review Technique and Critical Path Method).
It was the ongoing failure of projects throughout the 1970s and 1980s, however,
that continued to push organizational interest in developing more effective and
efficient methods of management (Morris et al., 2011, p. 2).
Lean is one such management method, developed by Toyota in the 1980s, a
concept that, as Nick Saval (2014) explained, found its way into popular
management books like In Search of Excellence. In the 1990s and after, with the
rise and adoption of commercial computing technology (and the internet), the
work of project teams began to change substantially as they focused on software
development. By the early 2000s, organizations were developing digital products,
services, and experiences that significantly impacted how project managers
needed to communicate with teams. Final products were more loosely defined
and more cost-effective to change after the design phase of a project. Teamwork
became less linear and required more coordination. When development took to
screens, Waterfall approaches to managing projects seemed less appropriate as
organizations began to build experiences for people around products. As a result,
methodologies were created to change development processes of digital artifacts.
Just as operations management influenced early forms of project management,
software development methodologies have been instrumental in shaping how
projects get managed today. These development methods—Agile, Lean, and so
on—decentralized project management activities as they emphasized the need
for more participatory communication across teams and stakeholders. These
development methodologies were team-based, and it became more common for
teams to share in what were traditionally centralized project management
activities (such as estimating timelines and schedules). These methodologies
introduced new processes and terminology for communicating about develop-
ment work as well.
While there are many decentralized development methods, I overview three
approaches to provide an example of how they support decentralized project
management. To be clear, development approaches can be understood as what
John Law (2004, p. 10) calls “a philosophy of method” or “methodology.” That
is, they have a very clear rationale attached to them, such as products are best
developed by involving people in the design process. Essential to these methodo-
logies, as well, are concepts of efficiency and flexibility as bedrock principles for
 Decentralization and Project Management 29

managing the work of development teams. While I will discuss this topic area in
depth in Chapter 2, it is worth noting here that development methodologies
should also be understood as methodologies that influence how project managers
communicate, not just as tools or techniques for developing digital artifacts. Also,
a point of clarification: my goal for the coming paragraphs is to give some context
about how development methodologies draw from decentralized approaches to
help structure the communication needed to support teamwork. I specifically
avoid purist debates about what qualifies as Agile or Lean—a conversation I believe
not relevant to this book and its offerings.

Agile Development
In February 2001, The Agile Manifesto was conceptualized by a group of
“organizational anarchists” (Highsmith, 2001, para. 2), who worked together to
describe a set of shared values for approaching software development. In History:
The Agile Manifesto, Jim Highsmith explains,

Agile Methodologists are really about ‘mushy’ stuff, about delivering good
products to customers by operating in an environment that does more than
talk about “people as our most important asset” but actually “acts” as if
people were the most important.
(Highsmith, 2001, para. 5)

The Agile Manifesto appeared to contribute to a human-focused turn in how

contemporary software development teams are managed. Agile falls in the
tradition of other human-centered approaches to workplace design, such as in-
house magazines (Yates, 1989) or Participatory Design (Spinuzzi, 2005). As a
methodology, Agile was also developed to help teams self-direct their work and
improve efficiency over more traditional development methods, such as
Waterfall. Agile is a methodology for developing software and managing people,
and is used widely in many workplaces today—even by those that do not
necessarily engage in software development activities. In practice, Agile is as much
a philosophy of the importance of flexibility in learning as it is a procedural way
of working.
Agile organizes teams into short periods of intense work called “sprints,” which
generally last around two weeks, although they can be longer or shorter. During
that period of time, the team is co-located, and works toward delivering software
for a product owner, even if it is just a modest feature of the software. Agile teams
tend to communicate more frequently, often through specific kinds of meetings
like stand-ups or Scrums. Agile comprises a code-and-fix mentality, where teams
work quickly and efficiently by self-organizing and communicating frequently
about how to improve their internal processes and procedures through
retrospective meetings, which are usually scheduled at the end of a sprint. Agile
30 Communicating Project Management

has become relatively popular in the early 21st century and, as a result, has been
adapted to contexts outside of software development. In this book, for example,
the research participants are project managers and leaders that have worked with
flexible methods in the context of higher education, government agencies,
information technology companies, and medical organizations, but what makes
them “Agile” varies a great deal by what aspects of the methodology have been
adopted to their workplace context. More, as discussed in Chapter 3, many of
my participants claimed Agile was mostly a buzzword because the methodology
had been diluted by large-scale adoption. As a term, it seems Agile is often used
to describe a range of flexible working methods. Flexible approaches for
developing software and managing people are used widely in many workplaces
today.

Lean Development
Lean production is another model that works to simplify bureaucracy by keeping
employee numbers low and productivity high. It is also a management efficiency
model descended from concepts forwarded by Taylorism and Fordism (Schreiber,
2017). Even so, Lean demonstrates how companies, like Toyota, have become
quite successful by dismantling hierarchies, a key component of shared project
management: “Lean production calls for learning far more professional skills and
applying these creatively in a team setting rather than in a rigid hierarchy”
(Womack, Jones, & Roos, 2007, p. 12). The reevaluation of workplace hierarchies
was also forwarded by the approach, although it initially caused increased
stress: “‘workers’ may find their work more stressful, because a key objective
of lean production is to push responsibility far down the organizational ladder”
(Womack et al., 2007, p. 12). In Lean, control was delegated to employees rather
than to a single empowered manager.
The philosophy of Lean production has also been adapted to user experience
design and research, where teams intently focus on rapidly bringing value to
a project. Gothelf and Seiden (2013) outlined the approach emphasizing three
essential tenets. The first was to remove waste, especially in terms of the time
and effort it takes to document design practices (p. xiii). The second was to
“harmonize” cross-functional teams, including clients and users (pp. xiii–xiv).
The last concept was to employ an iterative design approach that does away with
the “hero designer” mindset (p. xiv). These three principles allow teams to move
quickly, and gives them room to make rapid decisions during the design process.
To cut waste, Lean focuses designers on developing the Minimal Viable Product
(MVP) to get to market faster. That is, if I brought a company an idea for a new
mobile application, a Lean approach would focus our initial effort on defining
the MVP of the product in order to release it faster. Then future iterations
would work on rapidly developing iterations of that MVP. Lean teams aim to
 Decentralization and Project Management 31

rapidly deliver working code, which is similar to concepts forwarded by Agile

development. Agile methods, however, grew out of a separate industry.

Six Sigma
Often combined with Lean, Six Sigma is not necessarily a development method-
ology, but a way for measuring a project system’s success. As such, Six Sigma
uses measurements that can be used to evaluate and improve development
systems. It is also compatible with user experience research and design, and is
often combined with elements of Lean and Agile. Six Sigma’s process improve-
ment model is based on what is called the DMAIC (Define, Measure, Analyze,
Improve, and Control). In this model, the project manager develops feedback
loops to learn how to make the team work in an efficient and sustainable manner.
Like Agile and Lean, Six Sigma is a systems approach to managing teams and
improving internal processes. Popular methods, such as Scrum, are often
combined with approaches outlined in Agile, Lean, or Six Sigma. For example,
an organization might arrange work into sprints with a daily Scrum, but hold a
retrospective meeting upon completing a sprint to engage in a Six Sigma process
improvement exercise. The outcomes of such discussions are then implemented
prior to beginning the next sprint, and so on. In some organizations, the role of
project managers becomes one of facilitating when working with decentralized
teams (Lund, 2011), in part to help them self-organize and to help them rapidly
complete project work.

How Decentralization Influences the Role of Project

Manager
While the position of project manager certainly still exists, there is also evidence
that it is being rethought in some organizations. Decentralized methodologies
influence the job and the role of a project manager on a team. For instance, Agile
teams might have an Agile Coach or a Scrum Master, whose role is to primarily
help the team adopt Agile principles. Those teams may also operate without
a project manager. There are also examples of shared project management
(Spinuzzi, 2015). In this book there are examples across the spectrum. For
example, some participants in later chapters worked in environments where
project management was communicated by an automated ticketing system.
Others explained they had traditional project managers engaged in planning,
organizing, leading, and controlling. And still others worked in a far more shared
approach to project management. Nevertheless, decentralized methodologies aim
to involve workers more in the management of development projects, whether
that is through offering feedback to communication workflows or taking a more
hands-on approach to creating schedules. To facilitate the implementation
32 Communicating Project Management

of decentralized methodologies, project managers had to develop flexible

communication skills and literacies.
Another way decentralization has impacted the role of project management
is through the development of information communication technologies.
Many of today’s development companies are networked, and as a result, a suite
of technologies are used to coordinate information across teams. The affordances
of these technologies will sometimes take the place of traditional project
management activities. Ticketing systems, for example, automate processes such
as assigning and tracking the completion of tasks. The system tells people how
long a ticket has been open and also how long until a ticket has been resolved.
For distributed teams, ticketing systems help to coordinate tasks and information.
There are other web-based systems as well, some of which visualize project
management processes similar to Gantt charts or Kanban boards. These
technologies help teams collaborate on tasks and track their own progress. The
role of project management in these systems is to help oversee the use of
technology and to shepherd information. A research participant in this book
described using project management systems in this way, and explained her team’s
newly hired project manager as monitoring the interplay between the information
communication technologies as a way to coach the team about their work
processes.
Project management has always responded to context and project needs, but
decentralization is also making the need for effective communication even more
essential. Teams can move more quickly, problem-solve collaboratively, and be
more creative (Rainie and Wellman, 2014). As a result, standardization of project
management activities, such as offered by The Project Management Body of
Knowledge, may not be a good fit for every organization and/or institution. The
process may be too prescriptive for the different kinds of projects that emerge
in these organizations. The autonomy of decentralized networks means that
project work can change and evolve rapidly. The project manager’s job has
historically worked to clearly define a project’s scope from onset to outset, but
in some team situations, especially where the goal is learning through research
activities, it is difficult to predict how project outcomes might change. In this
way, project management communication is often focused on facilitation and
coordination rather than to act as the primary source of project information.
Another shift is that many decentralized teams exist only temporarily to form
around specific kinds of projects. People are drafted onto these teams based on
their specialization and availability. As a result, every project and potentially every
project team dynamic can vary, although some teams are made up of coworkers
who are familiar with each other. Spinuzzi’s (2015) account of this points out
that one driving element of temporary teams is projectification (making
everything in an organization a project). He noted that some teams tends to rely
on organizational networks to move quickly, but those same teams can also
struggle with strategy. As development teams grapple with forming around so
 Decentralization and Project Management 33

many projects, they can also have to learn how to share in leadership of the work
in different ways. If teams truly can be understood as a social system (see Hoegl,
Muethel, and Gemuenden, 2011), then they must develop communication strate-
gies and norms for working together. These strategies are often reliant on tacit
approaches to communicating and interacting, especially as a means of increasing
capacity for getting work done. Importantly, these strategies and norms are
written—that is, they are designed most effectively through participation.

Decentralized Project Communication

The rise of decentralized forms of managing projects also came with new ways
of communicating across self-organizing teams. Many project communication
activities today are facilitated by information communication technologies and
traverse broad digital terrain. The division of labor on teams often changes from
project to project. Even so, “All divisions of labor, whether the labor is physical
or cognitive in nature, require distributed cognition in order to coordinate the
activities of the participants” (Hutchins, 1995, p. 176). Indeed, organizing and
coordinating this work is an act of writing. For methodologies like Agile or Lean
to work, teams need standardized practices of distributing their ideas and labor
across the team. For example, throughout a sprint, an Agile team often relies on
learning (requirements, user response to features, etc.), and since learning can
be unpredictable, coordinating information with others on the team is important,
especially if the direction of a sprint suddenly changes the direction of a project.
Agile teams create alignment mechanisms to communicate these changes, such
as meetings (with notes) and charters. On Lean teams, since one of the funda-
mental goals is to cut waste, the team must be in frequent contact to ensure
everyone is working toward the same goals, and this is usually done through face-
to-face contact in a co-located working environment. When development teams
decentralize control, they must design a communication plan that helps manage
shared decision-making. A communication plan is not a foil to efficiency and
flexibility, but a means of organizing work across a variety of projects and
initiatives. In this way, coordinating knowledge and cognition is ostensibly
writing.
Information communication technologies also make it possible for develo-
pment teams to be in near constant contact with each other. These kinds of
“decentralized networks are more efficient for creativity and collaborative
problem solving where people have more autonomy to find and use knowledge”
(Spinuzzi, 2015, Chapter 7, Section 5, para. 6). There are suites of technologies
used to support a range of communication opportunities—from synchronous
video and voice chatting to asynchronous instant messaging, but more
importantly, they require different kinds of literate activity (see Pigg, 2014). As
communication in the workplace exists across groupings of tools, resources,
and activities, so do the spaces and places where people communicate. Digital
34 Communicating Project Management

technology enables workers the flexibility to be mobile, even within the physical
barriers of their own organizations. Some companies facilitate mobile working
styles by modifying the work environment. All of these changes certainly
communicate the values of the organization symbolically, but also require an
ability to use information communication technologies in flexible, audience-
centered ways.
As briefly explained earlier in this chapter, there are a number of different
kinds of decentralized communication approaches used to support and
coordinate communication across people and teams. These situations are used
to present opportunities to share information and solve problems. A good
example is a Scrum, which is a daily meeting where people huddle together to
engage in problem-solving activities. In Lean there is Kaizen, where teams engage
in an ongoing process of improvement by locating and removing waste from
processes. Project managers, or teams that share in project management activities,
facilitate these meetings by helping problem-solve and remove roadblocks. (As
composers of these meetings, if you will, that is the project manager’s role.) Project
managers are composers of Muse meanings. So, in Scrum, the team discusses
what someone has been working on, what they will be working on that day, and
what problems they need help solving. The project manager facilitates that
conversation through a range of communicative acts, such as active listening and
coordinating people who can help each other solve problems. In Kaizen, teams
follow a process of plan, do, check, act. There are other communication tools
meant to support participation, such as a Kanban Board (see Figure 1.3), a
retrospective meeting (where teams evaluate their internal processes and
procedures to improve them), and so on.
Movement toward thinking about project communication as networked is also
important to how project communication has been decentralized. To illustrate
these ideas, Rainie and Wellman (2014) coined a term: networked individualism.
Networked individualism is a decentralized practice because it involves how people
use digital, web-based networks to “connect, communicate, and exchange

FIGURE 1.3 Simple Kanban Board

 Decentralization and Project Management 35

information” (Chapter 1, Section 2, para. 2). The networked individual has

multiple opportunities for connecting with people through personal networks.
Organizations are also networked, and as a result, project communication can
seemingly occur at almost any moment, day or night. The ubiquitous need to
communicate and to be available is supported by organizational networks.
Although, as Rainie and Wellman (2014) note, these networked, decentralized
ways of communicating—of always being “on”—present many challenges to the
work–life balance of people on development teams. As well, many others have
argued that always being “on” is not mentally healthy and creates unrealistic
expectations for productivity and performance (Turkle, 2011; Wajcman, 2014).
The issue of always feeling available is particularly difficult for some
on dispersed or distributed teams, which is another common example of
decentralized communication for development teams. When globally distributed
teams share in project management activities, they must establish effective
teamwork skills: communication, coordination, balance of member contribu-
tions, mutual support, effort, and cohesion (Hoegl & Gemuenden, 2001, as cited
in Hoegl et al., 2011). Of communication, the authors explain the goal of people
on the team is “to increase not only their own performance but the performance
of the team as a whole” (Hoegl et al., 2011, p. 489). Furthermore, in shared
leadership situations, they cite work by Martins, Gilson, and Maynard (2004)
to explain “the individual starts a learning process of how (in the sense of ‘by
which communication media’) to approach other team members” (Hoegl et al.,
2011, p. 489). Finally, they conclude, “Team-shared leadership therefore fosters
active management of geographical distance (when to have face-to-face
meetings), and continuous reflection not only on the task, but also on the
communication strategy” (Hoegl et al., 2011, p. 489). This kind of deliberate and
reflective practice is helpful for decentralized project teams because project
management communication often grows more complex and nuanced. Further,
since development work often focuses on learning and making fast, effective
decisions in the moment, it is essential that teams learn to communicate in ways
that make space for people to participate in project work.

Conclusion
Organizations delegate control to make development teams more productive and
efficient, but decentralization can introduce unproductive power dynamics that
play out through communication activities. In short, decentralization is another
form of control. While there are more opportunities for participating in decisions
about work processes and procedures, and for making changes to unhealthy
system behaviors, individuals on teams must also perceive that space is available
for them to participate in those processes. Decentralization of project work is
only effective if people on teams can or will exercise their agency to participate.
That is, decentralized approaches requires people buy-in to the system, adopting
36 Communicating Project Management

specific philosophical views of leadership and work practices. But participation

can also be nonlinear, and as Stave (2002) argued, we need mechanisms in place
to support participation because just providing a structure and opportunities may
not actually cultivate it. In other words, structure alone does not create avenues
for exercising an individual’s or a team’s collective agency.
As well, decentralization cannot account for the implied hierarchies of
influence and unhealthy alliances that manifest themselves in organizations
or on teams. Brafman and Beckstrom (2006) argue that the more decentralized
a system becomes, the harder it is to control that system and hold a single person
or leader accountable. As a result, power dynamics inside systems can work against
the benefits of decentralization. As we’ve seen in the work of Winsor (2003) and
Spinuzzi (2003), power dynamics can manifest themselves in the documents
people use to circulate information, but also in the processes organizations ask
people to use to get work done. Work processes can be overly prescriptive,
controlled by outdated systems, misaligned with organizational needs, or just
plain inefficient. Such issues generate power dynamics that can work against
decentralized control in subtle, less visible ways that can promulgate power
disparity between workers. In these circumstances, a decentralized structure
alone cannot ensure individuals will participate fully in project work, which is
why effective communication is a central concern of this book.
This chapter provides a context for understanding why effective communica-
tion is essential for today’s development teams, and the next chapter builds
on these ideas to explain how decentralization has contributed to a shift in the
paradigm of project management. The chapter argues that teams today are
perhaps unknowingly operating under a participative paradigm for planning,
doing, and reflecting on project work, while using processes and tools that still
emphasize, above all, productivity and efficiency. This tension is important to
pay attention to because without participation, efficiency cannot be achieved.
To come to an understanding of how to communicate in ways that make space
for participation, project management as a discipline must position itself as a
methodology of contextual and situational praxis.

Notes
1 Peer-to-peer file sharing services, such as Torrents, create an organization of people
through sharing files across users. Self-organizing communities online, such as Reddit,
often develop community standards and norms that others are expected to follow if
they want to participate in the group.
2 See the article at www.businessinsider.com/google-20-percent-time-policy-2015-4.

References
Ackoff, R. L., Addison, H. J., & Carey, A. (2010). Systems thinking for curious managers:
With 40 new management f-laws. Devon: United Kingdom: Triarchy Press Limited.
 Decentralization and Project Management 37

Antoncic, B., and Hisrich, R. D. (2003). Clarifying the intrapreneurship concept. Journal
of Small Business and Enterprise Development. doi:10.1108/14626000310461187
Bolman, L. G., & Deal, T. E. (2013). Reframing organizations: Artistry, choice, and leadership
(5th ed.). San Francisco, CA: Jossey-Bass.
Brafman, O. & Beckstrom, R. A. (2006). The starfish and the spider: The unstoppable power
of leaderless organizations. New York: Penguin Group.
Brewer, P. E. (2015). International virtual teams: Engineering global success. United States:
IEEE Press.
Brown, T. (2009). Change by design: How design thinking transforms organizations and
inspires innovation. New York: HarperCollins.
Drucker, P. F. (2009). The essential Drucker: The best of sixty years of Peter Drucker’s essential
writing on management (reissued ed). HarperCollins e-books.
Goldratt, E. M., & Cox, J. (2014). The goal: A process of ongoing improvement (30th
anniversary ed.). Great Barrington, MA: North River Press.
Gothelf, J., and Seiden, J. (2013). Lean UX: Applying Lean principles to improve user
experience. Sebastopol, CA: O’Reilly Media, Inc.
Highsmith, J. (2001). History: The Agile manifesto. Retrieved from www.agilemanifesto.org/
history.
Hoegl, M., & Gemuenden, H. G. (2001). Teamwork quality and the success of innovative
projects: a theoretical concept and empirical evidence. Organization Science, 12(4),
435–449.
Hoegl, M., Muethel, M., & Gemuenden, H. G. (2011). Leadership and teamwork in
dispersed projects. In P. Morris, J. Pinto, and J. Söderlund (Eds.), The Oxford handbook
of project management (pp. 483–499). New York: Oxford University Press.
Hutchins, E. (1995). Cognition in the wild. Cambridge, MA: MIT Press.
Law, J. (2004). After method: Mess in science research. New York: Taylor & Francis.
Lepore, J. (2009). Not so fast: Scientific management started as a way to work. How did
it become a way of life? The New Yorker. Retrieved from www.newyorker.com/
magazine/2009/10/12/not-so-fast.
Longo, B. (2000). Spurious coin: A history of science, management, and technical writing.
Albany: State University of New York Press.
Lund, A. (2011). User experience management: Essential skills for leading effective UX teams.
Burlington, MA: Morgan Kaufmann Publishers.
Malone, T. W. (2004). The future of work: How the new order of business will shape your
organization, your management style, and your life. Boston, MA: Harvard Business School
Publishing.
Martins, L. L., Gilson, L. L., & Maynard, M. T. (2004). Virtual teams: What do we know
and where do we go from here? Journal of Management, 30(6), 805–835.
Mintzberg, H. (2013). Simply managing: What managers do—and can do better. San
Francisco, CA: Berrett-Koehler Publishers, Inc.
Morris, P. W. G., Pinto, J. K., & Söderlund, J. (2011). Introduction: Towards the third wave
of project management. The Oxford handbook of project management (pp. 1–11).
Oxford and New York: Oxford University Press.
Peters, T. J., & Waterman, R. H. (1982). In search of excellence: Lessons from America’s best-
run companies. New York: Harper & Row.
Pigg, S. (2014). Coordinating constant invention: Social media’s role in distributed work.
Technical Communication Quarterly, 23(2), 69–87.
Rainie, H., & Wellman, B. (2014). Networked: The new social operating system. Cambridge,
MA: MIT Press.
38 Communicating Project Management

Richards, S., & Culp, D. (2001). The peaceable kingdom: Building a company without
factionalism, fiefdoms, fear, and other staples of modern business. New York: John Wiley.
Saval, N. (2014). Cubed: A secret history of the workplace. New York: Doubleday Publishing.
Schreiber, J. (2017). Toward a critical alignment with efficiency philosophies. Technical
Communication, 64(1), 27–37.
Söderlund, J. (2011). Theoretical foundations of project management: Suggestions for a
pluralistic understanding. In P. Morris, J. Pinto, and J. Söderlund (Eds.) The Oxford
handbook of project management (pp. 37–64). New York: Oxford University Press.
Spinuzzi, C. (2003). Tracing genres through organizations: A sociocultural approach to
information design. Cambridge, MA: MIT Press.
Spinuzzi, C. (2005). The methodology of participatory design. Technical Communication,
52(2), 163–174.
Spinuzzi, C. (2015). All edge: Inside the new workplace network. Chicago, IL: University of
Chicago Press.
Stave, K. A. (2002). Using system dynamics to improve public participation in
environmental decisions. System Dynamics Review, 18(2), 139–167.
Turkle, S. (2011). Alone together: Why we expect more from technology and less from each
other. New York: Basic Books.
Wajcman, J. (2014). Pressed for time: The acceleration of life in digital capitalism. Chicago,
IL: University of Chicago Press.
Winsor, D. A. (2003). Writing power: Communication in an engineering center. Albany, NY:
University of New York Press.
Womack, J. P., Jones D. T., and Roos, D. (2007). The machine that changed the world: The
story of Lean production. New York: Free Press.
Yates, J. (1989). Control through communication: The rise of system in American
management. Baltimore: Johns Hopkins University Press.
2
RETHINKING THE PARADIGM
OF PROJECT MANAGEMENT
From Efficiency to Participative

[I]t is now generally recognized that a disciplined approach to managing projects

yields positive value in the resulting cost, schedule, and functionality. However,
there remains great conflict over exactly what discipline is to be used in this
process.
(Richardson, 2010, p. 11)

The need for participation, in essence, recognises that tensions exist between
those with some form of knowledge and power and those without.
(Kensing & Greenbaum, 2013, p. 22)

The view that development methodologies are not neutral is likely intuitive for
those of us working in technical communication. The field has long believed
technological systems are political (Selfe & Selfe, 1994; Winner, 1980) and are
generally ineffective unless designed with people (Johnson, 1998; Kaptelinin &
Nardi, 2012; Potts, 2014 Spinuzzi, 2003; Sun, 2012). So, like any system or
experience that is developed for people to use, I begin this chapter with an import-
ant claim: project management methodologies are also not a neutral system.
Project management methodologies are political and have histories that include
some and exclude others. As Law (2004) argued of research methodologies, the
communication practices of project managers “produce the reality that they
understand” (p. 5). Further, project management practices symbolically make
arguments about how people should or can participate on teams and what
effective participation looks like in a given context and situation. Project
management forwards labor conditions that are normative and delimiting.
Under efficiency paradigms, which value speed and productivity above all
else, the methodologies of project managers can commodify and constrain an
40 Communicating Project Management

organization’s most important resource: people. And since efficiency tools and
processes on their own do a poor job of highlighting the importance of people,
this chapter makes an argument for a shift toward a participative communication
paradigm for project management.
As Chapter 1 explained, an underlying issue with decentralized management
structures is that people do not enter a neutral working environment,1 and
management structures alone cannot account for social hierarchies of influence
or unhealthy communication practices. Workplace bullying (or mobbing),
sexism, ageism, and other forms of discrimination can manifest themselves in
the culture of a team, even if that team is structured to be more democratic. This
chapter also investigates the theoretical underpinnings of project management
to argue it should be understood as praxis—so that it can be responsive to such
unhealthy communication activities. To do so, I refer to scholarship in writing
and rhetoric on research methodologies offered by Sullivan and Porter (1997),
which argues that methodologies should be applied as a heuristic rather than
“treating methodology as a set of antiseptically applied rules that govern research
practices” (pp. 45–46). In making this argument, I use theory that addresses
research practices because it has a great deal of alignment and overlap with
communication approaches used for approaching development work. I begin the
chapter by further explaining the roots of project management in efficiency
models. Further, I argue that participation, done effectively, is also efficient and
productive. Explicitly, my goal for this chapter is to theoretically ground and argue
for the importance of participatory approaches to managing and communicating
the project work of development teams. A participative project management
paradigm seeks to communicate in ways that involve development teams in
assembling—and sometimes in developing—the tools, resources, processes, and
procedures that support project management praxis, and is implemented through
effective communication techniques.
This chapter is also a response to a critique that surfaces a great deal in the
scholarship of project management. As I noted in the introduction, scholars have
been critical of the lack and type of research that exists (Dicks, 2013; Morris, Pinto,
& Söderlund, 2011). Hällgren and Söderholm (2011, p. 500) summarized these
criticisms as research that focused on “best practice[s] and the development of
tools and models” and a second area that is “process oriented and is primarily
empirical, with a descriptive focus.” This chapter forwards critical attention to
the tensions produced by project management paradigms, epistemology, method-
ology, and methods as a means for suggesting a more inclusive approach through
communication practices that respect difference and value participation.

Project Management Is Rooted in an Efficiency Paradigm

When project management was initially conceived, it was largely treated as a subset
of management studies (Morris et al., 2011), and as a result, management studies
 Rethinking the Paradigm of Project Management 41

and project management share some productive theoretical overlap. One area
where overlap occurs is in the importance of management paradigms. As
described by Dicks (2004), management paradigms illustrate the principles and
philosophies that contribute to how managers view their work. A useful definition
of paradigm is provided by Heron and Reason (1997, p. 274), who explain it as
“an overarching framework that organizes our whole approach to being in the
world.” There are many different management paradigms that exist, and as a
result, seemingly a never-ending supply of books and articles that argue for new
ways of thinking about managing and leading organizations and people.2
More recently, scholars have been working to situate project management with
its own theoretical discussions (Söderlund, 2011), identifying it as a scientific
discipline that focuses on implementing processes to coordinate human behavior.
Meanwhile, one result of the overlap between management studies and project
management is that seemingly little attention has been paid to the paradigm
that project management operates under, which is especially important to its
influence as a social workplace practice. In other words, the paradigm of project
management is directly tied to its historical role in organizations, which is to
maximize worker efficiency and productivity through organizing, coordinating,
and aligning teams.
Just like technical and professional communication, project management
began to professionalize in the 1950s. During this time, efficiency models of
managing work began to move from production plants to office environments.
It is important to note that project management as we understand it today
largely grew out of scientific management, which is a factory model of organizing
and coordinating teams. In scientific management, managers used analytical
methods to coordinate employees. These analytical frames would suggest how
long a task should take or create benchmarks for productivity. Yet, as Chapter
1 explained, the workplace has transformed quite significantly in the last half a
century, especially since organizations gained widespread access to the internet
and information communication technologies. Even while the workplace
conditions that project management operates in have changed quite a bit since
its professional inception, an efficiency paradigm for designing project
management as a system unfortunately remains in place.

Efficiency in Communicating Project Management

There are fundamental practices meant to enhance the efficiency of managing
projects through communication strategies. In this section, I illustrate a portion
of the processes to clarify how project management processes are designed for
efficiency and productivity using contemporary practices. What follows are
broad strokes and hardly exhaustive, but help to illustrate how efficiency is still
very much the worldview of project management processes. A good example to
begin with is a communication plan. Communication plans are a form of project
42 Communicating Project Management

planning. They are used to clarify how and when teams will interact, including
the frequency of meetings and what technologies will be used to support
communication. The goal for a communication plan is to provide interaction
touchpoints across a project lifecycle. It supports productivity by providing an
efficient overview of communication that people on teams can use to plan their
work and reporting on their work.
No doubt, a main concern of project management as a practice is planning
and coordinating information across projects and teams. Sometimes this
coordination of information is meant to communicate dependencies, such as
when one deliverable of a project directly impacts when work on another
deliverable can begin. Planning processes often rely on documentation that is
essential for efficient task management (see Geisler, 2003). These documents are
made-up tools, such as to-do lists and charters, and exist to clarify the goals of
a project so people stay focused on the goal. In fact, many of the documents
developed for project management—from Gantt charts to visual roadmaps—were
developed to help coordinate information in ways that maximize productivity.
In Yates’s (1989) work, we see a direct relationship between the tools people use
(i.e., typewriters, telephones, etc.) with the level of efficiency they offer for a given
task or activity. Networked computing technologies may be the most efficient of
all, affording development teams the ability to shrink space and time with just
a few clicks. On teams that develop products, services, and experiences, these tools
help distribute labor and cognition across a team.
To plan effectively and expediently, formalized project lifecycles were
developed to neatly communicate the breadth or scope of a project. Formalizing
the project lifecycle is also essential to the efficiency paradigm because it creates
a prescriptive process to follow. As outlined by The Project Management Body of
Knowledge (PMBOK), the project lifecycle is made up of four stages that clearly
relate to Fayol’s management concepts. The sequential stages are “Starting the
project,” “Organizing and preparing,” “Carrying out the work,” and “Closing
the project” (Project Management Institute, 2013, p. 39). Throughout these
stages, various documents are created in support of the project, and while the
documentation is often unique to the organization, there are recommendations
for a series of best practices offered by the PMBOK (e.g., project charters, project
management plans, communication plans, etc.). Additional representations are
provided in work by other professionals, such as Berkun’s (2008) simplified project
cycle that begins with planning, and continues with strategies for leading teams
through the middle and end of a project. Hackos (2007) offers a similar model
but in the context of information development called “The Information-
Development Life Cycle” (p. 318). The stages are made up of planning, design,
development, production, and evaluation, and each has an approximate
percentage of effort it takes to complete each activity. These examples of different
project lifecycles demonstrate the importance of managing projects with an
efficiency paradigm. That is, by emphasizing stages of a project lifecycle, the goal
 Rethinking the Paradigm of Project Management 43

is to communicate clear processes, to assign effort and resources, and to improve

chances that work will be completed quickly.
Another example is the end of a development project, which is sometimes called
a retrospective or closing out the project. The goal during this project phase is
to measure the success of the team’s internal processes and procedures to improve
them for the future as a way to make them more productive and efficient. While
success can be measured in many ways, and these measurements can be
standardized (e.g., Six Sigma has the DMAIC process), the general idea is for a
team to self-evaluate internal processes and procedures. In Goldratt and Cox’s
(2014) The Goal, we see the main characters frequently sit together to discuss
ways to improve the plant’s workflow to make operations more efficient,
similarly to what Lean calls “Kaizen” (i.e., targeted process improvement). Many
development teams practice process improvement in other ways, such as
evaluating internal processes throughout a project to improve efficiency as they
work. For example, Berkun (2008, p. 199) recommended collaborating in small
groups to create ideas and then test them as a team throughout the project.
Software development teams have similar approaches, such as refactoring
computer code (although sometimes refactoring is automated by computing
technology). Needless to say, many of these practices are meant to create
opportunities for teams to communicate about how to improve their productivity
and efficiency.
Interestingly, many of the tools and processes project management relies on
for efficiency also require effective participation. For example, a project manager
or a team can develop a communication plan, but if no one follows the plan, it
fails. The same goes for coordinating work and deadlines. If people on the team
do not comply, then work falls behind. If the project lifecycle is dismissed or
ignored, then the scope of a project can quickly grow out of control. Certainly
if a retrospective session is treated as a procedural hurdle, then processes do not
actually improve and teams will not grow more productive. In short, project
management processes and tools rely on—if not assume—participation to be
successful. Without cultivating participation, the processes are more or less
emptied of substance and execution.

Criticisms of Efficiency
Efficiency as a value for working has been criticized for eliminating a focus on
the human factors of work in favor of a mechanization and standardization of
work processes and procedures. Many of these criticisms are covered quite
well in technical communication scholarship. For example, Killingsworth
and Jones (1989) explain how Max Weber, Frederick Taylor, and Henri Fayol
are largely responsible for how managerial control was practiced begin-
ning in the early 1900s. They further explain that it was Elton Mayo who
introduced a less bureaucratic approach that emphasized integrated teams and
44 Communicating Project Management

was “a dialectical challenge to what was by then the well-established division of

labor model” (Killingsworth & Jones, 1989, p. 211). Technical communication
scholars have pointed to efficiency models as overtly controlling through the use
of texts (Swarts, 2008) and communication (Yates, 1989; Longo, 2000).
Furthermore, a common criticism of efficiency models is that it deskills labor by
automating tasks and making them repetitive (Kensing & Greenbaum, 2013;
Smith, 2000). Indeed, what is furthermore problematic about efficiency models
for managing projects is many development teams are asked to use participatory
methods for their work.
Critiques of efficiency models are not limited to technical communication.
In fact, efficiency models have been critiqued for the commodification of labor
since the rise of mass production in the 1900s. As Saval (2014, p. 61) explained,
“Taylorism, whether applied in its most ruthless form or not, ensured constant
supervision.” Principles espoused by efficiency models were partially the
motivation behind the argument forwarded by the Manifesto for Agile Software
Development, which was largely written in reaction to what a group of develop-
ers felt was an overwhelming and ever-growing corporate bureaucracy that too
often got in the way of working alongside customers and building useful products.
Yet, even if the motivation for the manifesto was to create more room for parti-
cipation, the document also made these arguments through the lens of improving
productivity and efficiency: “working software over comprehensive documenta-
tion” and “responding to change over following a plan” (Beck et al., 2001). The
goal was for teams to move quickly without being micromanaged by the tedium
of stabilized processes and procedures, but to do so by involving customers and
being accountable to each other.
It is more difficult to locate, however, the criticisms of how efficiency influ-
ences various models of project management. Most criticism happens by proxy
of some other issue. For instance, there is a great deal of debate over what counts
as Agile (for an interesting account, see Apke, 2015). Some of the criticism that
grows from these conversations follow logic like “Agile is X, not Y,” and many
of my research participants were well-aware of these “purist” arguments that
relied on relatively absolutist views of practice. As this chapter will explain a
bit later, adapting methodologies, like Agile, does not dilute it as praxis. Rather,
it strengthens its influence as a theory for organizing teams and work, particularly
if it is revised for a certain context to enhance a participatory approach to com-
municating.

Tensions Between Communicating Efficiency and Participation

There is clearly a tension that surfaces in project management between maxi-
mizing productivity while enlisting the participation of people on the team. To
further illustrate this tension, let me point to a vignette offered by one of the
 Rethinking the Paradigm of Project Management 45

participants interviewed for Chapter 3, as his story is instructive about the

tensions that surface between efficiency and participation. As the story was told
to me, he worked on a distributed team in a user experience role and would
participate in a Scrum that was facilitated by a group phone call. The Scrum was
with people dispersed across other office locations. As a result, only some people
were in the same room with each other. He noted that participation in these
Scrums varied, and he felt face-to-face Scrums, or being in the same room
together, produced better results. He explained the lack of participation in this
way:

In a room, if you’re going to have a sidebar communication, it’s real easy

for the facilitator to see them and go, “Excuse me guys, we are going to
have one meeting here.” But you don’t see the IMing going on in a
distributed meeting, you don’t see the three people in one room just put
their phone on mute and they are going, ‘What the heck is he talking about?’
So there is a lot of the hidden channels that are hard to moderate.

What is interesting about this example is people are participating, but not in
the prescriptive method offered by the structure of Scrum. Instead, people on
the team exercised agency and participated according to their individual needs.
In this example, the communication practices and the tools do not seem to align
with the actual goal: participation, facilitated through interactive activities of
problem-solving and coordinating work. It is the participation that leads to
productivity, not the other way around. That is, the outcome of effective
participation is productivity. Furthermore, it is through the effective participation
of people that methods are adapted to practice. Adapting methods and method-
ologies is about making space for teams to not just change practices, but to respond
to the unique needs of a given context and problem to be solved. Applied as a
template, methods like Scrum can actually marginalize an individual’s ability to
participate in important conversations about work.
Additionally, Agile itself presents an intriguing tension because it argues for
more team participation by operating under an efficiency paradigm. For example,
Ratcliffe and McNeill (2011, p. 9) describe Agile in this way: “The aim of Agile
is to get to code as quickly as possible.” Here the emphasis is on efficiency. The
authors explain that Agile makes use of cross-functional teams because they are
more efficient (p. 70). Yet, the authors also argue, “Software is a social exercise.
It should be about people and how they communicate, cooperate, and interact
as a team to deliver value to the organisation” (p. 25). Such contradictions
demonstrate the paradigmatic tension that development methodologies pre-
sent to communicating project management. Agile, in theory, operates under a
participative paradigm, but in implementation it is often preoccupied with
efficiency.
46 Communicating Project Management

Meanwhile, numerous books have been published on development method-

ologies that explain prescriptively what they are and how they can be implemented
into a given workplace (e.g., George, 2005; Rasmusson, 2010; Sims and Johnson,
2012). These books, while seemingly useful, appear to exclusively avoid discussion
of paradigm. In some ways, these books forward implicit arguments that specific
project management or development methodologies and methods can save
teams from bad habits or lack of know-how, which is not far from the trope that
hero-designers can save users from themselves (see Spinuzzi, 2003). Too often
assumptions are made that if innovation does not occur, it is because of the
people, not the methodology. This assumption overlooks the important role of
paradigms in producing project outcomes. As Peter Merholz (2015) explained
at the IA (Information Architecture) Summit, “Be wary of people espousing
methodologies. Typically, they are crutches to free people from critical thinking.”
In other words, development methodologies do not alone make teams impervious
to inefficiency and poor-quality work, but a lack of space for communicating
and participating can.

Participation Leads to Efficiency

Today’s teams are heavily involved in planning, organizing, and evaluating the
success of project work. People work together to identify problems with processes
and develop solutions that help improve project outcomes. And even when there
is a central person designated in title as a project manager, this person does not
work in isolation. Consider Agile’s process of estimating a schedule (e.g., planning
sprints), which is done in a meeting by teams through a dialogue of stories about
time, resources, and commitments (Cohn, 2005). In fact, games have been
created for teams to engage in estimating exercises together to get people involved
and to give feedback to each other. Planning is achieved through participation,
but is used to organize for productivity. In the context of project management,
the relationship between efficiency and participation is symbiotic. In other words,
one does not persist without the other.
Since today’s organizations do not act as a kind of container that holds
communication (Doerfel & Gibbs, 2014), but as a network that facilitates it (Rainie
& Wellman, 2014; Spinuzzi, 2015), making space for participation is essential to
cultivating efficiency. Much of today’s development work is project-based, so
communication that supports the management of projects often does so through
people working together on simple tasks, like choosing information communica-
tion technologies to use for a project. Communication in these circumstances is
made up of social coordination that extends across a range of activities that can
also improve project efficiency. As Pigg (2014, pp. 84–85) explained, “The social
coordination that has become a crucial layer of what symbolic analysts do is itself
a form of literate activity. It is also intricate, complex, time consuming, and often
tacit rather than explicit.” When teams assemble around projects, they socially
 Rethinking the Paradigm of Project Management 47

coordinate in relational ways, working to find useful methods of supporting com-

munication that suits the needs of the moment and involves the audience.

A Paradigm in Transition
One important issue mentioned repeatedly in project management scholarship
is that the focus on tools and processes to enhance efficiency and productivity
have produced relatively little understanding about broader, theoretical issues
about how project managers can or should communicate. Simply put, teams are
given tools and processes, and they use them. Heron and Reason (1997) help to
explain an outcome of this approach in terms of paradigmatic thinking: “A basic
problem of positivist mind is that it cannot acknowledge the framing paradigm
it has created” (p. 275). By focusing so intently on practice, on adopting out-of-
the-box tools and processes, the development of a participative paradigm is
potentially less visible to those managing projects. Further, any epistemological
discussion seems impractical because it does not contribute in material ways
to the outcome of efficiency and productivity. In this way, the continuous
development of project management methodologies, methods, and tools appear
to repeat on an endless loop of situational practice without theoretical input.
The result is teams or project managers—not understanding the broader para-
digm their practices contribute to—working to improve practices without
understanding the broader communication activities also guiding or derailing
these processes and tools.
In technical communication scholarship, there is clear evidence that suggests
project management’s paradigm is in a state of transformation. For example,
consider Amidon and Blythe’s (2008) work with communication managers.
Managers report a constantly shifting workplace environment with more use of
information communication technologies to coordinate work. The changes
could “lead to flattened bureaucracies,” but they “heard of changes in both
directions” (p. 14), echoing what Goldratt and Cox (2014) intimidated about
trends in organizational design as a kind of merry-go-round. As well, in Spinuzzi’s
(2015) work, we learn how organizational networks, supported by information
communication technologies, are essential for supporting temporary teams that
assemble around solving problems. These temporary teams operate in a flat hier-
archy and share in project management activities, which requires participation.
In these shifts, efficiency and productivity are outcomes of effective participation.
Given the changes in the workplace and in development approaches, the focal
point of project management communication needs to be learning how to best
involve people in project management and development activities. If effective
participation breeds better outcomes and improved productivity, then project
management communication depends on making space for people to partici-
pate—to maximize opportunities for engagement and interaction.
48 Communicating Project Management

Participation and Project Management as Methodology

Up until this point, I have referred to approaches like Agile and Lean as parti-
cipatory methodologies operating under an efficiency paradigm. In this section,
I want to clarify some of this terminology and explain these concepts in more
detail, particularly how I see them informing project management communi-
cation as praxis.
Research methodologies are philosophies that guide or unite methods. They
are generally understood to align with a particular epistemology, ontology,
and paradigm. Epistemology is essentially how we come to learn or know
something, whereas ontology asks what can be known. And, as we’ve discussed
earlier, paradigm can be understood as an overarching worldview. Why does
this matter? Because, as these concepts are traditionally understood, they func-
tion like a row of dominos set up across a spectrum of the theory into practice.
However, I see these terms as less hierarchically connected, which is important
for illustrating how project management has evolved from an efficiency paradigm
to a participative one. As Fleckenstein, Spinuzzi, Rickly, and Papper (2008)
explain:

Rather than conceiving of the components of the research process (para-

digm, methodology, methods, techniques, and strategies) as isolated
from one another, scholars guided by ecological thinking conceive of
them as symbiotic clusters: knots of nonhierarchical, locally enacted
semiotic-material practices that inform each other in multiple ways.
From perspective, then, a paradigm is not an overarching category. Rather,
it is a symbiotic cluster, an ecology of reinforcing activities, artifacts, and
language.
(Fleckenstein et al., 2008, p. 394, emphasis in original)

In this model, the goal is to create metaphorical harmony across these

considerations, rather than through hierarchical reasoning. That means as
methods and methodologies evolve, so can a paradigm because “a paradigm
emerges out of its linkages” (Fleckenstein et al., 2008, p. 395). That is, the tension
emerging between communicating efficiency and participation is healthy—if it
receives attention. Today’s project management methodologies, which have very
clear ties to scientific management, have shifted due to factors that influence the
ways we approach development work. I’ve pointed out a number of these factors,
including the broad decentralization of organizations, teams, and communica-
tion, and the development of methodologies for designing experiences for people.
It is arguable the paradigm of project management began to transform with
changes in work practices, technologies, and global contexts as well.
Questions about the relationships between method, methodology, epistem-
ology, and so on are useful—even essential—for project managers because they
 Rethinking the Paradigm of Project Management 49

introduce a critical mindset into issues of alignment or linkages across philosophy

and accompanying communication methods. In other words, they force project
managers to ask questions about themselves as writers. For instance, a project
manager might ask questions such as: how do they know methods like Scrum
work? How can they know if they work for everyone on the team? Does it link
to a philosophy for working? How can teams measure the success of a Scrum?
Define it? By measuring efficiency or by measuring participation? Or even, can
participation be measured? In the context of management studies, similar
questions are posed by Goldratt and Cox’s (2014) The Goal. The main character,
Roggo, changed work processes in his plant to address a process bottleneck. The
changes improved the efficiency of the plant and it started making money again.
However, because how the organization measured success hadn’t changed to
accommodate the new processes, it looked on paper as if the plant wasn’t actually
making money. Throughout the book, Roggo realized that how success is defined
has to transform to account for changes in workflow and process.
To help understand Roggo’s plight of changing how his company measures
success, I refer to how John Law (2004) discussed mess in social science research.
Much about how he described research methodology also applies to the work of
writing processes with development teams. He wrote, “No doubt some things
in the world can indeed be made clear and definite” (p. 2), but countered this
statement with “the world is also textured in quite different ways” (p. 2). He
continued to explain that some approaches are useful, but cannot account for
complexity, and posed an important question: “So what are the textures they are
missing out on?” (p. 2). I am making a similar observation about the role of
communication in project management methodologies. In other words, because
project management methodologies will no doubt continue to evolve, what are
they missing out on? How are they not accounting for changes in the ways we
work?
At this point, I hope it is clear that one answer I offer to this question is that
the tension between efficiency and participation is not being recognized, but must
be. Working conditions require participation, but project management organizes,
above all, for efficiency. Law’s (2004) work sheds additional light on how adopting
specific methodologies as a template can be to the detriment of other ways of
knowing, or in the case of project management, working. By working under an
efficiency paradigm, similar to adopting a research method, people and teams
are placed “in a set of constraining normative blinkers. We are being told how
we must see and what we must do when we investigate” (Law, 2004, pp. 4–5).
In the context of communicating project management, the paradigm we work
under—as well as the methodologies and methods we adopt—influences how
we participate individually and collectively in project work and project and
business goals and outcomes. Project management methodologies can control
both how teams communicate and what they develop.
50 Communicating Project Management

As a discipline, and because of its focus on processes and tools, project

management does not often critically evaluate how methodologies influ-
ence participation in practice. Rather, published work expends a great deal of
energy adopting specific methodologies and, as a result, companies are hiring
people to help implement them. Industry has seen an uptick in consulting jobs
such as Agile Coaches or Scrum Masters to help struggling development teams
adopt new methodologies. The role of an Agile Coach is to implement Agile, often
without critically evaluating if the model will be useful for the team or if the
methodology needs to be adapted to fit a specific project (or not at all). For
instance, consider this description of Agile Coaching by Rachel Davies and Liz
Sedley:

Your goal is to grow a productive Agile team that thinks for itself rather
than relying on you to lay down the Agile law. Showing people how to be
Agile isn’t enough: they need to change how they work and how they think
in order for Agile to stick. They often need to unlearn old habits before
they can work effectively as members of an Agile team.
(Davies & Sedley, 2009, p. 3)

To be clear, I am not necessarily interested in criticizing Agile as a way of

approaching work; rather, I am criticizing the adoption of methodologies like
Agile as if they are neutral and arrive ready for implementation. Agile is not a
template to overlay on people, nor should a methodology be used as an isolated
agent for social and cultural change on teams.
It is also important to temper the sort of participation that I’m describing here.
I do not mean to argue participation is a cure-all for all project management’s
communication failures. Participatory forms of management (see Lawler, 1986)
certainly has had its detractors (e.g., Barker, 1993; Mintzberg, 2013), and for good
reasons. For example, Drucker (2009) explained the protective qualities of
organizational hierarchy where he believes participative management is not
useful:

One hears a great deal today about “the end of hierarchy.” This is blatant
nonsense. In any institution there has to be a final authority, that is, a
“boss”—someone who can make the final decisions and who can expect
them to be obeyed. In a situation of common peril—and every institution
is likely to encounter it sooner or later—survival of all depends on clear
command. If the ship goes down, the captain does not call a meeting, the
captain gives an order. And if the ship is to be saved, everyone must obey
the order, must know exactly where to go and what to do, and do it without
“participation” or argument.
(Drucker, 2009, p. 73)
 Rethinking the Paradigm of Project Management 51

Even so, Drucker later acknowledged that “Other situations in the same insti-
tution require deliberation. Others still require teamwork—and so on” (p. 74).
I believe, just based on the widespread influence of decentralization alone, project
management qualifies as a situation that directly benefits from more participatory
communication. Yet, too often the frequency and nature of participation is pre-
determined by a methodology that may or may not be appropriate for a project,
a team, or an organization. Methodologies are not templates. Used as one, they
have the ability to produce behaviors that predetermine what qualifies as desir-
able, such as personality traits like extroversion or competitiveness. For people
on development teams with different ways of participating, the communication
prescribed by methodologies can provide very little space. In such cases, space
has to be made for people to participate, which means adapting the methodology
to enhance, not disrupt participation.

Participation Informed by Participatory Design

Participation as a concept has roots in Participatory Design, which is a method
for involving people in workspace and technology design, and skill and
professional development. Participatory Design grew out of the Scandinavian
Design movement in the 1970s, which aimed to create a more egalitarian
workplace. Kensing and Greenbaum (2013) explained that the trade unions and
collective bargaining were quite strong in Scandinavia at that time, which helped
pave the way for interest in and support for a more democratic work experience.
As Participatory Design matured, it continued to make power relations between
workers and organizations its object of focus, expanding into the development
of technologies to support work. In this context, Spinuzzi (2005) explained that
Participatory Design is particularly interested in learning tacit knowledge, which
is “implicit rather than explicit, holistic rather than bounded and systematized;
it is what people know without being able to articulate” (p. 165). Communicating
tacit knowledge may not expedient in the short term, but that investment may
help with alignment issues later on. In other words, the time investment for
learning tacit knowledge up-front in a project may be costly in terms of time,
but become productive across a project’s lifecycle.
An important tool of participatory design is mutual-learning, which positions
a designer and a user into co-designing roles for a technological system. Mutual
learning is essential to involving people in the design of a system they will use
to support work. In the beginning of this chapter, I suggested that project
management systems are not neutral. A participatory approach, as described by
mutual-learning, is one way I believe a participative paradigm for project
management can operate. Project leaders and managers must be willing to learn
from teams, and let others take the lead when it makes sense for the project.
52 Communicating Project Management

Participation Informed by Feminist Theory

Feminist theory also offers theoretical importance a participative paradigm for
project management. Interestingly (or maybe not so much), it can be surmised
that many of the efficiency models discussed so far were largely developed by
men. Popular methodologies like Agile and Lean have largely been credited
to men. The original “Agile Manifesto,” for example, was signed by all men, even
though it was later endorsed by some women. Lean manufacturing, while initially
developed in Toyota’s Japanese factories, was first described in an article by a
man, John Krafcik (1988) who, in that same article, championed the efficiency
strategies forwarded by Fordism, also developed by a man. Six Sigma was initially
developed by a man, Bill Smith at Motorola. It is difficult to know whether the
early conceptualization of these models contained the input of LGBTQ people,
women or people of color, but it seems clear that these conversations were
largely dominated by men. This lack of diversity, no doubt, demonstrates how
many prevailing methodologies rely, much to their detriment, on specific views
of experiencing project work.
A paradigmatic transition from efficiency to participation also aligns with
feminist critique of project management methodologies because I am arguing
for more inclusive approaches to managing and communicating development
work. In making space for people, I am also arguing that project management
needs to address the silencing that methodologies and teams socially construct.
Erin Frost (2016, p. 16) makes a similar argument about efficiency models as
they relate to ethics, explaining that “when we invoke the term efficiency, we
must also make apparent the contextual implications for ethics.” Ethics, Frost
continues, cannot be separated from discussions of efficiency because it disrupts
the development of a more egalitarian workplace. To support her ideas, Frost
argues that including diverse voices that represent a range of workplace experi-
ences into an efficiency model’s framework actually makes them more efficient
and more ethical (p. 17). Furthermore, technical communicators must be careful
because:

Efficiency can easily become so embedded as a cultural value that it is no

longer explicitly discussed—the shifting balance of energy expended versus
goodness done is not articulated—and it is then a small step to using
efficiency to justify racism, sexism, ableism, and other evils.
(Frost, 2016, p. 17)

No doubt, we must balance the need for efficiency with an ethics of partici-
pation. Furthermore, I agree with Frost that inclusivity will ultimately help to
develop a participatory team environment that is even more efficient while also
being more inclusive.
 Rethinking the Paradigm of Project Management 53

Feminist scholars have been making arguments about participation and

collaboration in the workplace for quite some time. Much of this work argues
in a similar vein as I have about project management. For instance, Lay (1991,
p. 364) argued, “Feminist theorists can help technical communicators provide
new models of effective collaboration—models that help collaborators break out
of gender roles.” While I am careful to delineate participation from collaboration,
they are also no doubt related activities (that is, one must participate in a colla-
boration). As well, others have examined the roles of gender at the executive
management level (Wajcman, 1998) and the role of space and place in the social
construction of gender (Massey, 1994). It is realistic that many collaboration
models are easily comparable, or maybe even synonymous, with what I’ve
interchangeably termed project management methodologies. Many of these
approaches have as much to do with how people collaborate as they do with how
people scope and budget a project (both in time and money).
A movement towards a participative paradigm suggests, among other trans-
formations, a model of communicative inclusivity that seeks to include a more
diverse approach to collaborating and thinking together. As Frost and Lay both
argue, including diverse experiences and knowledge can both improve efficiency
models and make them more effective. Participative frameworks are compatible
with feminist critique of team dynamics and efficiency methodologies. The
uncritical adoption and application of project management methodologies
creates power imbalances that can stunt the kind of creative diversity (Phillips,
2014) and team psychological safety (Edmondson, 1999) that facilitates inno-
vation on development teams. In fact,

Unless we find, identify, and try to understand other ways of organizing

and control, we are in danger of perpetuating organizations and organizing
systems that will sustain and exacerbate the power imbalances and systems
of exploitation that have already created their own logic, epistemology, and
justification.
(Mir, Mir, and Upadhyaya, 2003, p. 53)

Project management methodologies impose their own communicative logic—

a logic that is not necessarily co-created by the very development teams that are
asked to implement these new ways of working.

Project Management Methodologies as a Heuristic

To further address how we can understand participation, let’s turn attention back
to how we adapt methodologies to teams. To address a lack of reflexivity of praxis
in research, Sullivan and Porter (1997, p. 64) argue for a “continuous critical
perspective” that positions methodology as a heuristic that must be applied and
54 Communicating Project Management

argued for in a given situation of inquiry. As Sullivan and Porter (1997, p. 65)
explain, “we can argue to the community that one or more particular frame-
work(s), justifiably reshaped by this situation, provide helpful filters/guides.”
In practice, project management methodologies, or specific communicative ele-
ments of these approaches, can prove useful to certain situations and less so to
others. Such an approach would enhance the participatory element of communi-
cation on project work without sacrificing efficiency. In this approach, project
management methodologies are more of a heuristic than a template. Using a
heuristic model, teams can evaluate methodologies by communicating about
them, and then critically adapting them to their work rather than implementing
them as a single identifiable process that must be followed. What counts as
participation in these instances? In the context of Participatory Action Research,
Alice McIntyre (2008) suggests that participation must be defined within and by
a community. This adaption can be made part of regular project management
practice. For example, posing the question: what are the expected levels of parti-
cipation throughout the project’s lifecycle for people on the team? And how will
the team define those expectations?
Another way to transition toward a heuristic approach to applying method-
ology is to focus on the circulation of ideas across the team. Lucy Suchman (2004)
explains that managers must move from being the “origin of change, or of new
things, to an understanding of the manager/designer as involved in the circulation
of ideas and objects” (p. 170, emphasis in original). Furthermore, Royster and
Kirsch (2012) argue that since information and knowledge are not static, we must
“pay attention to the way that ideas travel in order for us to become more
consciously aware of patterns of intellectual and social engagement” (p. 138).
These conceptualizations nicely connect to Simmons and Grabill’s (2007) view
of creating multiple entry points for inquiry and citizen action. An essential goal
in a participative paradigm must be to pay attention to how and when people
are involved in project work, specifically focusing on how the methodologies being
used might unintentionally undercut their contribution, because organizations
produce people (Collinson, 2003).
The mechanisms for a heuristic approach to communicating project manage-
ment methodologies are already in place for most teams. Planning sessions, check-
ins, Scrums, sprint retrospectives, Kaizen, process improvement efforts, and so
on are all instances where the system can be collectively examined and changed.
These spaces can directly elicit the “continuous critical framing” that Sullivan
and Porter (1997) advocate for in their work. Critically evaluating the project
management system is essential to its health. That evaluation work is done by
communicating about the current system, where it fails people, and the ways in
which it supports people. In contrast, Chapter 5 will discuss a more prescriptive
approach where the system is treated more like a template for working. The team
is given new tools and processes and asked to change their workflow, but they
 Rethinking the Paradigm of Project Management 55

largely resist and become suspicious of management’s motives. Thus, individuals

on the team found ways to maneuver through and around the system by
interacting in hidden channels of communication to remain flexible and make
space for working in ways that feel comfortable.
The resulting flexibility of methodology and methods might seem careless or
overly expectant of teams, teamwork, and collaboration. Or, as Sullivan and Porter
(1997, p. 69) explain, it might come across as “sloppy or imprecise work.” In my
view, participation cannot be a prescriptive process either, or it erodes the
argument I’ve made so far in this chapter. Rather, I see participation as defined
by a community, as a kind of rhetorical agency that can be exercised through
communication activities. In Participatory Action Research, teams develop their
own norms and expectations, terms for discussing ideas, and approaches to solving
problems. McIntyre highlights for general tenets that offer insight into how
participation is deployed.

• a collective commitment to investigate an issue or problem.

• a desire to engage in self and collective reflection to gain clarity about
the issue under investigation.
• a joint decision to engage in individual and/or collective action that leads
to a useful solution that benefits the people involved, and
• the building of alliances between researchers and participants in the
planning, implementation, and dissemination of the research process.
(McIntyre, 2008, p. 1)

The ideas forwarded are a good starting point for emphasizing participation
on teams, and are in alignment with several other practices already used by
industry. For example, the workgroups approach described by Berkun (2008)
that emphasize incremental improvement to process throughout a project, or
the more targeted DMAIC process improvement principles outlined by Six
Sigma (George, 2005). The benefit of thinking about McIntyre’s approach is
that it foregrounds participation over efficiency by making space—even if people
choose not to use the space in ways we expect. As Chapter 3 will show us,
communicating in ways that make space for participation occurs in a range of
ways.

Effective Communication Is Participatory

Participatory communication can be understood as what Johnson (1998) refers
to as “the audience involved” (p. 363, emphasis in original). For Johnson, involve-
ment means active engagement with people, as opposed to a more passive role
of an overly generalized or generic audience. In a participatory communica-
tion framework, “the involved audience is an actual participant in the writing
56 Communicating Project Management

process who creates knowledge and determines much of the content of the
discourse” (p. 363). Johnson’s conception of involvement is closer to McIntyre’s
(2008, p. 15) idea that true participation in projects is reliant upon a sense of
ownership over the work. It is through communication that participation in
project management gets done.
Examples of participation exist in participatory design (Spinuzzi, 2005), Parti-
cipatory Action Research (McIntyre, 2008), participatory healthcare (Oldenburg,
2016), participatory government (Stave, 2002), environmental policy (Simmons,
2007), disaster response (Potts, 2014), civic participation (Simmons & Grabill,
2007), and so on. Simmons and Grabill (2007), in particular, provide a useful
discussion of participation in democratic spaces, which I find comparable to the
situation presented by decentralized organizations and teams. Simmons and
Grabill (2007) suggested that citizens, to participate, need to have a rhetoric of
invention and an element of performance to participate. They say, “We believe
the design of civic information must allow for multiple entry points, multiple
types of questions, and multiple angles of investigation to allow citizens to invent
usable knowledge from the available information” (Simmons & Grabill, 2007,
p. 434). The same can be said about project management information under a
participatory paradigm. Project management systems are designed and should
allow for similar points of entry as a means for participating and exercising agency
into the system.
In this book, the central concern of a participative paradigm is effective
communication. A rhetoric for participation on development teams must be
co-constructed, sometimes serendipitously, and as Spinuzzi (2015) explained,
this work often happens during moments of collaboration. The communication
that supports the co-construction of project management on these teams has three
overlapping characteristics that depend on constant reflection:

• It is generally reactive, but intentional.

• It focuses on future action.
• It is systems-based.

While these characteristics are certainly not rules for communicating, they are
useful as theoretical guideposts for understanding how the cases in this book
describe communication. Below I explain each of these characteristics in more
detail.

Reactive
By reactive, I mean that project managers tend to read and respond to com-
munication problems when they surface. Also, because every project is unique,
the different kinds of rhetorical situations that surface are hard to predict.
Spinuzzi (2015) describes all-edge teams sharing in project management activities
 Rethinking the Paradigm of Project Management 57

as reactive, responding in the moment through “constant mutual adjustment”

(Chapter 10, Section 4, para. 2). Communication strategies rely a great deal
on listening and responding. For instance, during ideation, the team may use a
“Yes, and . . .”3 approach to participating with each other, co-constructing
project outcomes through dialogue. We will see examples of the strategies project
managers used to communicate in Chapter 3. At the same time, the reactivity
may be less productive or well-meaning. We will also see examples of less
productive reactions in Chapter 5 that demonstrate how space for participation
can be constrained.
Dicks (2004) advocated for a rhetorical approach to management communica-
tion. Specifically, he believed that “it is important to note that leaders adapt their
communication modes to particular people and situations” (p. 27). He later
walked readers through a variety of rhetorical situations that were likely to
surface as people manage, pointing out that context of communication has an
important influence on what is understood. While Spinuzzi’s (2015) work
demonstrated through case studies the reactivity of temporary project teams,
Dicks (2004) argued this communication as inherently rhetorical. He argued that
managers “must decide for each communication what [their] message is, who
[their] audience is, and what [their] purpose is, and which communication
methods will most effectively communicate that message for that purpose to that
audience” (p. 154). For Dicks, rhetoric is a practice of communicating and inter-
acting in participatory ways where people react to each other and the actors in
their environment with intentionality. Dicks’s view aligns well with the action
of making space.
The work of development teams is growing more cross-functional and
nonlinear, and as a result, project managers have to expect periods of confusion
and frustration, particularly when people are learning new methods of work-
ing together. Mintzberg (2013) argued “engagement is what managers do with
people,” and contrasted that with empowerment, which “is what managers do
to people” (p. 48, emphasis in original). The subtle conceptual variation is
important because a participatory philosophy to communicating project work
is based on regular and active engagement. That is, the goal of engaging with
people is to facilitate communicative action—to rapidly react to problems and
help teams gain forward progress when/if they are stuck. Mintzberg explained
the communication associated with leading people as a form of energizing
filtered through activities like persuading, supporting, convincing, and encour-
aging (p. 48). Once again, we will see examples of these communication strategies
in Chapter 3.
Often, collaborative moments of communication demonstrate a need for a
qualified individual to take the lead on a certain part of a project, and usually
the most qualified person takes on that role to make sure the work gets done.
Spinuzzi (2015) explains that “members of all-edge adhocracies need basic
project management skills (Chapter 10, Section 4, para. 2). To build this sort of
58 Communicating Project Management

trust, many of these teams do not have time for incremental negotiation of buy-
in or agreement. Instead, participatory communication is relational, supported
by an organization’s network. As Paretti and McNair (2008) determine of
distributed project teams:

Successful information exchange among team members requires collabo-

rators to establish a social network marked by features such as trust,
attention, and shared orientation that makes it possible for them to com-
municate successfully with each other about the work at hand
(Paretti & McNair, 2008, p. 27)

These shared orientations are often supported by the very processes and
procedures used to build trust and co-manage projects. In some organizations,
those processes are supported by technology such as instant messaging. In others,
that work is done face-to-face, typically in meetings. Technologies, tools, and
resources are often used to make space for the right kind of communication
to occur at the opportune moment so that teams can participate in project
management.

Future Action
By future action,4 a term I borrow from Pigg (2014), I mean that project man-
agers are thinking about how communicative actions might influence future
events. This way teams can anticipate roadblocks and build trust and goodwill
with fellow teammates. A participant in Chapter 4 discussed this communication
strategy as “putting money into a trust account.” Since some project teams are
temporary, people often work as intrapreneurs, and must treat communicating
in team situations as preparing and inventing future work opportunities. When
working on teams that assemble temporarily around a project, people recog-
nize that they will eventually work with these same people again, even if in a
different configuration. The ways in which goodwill is constructed with temporary
teammates has an influence over how future work and work opportunities may
unfold.
For Pigg (2014), future action also means that people recognize their current
work is setting the stage for potential work down the line. As people work to
develop career trajectories, they recognize that with each opportunity another
potential future project awaits. Future action is, in many ways, an entrepreneurial
mindset (see Lauren and Pigg, 2016). But, as Rainie and Wellman (2014) describe
the networked individual as autonomous and distributed across a number of
personal and professional networks, future action must occur in multiplicity. That
is, people must always understand that actions today have the potential to
influence and create the work relationships of tomorrow.
 Rethinking the Paradigm of Project Management 59

As a result of future action, workers must balance participating across multiple

networks and teams. As Rainie and Wellman (2014) explained, information com-
munication technologies allow for teams to disperse and connect with relative
ease, being everywhere all at once. There are implicit rules for working in this
way. For example, in Chapter 3 we will learn about how the time it takes to
respond to someone’s instant message request can influence how much trust your
team has in you and your work. And in Chapter 5 we will learn how one parti-
cipant uses his desk as a kind of central control, where he can connect with anyone
he needs to at a moment’s notice. Building trust is an essential move of commu-
nicating for future action.

Systems-Based
By systems-based, I mean that communication occurs across a flexible, adaptive
organizational network that is built upon relationships and feedback loops.
Donella Meadows (2008, p. 11) defined a system as “an interconnected set of
elements that is coherently organized in a way that achieves something.”
Additionally, organizational systems have histories and cultures that develop
and sustain over time. Looking at the whole of an organization is essential
because “systems thinking looks at relationships (rather than unrelated objects),
connectedness, process (rather than structure), the whole (rather than just
its parts), the patterns (rather than the contents) of a system, and context”
(Meadows, 2008, p. 6). In fact, organizational systems of communication are
influenced heavily by a company’s culture, which is represented in both tacit and
explicit ways. For example, there are implicit rules on every team (e.g., attend
meetings on time) just as there are explicit rules (e.g., do not interrupt people
during ideation sessions). These rules are often unique to an organization or a
team. On temporary teams, the implicit rules must be learned more quickly.
There is an interplay between organizational culture and hierarchy, and team
communication often works within these systemic considerations by treating them
as context. For example, Mintzberg (2013) explained “In contrast to decision
making as a form of controlling, culture is decision shaping as a form of leading”
(p. 50, emphasis in original). While people make decisions about communicating
with others, they often consider what they know about previous interactions with
a specific person. As a result, project managers appear to grapple with histories
and cultures of organizational systems, sometimes as a means of working within
a set of system constraints and other times with an eye toward making some sort
of change to the work or team environment.
Systems are also made up of feedback loops. Feedback can be written and
formalized, such as in evaluations of work that get filed with Human Resources,
or it can be less formal and referential, such as a brief follow-up conversation
after a meeting. To this point, Meadows (2008, p. 72) argued that the goal “is to
60 Communicating Project Management

recognize what structures contain which latent behaviors, and what conditions
release those behaviors—and, where possible, to arrange the structures and
conditions to reduce the probability of destructive behaviors and to encourage
the possibility of beneficial ones.” The systems approaches described in the prev-
ious quote suggest that teams must work in participation with each other in order
to achieve their objectives. In Chapter 4, we see examples of mutual adjustment
as people work to make space through communication strategies and practices.
In fact, it is the concept of making space for participation that proves essential
to a participative paradigm for project management.

Conclusion
In this chapter, I argued that the paradigm of project management has trans-
formed from an efficiency model to a participative one. To support this claim,
the chapter demonstrated several tensions that exist that demonstrate evidence
of the transformation. Recognizing this transformation is important because it
emphasizes participatory approaches to communicating project management.
The chapter additionally introduces the idea that project managers must com-
municate in ways that make space for individuals to exercise their agency and
participate at opportune moments throughout a project lifecycle. The goal for
making space is to give people on teams, including stakeholders and customers,
multiple opportunities to participate in project work, either through using
information communication technologies to solicit feedback or to structure
conversations and meetings for engagement. In my view, making space for
participation is a bedrock principle of project management communication.
In a participative paradigm, people must discover pathways for engaging and
participating in project work. What this chapter concludes is that engaging with
effective communication is one essential way to make space for people to
participate in project work.
In the next chapter, I focus on the results of the first case study, which dis-
cusses the social factors and strategies project managers consider when
communicating. The chapter further illustrates how project managers make
space for people using rhetorical communication strategies that are intentional
and reactive, focused on future action, and based on systems thinking. The chapter
also addresses how by making space for people to effectively participate, project
managers deliberately try to find methods for teams to coordinate work across
organizational networks. Furthermore, making space is an important part of
positioning project management methodologies as a heuristic because as projects
unfold, the exigency of the moment tends to disrupt the rigidity of development
methods. Finally, the next chapter also contests the idea of making space by
providing examples of communication that shows misalignment and/or a lack
of engagement with people on the team.
 Rethinking the Paradigm of Project Management 61

Notes
1 Recently a Google employee wrote a ten-page memo about why women do not make
effective programmers, arguing it is partly biological. For more information visit:
www.cnbc.com/2017/08/10/3-reasons-the-google-anti-diversity-memo-is-wrong-
about-women-in-leadership-according-to-data.html.
2 One useful approach is offered by Mintzberg (2013), who walked readers through five
example mindsets, such as “The Energetic Thread” (p. 151), “The Reflective Thread”
(p. 152), and “The Collaborative Thread” (p. 156), the latter where “There is a sense
of respecting, trusting, caring, and inspiring, not to mention listening” (p. 157).
3 A “Yes, and . . .” approach is a game used in improvisation. The goal of the game is
not to dismiss any one person’s ideas by saying no. Instead, the prompt “Yes, and
. . .” forces people to build on each other’s ideas instead.
4 By using this term, I do not mean to suggest an Aristotelian deliberative rhetoric, which
focused on making political arguments or arguments for the future. Rather, I mean
future action as a method of thinking about building relationships in the future.

References
Amidon, S., & Blythe, S. (2008). Wrestling with proteus: Tales of communication manag-
ers in a changing economy. Journal of Business and Technical Communication, 22(1),
5–37.
Apke, L. (2015). Understanding the Agile manifesto. Raleigh, NC: Lulu Publishing.
Barker, J. R. (1993). Tightening the iron cage: Concertive control in self-managing teams.
Administrative Science Quarterly, 38(3), 408–437.
Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., . . .
Thomas, D. (2001). Manifesto for Agile software development. Retrieved from http://
agilemanifesto.org.
Berkun, S. (2008). Making things happen: Mastering project management. Sebastopol, CA:
O’Reilly Media.
Cohn, M. (2005). Agile estimating and planning. Upper Saddle River, NJ: Prentice Hall.
Collinson, D. L. (2003). Identities and insecurities: Selves at work. Organization, 10(3),
527–547.
Davies, R., & Sedley, L. (2009). Agile coaching. Raleigh, NC: Pragmatic Programmers LLC.
Dicks, R. S. (2004). Management principles and practices for technical communicators.
New York: Longman/Allyn & Bacon.
Dicks, R. S. (2013). How can technical communicators manage projects? In J. Johnson-
Eilola & S. A. Selber. (Eds.), Solving problems in technical communication. Chicago, IL:
University of Chicago Press.
Doerfel, M. L., & Gibbs, J. (2014). Field research. In L. L. Putnam & D. K. Mumby (Eds.),
The Sage handbook of organizational communication: Advances in theory, research, and
methods (pp. 223–244). Thousand Oaks, CA: Sage Publishing.
Drucker, P. F. (2009). The essential Drucker: The best of sixty years of Peter Drucker’s essential
writing on management [Kindle version]. Retrieved from Amazon.com.
Edmondson, A. (1999). Psychological safety and learning behavior in work teams.
Administrative Science Quarterly, 44(2), 350–383.
Fleckenstein, K. S., Spinuzzi, C., Rickly, R. J., & Papper, C. C. (2008). The importance of
harmony: An ecological metaphor for writing research. College Composition and
Communication, 60(2), 388–419.
62 Communicating Project Management

Frost, E. A. (2016). Apparent feminism as a methodology for technical communication

and rhetoric. Journal of Business and Technical Communication, 30(1), 3–28.
Geisler, C. (2003). When management becomes personal: An activity-theoretic analysis
of Palm Technologies. In C. Bazerman and D. Russell (Eds.), Writing selves and
societies: Research from activity perspectives (pp. 125–158). San Diego, CA: Mind,
Culture, and Activity and Fort Collins, CO: academic.writing. Retrieved from https://
wac.colostate.edu/books/selves_societies/geisler/geisler.pdf.
George, M. L. (2005). The lean Six Sigma pocket toolbook: A quick reference guide to nearly 100
tools for improving process quality, speed, and complexity. New York, NY: McGraw-Hill.
Goldratt, E. M., & Cox, J. (2014). The goal: A process of ongoing improvement (30th
anniversary ed.). Great Barrington, MA: North River Press.
Hackos, J. T. (2007). Information development: Managing your documentation projects,
portfolio, and people. Indianapolis, IN: Wiley Technology Pub.
Hällgren, M., & Söderholm, A. (2011). Projects-as-practice: New approach, new insights.
In P. Morris, J. Pinto, and J. Söderlund (Eds.), The Oxford handbook of project
management (pp. 500–518). New York: Oxford University Press.
Heron, J., & Reason, P. (1997). A participatory inquiry paradigm. Qualitative Inquiry, 3(3),
274–294.
Johnson, R. R. (1998). User-centered technology: A rhetorical theory for computers and other
mundane artifacts. Albany: State University of New York Press.
Kaptelinin, V., & Nardi, B. A. (2012). Activity theory in HCI: Fundamentals and reflections.
San Rafael, CA: Morgan & Claypool.
Kensing, F., & Greenbaum, J. (2013). Heritage: Having a say. In J. Simonson, and T.
Robertson (Eds.), Routledge international handbook of participatory design (pp. 21–36)
[Kindle version]. Retrieved from Amazon.com.
Killingsworth, M. J., & Jones, B. G. (1989). Division of labor or integrated teams: A crux
in the management of technical communication? Technical Communication, 36(3),
210–221.
Krafcik, J. F. (1988). Triumph of the Lean production system. Sloan Management Review,
30(1), 41.
Lauren, B., & Pigg, S. (2016). Networking in a field of introverts: The egonets, networking
practices, and networking technologies of technical communication entrepreneurs.
IEEE Transactions on Professional Communication, 59(4), 342–362.
Law, J. (2004). After method: Mess in science research. New York: Taylor & Francis.
Lawler, E. E. (1986). High-involvement management. San Francisco, CA: Jossey-Bass.
Lay, M. M. (1991). Feminist theory and the redefinition of technical communication.
Journal of Business and Technical Communication, 5(4), 348–370.
Longo, B. (2000). Spurious coin: A history of science, management, and technical writing.
Albany: State University of New York Press.
Massey, D. (1994). Space, place and gender. New York: John Wiley.
McIntyre, A. (2008). Participatory Action Research. Los Angeles, CA: Sage Publications.
Meadows, D. H. (2008). Thinking in systems: A primer. White River Junction, VT: Chelsea
Green Publishing.
Merholz, P. (2015). Shaping organizations to deliver great user experiences. Presentation
at the Information Architecture Summit, Minneapolis, MN. Retrieved from www.
slideshare.net/peterme/designing-organizations-to-deliver-great-user-experiences.
Mintzberg, H. (2013). Simply managing: What managers do—and can do better. San
Francisco, CA: Berrett-Koehler Publishers.
 Rethinking the Paradigm of Project Management 63

Mir, R.A., Mir, A., & Upadhyaya, P. (2003). Toward a postcolonial reading of organizational
control. In A. Prasad (Ed.), Postcolonial theory and organizational analysis: A critical
engagement (pp. 47–73). Houndsmills, UK, and New York: Palgrave.
Morris, P. W. G., Pinto, J. K., & Söderlund, J. (2011). Introduction: Towards the third wave
of project management. The Oxford handbook of project management (pp. 1–11).
Oxford and New York: Oxford University Press.
Oldenburg. J. (2016). Participatory healthcare: a person-centered approach to healthcare
transformation. Boca Raton, FL: CRC Press LLC.
Paretti, M. C., & McNair, L. D. (2008). Communication in global virtual activity systems.
In K. St. Amant & P. Zemlianksy (Eds.), Handbook of research on virtual workplaces and
the new nature of business practices (pp. 24–38). Hershey, PA: IGI Global.
Phillips, K. W. (2014). How diversity makes us smarter. Scientific American. Retrieved from
www.scientificamerican.com/article/how-diversity-makes-us-smarter.
Pigg, S. (2014). Coordinating constant invention: Social media’s role in distributed work.
Technical Communication Quarterly, 23(2), 69–87.
Potts, L. (2014). Social media in disaster response: How experience architects can build for
participation. New York, NY: Taylor & Francis.
Project Management Institute. (2013). The project management body of knowledge (5th ed.).
Newtown Square, PA: Project Management Institute, Inc.
Rainie, H., & Wellman, B. (2014). Networked: The new social operating system, Cambridge,
MA: MIT Press.
Rasmusson, J. (2010). The Agile samurai. Raleigh, NC: Pragmatic Programmers.
Ratcliffe, L., & McNeill, M. (2011). Agile experience design: A digital designer’s guide to agile,
lean, and continuous. New Riders.
Richardson, G. L. (2010). Project management theory and practice. Boca Raton, FL: CRC Press.
Royster, J. J., & Kirsch, G. (2012). Feminist rhetorical practices: New horizons for rhetoric,
composition, and literacy studies. Carbondale: Southern Illinois University Press.
Saval, N. (2014). Cubed: A secret history of the workplace. New York: Doubleday.
Selfe, C. L., & Selfe, R. J. (1994). The politics of the interface: Power and its exercise in
electronic contact zones. College Composition and Communication, 45(4), 480–504.
Simmons, W. M. (2007). Participation and power: Civic discourse in environmental policy
decisions. Albany: State University of New York Press.
Simmons, W. M., & Grabill, J. T. (2007). Toward a civic rhetoric for technologically and
scientifically complex places: Invention, performance, and participation. College
Composition and Communication, 58(3), 419–448.
Sims, C., & Johnson, H. L. (2012). Scrum: A breathtakingly brief and Agile introduction.
Dymaxicon.
Smith, T. (2000). Technology and capital in the age of Lean production: A Marxian critique
of the “new economy.” Albany, NY: State University of New York Press.
Söderlund, J. (2011). Theoretical foundations of project management: Suggestions for a
pluralistic understanding. In P. Morris, J. Pinto, and J. Söderlund (Eds.), The Oxford
handbook of project management (pp. 15–36). New York: Oxford University Press.
Spinuzzi, C. (2003). Tracing genres through organizations: A sociocultural approach to
information design. Cambridge, MA: MIT Press.
Spinuzzi, C. (2005). The methodology of participatory design. Technical Communication,
52(2), 163–174.
Spinuzzi, C. (2015). All edge: Inside the new workplace network. Chicago, IL: University of
Chicago Press.
64 Communicating Project Management

Stave, K. A. (2002). Using system dynamics to improve public participation in environ-

mental decisions. System Dynamics Review, 18(2), 139–167.
Suchman, L. (2004). Decentering the manager/designer. In R. Boland and F. Collopy (Eds.),
Managing as designing (pp. 169–173). Stanford, CA: Stanford University Press.
Sullivan, P., & Porter, J. E. (1997). Opening spaces: Writing technologies and critical research
practices. Greenwich, CT: Ablex Pub. Corp.
Sun, H. (2012). Cross-cultural technology design: Creating culture-sensitive technology for local
users. New York: Oxford University Press.
Swarts, J. (2008). Together with technology: Writing review, enculturation, and technological
mediation. Amityville, N.Y: Baywood Pub.
Wajcman, J. (1998). Managing like a man: Women and men in corporate management.
University Park, PA: Pennsylvania State University Press.
Winner, L. (1980). Do artifacts have politics? Daedalus, 109(1), 121–136.
Yates, J. (1989). Control through communication: The rise of system in American
management. Baltimore: Johns Hopkins University Press.
3
COMMUNICATING TO MAKE
SPACE FOR PARTICIPATION
Locating Agency in Project
Communication

Many teams practice “Scrum-but,” which is to say “it’s Scrum, but we

changed it.”
John Hedtke, personal conversation, September 21, 2017

You can easily structure a conversation to open up space for other people.
Participant 8 in this chapter, personal interview

Management books tend to focus on the function of management inside its

organization. Few yet accept it as a social function. But it is precisely because
management has become so pervasive as a social function that it faces its most
serious challenge.
(Drucker, 2009, p. 8)

When participation is made a central concern of effective communication,

project managers are well positioned to make space for people. Yet, making space
is not done in isolation; rather, it is a collaborative effort. Participation is co-
constructed. When a project manager intends to make space for participation,
they are acting as writers: deliberately communicating in ways that invite people
to exercise their agency and to contribute to a team’s collective success. Even
so, participation is tricky. Just because an invitation is sent does not mean some-
one will indeed participate. They may ignore an invitation, despite best intentions.
Project management communication is, in part, about working to eliminate or
minimize such risks, which is why the delivery of an invitation is so important
to participation. This chapter is about the communication factors project
managers and leaders consider and the corresponding strategies they report
using to invite participation in project work.
66 Communicating Project Management

In evaluating space for participation on a project team, a project manager may

learn that some people have far more space than others. For example, someone
with very little space may contribute far less to an ideation session, whereas
someone else may consistently own the loudest voice in the room. With recent
research showing that diversity makes development teams smarter (Phillips,
2014) and also leads to innovation (Hewlett, Marshall, & Sherbin, 2013), it seems
timely to also evaluate how much space there is for diverse people and views on
development teams, and for voices with varying opinions or ideas. If there is
no space for communicating across difference, diversity is more of a descriptive
trait of people on a team rather than an influence on the products and services
teams ultimately produce.
With this in mind, making space for participation is also inherently rhetorical.
That is, the interviews in this chapter seem to approach making space as an
invention activity. Space can be discovered. Space can be found. It is often con-
tested, sometimes in the hidden corners of organizations and other times agitating
in the wide open. And, no one person owns it or makes space alone. So, by
“making space” I mean how project management communication aims to include
multiple points of entry for people to participate in the work of development
teams. In using the phrase “making space,” I do not mean to signal that all project
management communication focuses on making space for all people in an
organization at every moment. But a main function of project management
communication is to extend an invitation to all stakeholders, and to work
together to find space for people to participate when their contribution will be
most helpful. Indeed, as this chapter shows, much of the communication swirling
around today’s development work is about discovering the conditions in which
people will exercise agency and participate.
This chapter extends the discussion in previous chapters by turning sole
attention to the communication of project managers. What follows is a discussion
of the social space around project work on development teams. While the stra-
tegies reported are sometimes ineffective or even troubling, they are also insightful
in that they demonstrate how people perceive the social space of project work.
First, I theorize the concept of making space for participation by explaining the
influence of place and space on project work. Second, I introduce the research
conducted for this chapter, including a brief description of methods and par-
ticipant profiles. Third, I detail the factors and strategies the interview participants
considered as they made space for participation in project work. The chapter ends
by returning to the overlapping traits of project management communication
to further extend and situate them in the results of the interviews.

Theorizing Making Space Through Communication

When we talk about making space for participation, it is essential to note that
space as a concept is often paired and sometimes conflated with place. However,
 Communicating to Make Space for Participation 67

place and space each have a different influence on how people communicate and
participate in project work. In Physica, Aristotle argued that place was a kind of
definitional container that delimited certain types of action and had historical
elements. In the context of communicating project management, place is repre-
sented by built environments that have rhetorical features that influence
participation and interaction. In short, certain environments promote rhetorical
action and meaning based on their design. To illustrate, the floor of an office
building with a group of closed-door offices and cubicles clearly indicates
hierarchy and collaboration expectations (that is, those with offices are generally
higher up in the organizational hierarchy and will likely be expected to collaborate
less often). Meanwhile, an open floorplan with no assigned seating indicates
decentralized hierarchy and collaboration expectations (that is, everyone should
participate in collaboration when appropriate). While practice does not always
follow design, the built environment very clearly promotes specific ways of par-
ticipating and communicating at work.
In comparison to place, space is a less tangible concept. Spatial relationships
can have a similar influence as place, but are more of an abstraction—a precursor
of sorts. Aristotle also argued space is place not made. Space, as an abstraction
of place, innately contains the affordance of being constructed and reconstructed
in perpetuity until the ideas being produced are given a physical representation.
For example, imagine an ideation session where people think through the design
of an artifact. The group may engage and consider several ideas without physically
representing them, but once they assemble the ideas in physical form, they move
from one location (an idea space) to another (a piece of paper). Theoretically,
space is a flexible and abstract notion, and in the context of development projects,
can be understood as socially constructed. If place serves as a constraint of the
rhetorical situation, moving a person to act and strategize toward particular
orientations, then space represents the constraint of potential, (re)configuration,
and social influence.
Let me further illustrate this interplay with an example related to how place
and space can influence participation in development work. When facilitating a
design thinking workshop in a long, narrow boardroom with a single table at
the center, the room and its furniture will no doubt influence how people
interact. The physical room itself is a constraint the facilitator of the workshop
must consider in the delivery of materials. That is, the room may make certain
kinds of interactions (for example, small group discussion) more difficult to
arrange. The walls and furniture cannot be moved because, pragmatically, they
are what makes the conference room a meeting place. Meanwhile, the ideas,
realizations, and interactions produced throughout the session are socially con-
structed in the context of that place. Space signals these less tangible and social
elements of the built environment, and is also highly dependent on the individual
or group of individuals that collectively work together in that room.
68 Communicating Project Management

Tim Peeples (2003, p. 321) explained that “social space refers to the relation-
ships produced (or made impossible or difficult to form) between people and
ideas.” Furthermore, Peeples argued, “the things we produce become, or are
themselves, actions. If I produce a shoe, I am not simply producing a shoe. I am
also acting on my world and others within it” (p. 320). The idea of “acting on
my world and others within it” is essential to understanding how people perceive
and participate in social space at work. It is the near constant collision of people
acting on their worlds made up of built environments and social spaces that
concerns making space for participation in project work. Project managers must
make space for people, yes, but they must also make space for the team, project,
and organization in that configuration. I do not mean to imply that spaces where
people interact are not socially constructed, but I am suggesting that effective
project managers often communicate in ways that make participation in project
work possible.

Extensions of Social Space

Places where people work have an important influence on how social space is
produced, constructed, and experienced, and when information communication
technologies (ICTs) are used to extend workspaces, the location of work becomes
more mobile, the structure of work more fluid, and the power dynamics less
predictable. As a consideration of communicating project management, ICTs have
truly changed the place and space dynamics in ways that emphasize the need for
flexibility, particularly in how people connect and participate.
No doubt workplace design is symbolic of organizational values and influ-
ences, but what constitutes a workplace has significantly changed in recent years.
For example, in Make Space: How to Set the Stage for Creative Collaboration, David
Kelly (2012) argued that working environments are essential to innovation and
collaboration. He then provides examples of how the Stanford d.school uses
different places to facilitate creativity. Others have noted the importance of the
“Third Teacher,” where learning is achieved through interactions with the
classroom and its embedded affordances. In many ways, the built environment
is a collaborator, of sorts, in project work.
As people continue to adopt networked tools to support work, the conceptual-
ization of the workplace as a singular environment has become blurred and
extended with the affordances of ICTs. These extensions of the physical workplace
modify the ways in which project managers must think about managing social
space. Today social space can exist online and be networked across a range of
other built environments: home offices, coffee shops, coworking spaces, public
libraries, other organizations, or mobilized vehicles like trains, buses, planes, and
cars. Conceivably, meetings can occur wherever a mobile device can find a
connection to the internet.
 Communicating to Make Space for Participation 69

ICTs also have a direct influence in how social space is extended across these
different places for working. A good example of this can be found in Spinuzzi’s
(2012) inquiry into coworking spaces in Austin, Texas, where he learned that
these spaces provide a range of resources and tools for professionals working in
and across diverging markets. People work alongside others who are employed
by separate entities. They share ideas and give each other feedback. As noted in
Chapter 2, organizations can no longer be understood as a kind of container where
work is done (and left behind), but as networked—comprised of linkages between
people, resources, tools, places, and spaces. Rainie and Wellman’s (2014) work
emphasizes this point by explaining how ICTs can lead to blurring the boundaries
between private and professional activities and identities. When managing
projects across networked organizations and teams, project communication
naturally grows more complex. There are more technologies and resources for
making space for participation in project work, but also for misunderstanding
the intent of communicating across working environments. The solutions to these
problems have inspired companies to reiterate the importance of face-to-face
contact, as evidenced by The New York Times article “Yahoo Orders Home
Workers Back to the Office” (Miller & Rampell, 2013). Interestingly, many of
those who participated in the interviews emphasized that face-to-face
communication is often preferred over interacting over ICTs.
One reason ICTs are so pervasive is because they make communication
efficient. ICTs afford people the ability and flexibility to send symbols,
photographs, alphabetic text, audio recordings, and audio-visual capabilities—
all in a single transmission and to multiple audiences at once. Project managers
and leaders can participate in several conversations while monitoring others.
Certainly the information conveyed via these platforms has an important
influence over the messages people send over ICTs about project work. For
example, in referring to Blitefield’s (2000) work, Swarts and Kim (2009, p. 212)
concluded, “possibilities for rhetorical action are tied to the transformation of
the spaces and places through which we move and that occasion us to speak.”
That is, writers and communicators also construct, by inventing or discovering,
the environments in which they act (Swarts & Kim, 2009). Importantly, because
workers no longer participate in environments that may have been tied to
physical workplaces in organizations in the past (i.e., watercooler conversations),
project management activities must also account for digital spaces and commu-
nication practices afforded by ICTs. In digital spaces, worlds can collide across
time zones, regions, cultures, and so on. These collisions create power dynamics
that influence the communication around project work and dynamics in
sometimes less visible ways, in which making space for participating a more
complex undertaking.
To illustrate the implicit power dynamics created by communicating with ICTs,
I turn to Participant 12, whom we will meet again later in this chapter. Partici-
pant 12 worked on a globally distributed team. As a result, the team relied heavily
70 Communicating Project Management

on digital technologies to connect and interact. One evening a positive report

was released about the company’s work, and people on the team were excited to
bask in the good press. During the excitement, a new employee who did not
understand the rules of using the tools sent a message to everyone on her team
in a chat room. Participant 12 explained, “You can’t put an ‘@all’ [in chat rooms
unless it’s important]” because some people are sleeping. In the exchange, a person
on the team firmly reminded the new employee of this social norm. Participant
12 thought that comment was actually in good faith and helpful because “It was
immediate feedback to a new employee that there are rules of engagement.” The
implicit rule here was clearly not made explicit to this employee until they had
already made a mistake. While it is not clear how detrimental the mistake was
over the long term, or how the error influenced later team dynamics, it certainly
demonstrated that power dynamics related to communicating via ICTs comes
with implicit rules that make practice explicit. In other words, project managers
and leaders must talk and think about the rules of engagement more than ever
before as both the type and reach of communication space has expanded in recent
years. As project management as a field continues to think about participatory
approaches, the interplay and reach of space and place remain an essential
consideration of communicating project management.

Locating Agency in Participation

As a rhetorical concept, agency represents how individuals empower themselves,
the means with which they act. There have been important studies in the
affordances of digital spaces and how they are used to empower people to
collectively organize toward a specific end, sometimes with life-or-death
consequences (Potts, 2014; Shirky, 2010). Such views represent the postmodern
critique of individual agency, where a person acts alone devoid of the social. Geisler
(2004) quoted Gaonkar (1993, p. 263) to summarize the critique: “the speaker
as origin rather than articulation, strategy as intentional, discourse as constitutive
of character and community, ends that bind in common purpose.” As established
earlier in Chapter 2, project management of development work is experiencing
a transformation in its paradigm—one where participation is becoming the
overarching principle behind communicating. In this context, project managers
are not autonomous agents, but articulators of teams, linked to complex
organizations, colliding social groups, and a slew of information communication
technologies. Indeed, as further argued in Chapter 2, the communication of these
project managers is generally reactive to the project manager’s perception—their
self-awareness—of their role in the rhetorical situation, while also working
toward some sort of useful or valuable future action and responding within a
complex system. It is the project manager’s own understanding of their perception
of these considerations that guides their thinking about communication.
 Communicating to Make Space for Participation 71

In networked organizations, agency does not belong to an individual or a group.

Agency becomes visible, as Grabill and Pigg (2012) explained, through interactions
across groups of people—even when those groupings are temporary or fast. At
root, participation is a concern of project management today because a project
manager alone cannot make people participate. If a project manager alone could
make space for participation, then we would also have to assume people always
want to participate at work, and given the opportunity, would always do so in
homogeneous ways. I do not believe that is true. Instead, the interview results
in this chapter suggest that participation in project work must be co-constructed
through effective communication strategies where agency is flexed and involve-
ment at needed levels is harnessed. It is the symbolic invitation to participate that
begins the interaction. Not to say agency would not exist without the invitation
to participate, but it is through becoming aware of these considerations that a
participative approach to communicating project management will thrive.
So, what considerations do project managers think about when working to
make space for participation? What kinds of strategies do they use given the broad
reach of social space and people acting on their worlds? In the next section, I
describe how I interviewed 14 people to learn more about the factors and
strategies they use when thinking about communicating project management.

Brief Description of the Study

After receiving appropriate institutional review of my research protocol, I
recruited participants using social and personal networks and conducted semi-
structured interviews. The goal for the interview questions was to engage with
different perspectives on how people communicate project management.
Additionally, I asked participants to reflect over their entire career and not to
limit their answers to the most current experiences or positions. As a result of
the semi-structured approach, interviews were conducted as conversations guided
by questions, that naturally evolved through relevant threads of conversation.
Interviews were conducted over the course of approximately nine months.
Ultimately, I assembled interviews from 14 project managers and leaders (seven
men and seven women) that had actively participated on development and
creative teams across a range of industries. To capture interview data accurately,
each interview was audio-recorded and later transcribed for coding. Interviews
lasted approximately one hour per participant.1 After interviews were recorded,
I coded the data for emerging themes using a grounded theory approach (Corbin
& Strauss, 2008). After themes, or what I called “factors,” were discovered
through this recursive coding process, I assembled examples to highlight the
variate range of each factor. The examples for each factor I called “strategies.”
After Amidon and Blythe, (2008, p. 12), I worked toward assembling the results
into a “multilogue,” or “a tapestry of voices” undoubtedly filtered through own
72 Communicating Project Management

researcher stance. In the results section of this chapter I discuss the factors and
strategies in more depth.

Participants
The people who elected to participate in the study varied by field, training, and
experience. Some of my participants were early-career while others were mid-
to late-career. I interviewed entrepreneurs alongside project leaders working inside
of technology companies that specifically had experience on development teams.
Some had degrees in Technical Communication, Engineering, Business, or
Information Science. Intentionally, I recruited participants that would provide
a range of responses across levels of experience, industry, and preparation. Most
participants were geographically located in the United States, although I did
manage to interview someone who had lived and worked in Sweden as a project
manager. The participants in the United States tended to work on the eastern
seaboard, midwest, and southern states. As well, all the participants reported
working with globally distributed teams or remote workers in some way, and as
a result, the interviews also discussed communicating in these contexts.
In Table 3.1, I give information about each participant. While not all
participants had the job title of project manager,2 each identified with being in
a project leadership position in some way. For example, Participant 9 noted
teaching project management classes at a university and had engaged in project
management activities in a previous position. Meanwhile, Participant 4 had
been given informal project management training and duties at work. Across each
of the participants, many had also discussed sharing in project management
activities as part of their work. For example, Participant 12 worked remotely on

TABLE 3.1 Interview Participant Profiles

Participant Title Industry

1 Information Technology Project Manager Software

2 Product Manager/Innovation Specialist Software
3 Senior User Experience Designer Automotive
4 User Experience Designer Software
5 Project Manager Info. Management
6 Project/Development Manager Software
7 Co-Founder/Principal Researcher Experience Design
8 Principal Performance Improvement Consultant User Experience
9 UX Designer Software
10 Project Manager Software
11 Product Manager Software
12 Technical Writer Software
13 Development Manager Software
14 Program Manager Software
 Communicating to Make Space for Participation 73

a team that did not have a traditional project manager, but used a project
management system. In this way, Participant 12 needed to be self-directed while
relying on the system to help keep her organized. Other participants worked in
organizations where product management was innately involved with project
management in some way, whether through assembling charters or other relevant
project-level activities.
In the next section, I discuss the factors and strategies that surfaced during
interviews. Additionally, the implications of the factors and strategies are dis-
cussed in the context of making space for participation in the final section of the
chapter.

Interview Results: Communication Factors and Strategies

Earlier I noted that factors were themes that emerged from the interviews in this
chapter. I’d like to clarify what I mean by factors and strategies. When I use the
term “factor,” I refer to the situational considerations participants discussed when
reflecting on the communication used to support project work. Factors may have
been learned or practiced because of experience managing projects or witnessing
others do the same. In this way, factors are highly influential into how com-
munication is conducted. The factors participants noted were often multifaceted.
For example, the factor of “Building and Maintaining Relationships” can be
classified as a way to develop rapport with people and build trust, but also as a
way to evaluate existing ties as a means for thinking through how to communicate
a certain kind of message. A project manager may share bad news with a specific
person before a meeting because they know one individual on the team has a
tendency to be negative. The rationale is as following: sharing bad news ahead
of time gives an individual time to process, which hopefully builds trust when
the individual realizes the project manager is considering their feelings.
Meanwhile, the project manager might also be thinking about delivering this bad
news to the rest of the team in a meeting, hoping that delivering the bad news
to this person first will make that meeting more productive. The factors do not
necessarily make or take space from people, but they do influence the strategies
that have more of that ability.
A “strategy” is an approach used to address or respond to a specific factor.
Strategies are highly dependent on the project manager’s (momentary or even
limited) perception of the rhetorical situation. It is also worth noting that there
was a clear tension between participatory methods of communicating and the
factors and strategies people reported. In some instances, strategies appear to take
away or complicate participation in unproductive ways. The results of the
interviews point to such tensions. However, I wish to argue, as Simmons and
Grabill (2007) did about civic engagement, that people on teams may have
different reasons for participating and that not everyone wants to participate in
the same ways. On development teams, some people are only needed for a short
74 Communicating Project Management

time to perform a certain function, such as testing prototypes. This same person
may be spread across several projects, so participation looks different for that
team. In this way, participation is not always egalitarian, and while I’ve made
this point before, it seems a timely moment to remind readers that participation
can ebb and flow in ways that make sense for a project and project team.
During the interviews, seven clear factors surfaced that seemed directly
influential to making space for participation on project teams. Some of the
strategies under each factor were widely adopted, whereas others were used by
only one or two people in my participant pool. My goal was to collect as many
strategies as possible to illustrate the contextual variance of the communication
work done across the pool. Additionally, it is important to note these factors and
strategies are not meant to be uncritically adopted. Rather, they are presented
for careful consideration and reflection. To make each factor and strategy
accessible, Table 3.2 details each factor and associated strategy.3

Factor 1: Personality Type

When making space for participation, the perceived personality type of indi-
viduals influenced how project managers made decisions about communicating
with people. Personality type was both formally and informally discussed in
interviews. For instance, there was discussion about how to work with people who
identified as introverts or extroverts. As well, there was some reflection on how
personality types vary across team cultures and backgrounds. Issues related to
personality type also seemed to have identifiable methods for evaluating individuals
(e.g., Myers-Briggs type indicator test or something comparable). For this reason,
perhaps, most participants readily discussed strategies of working with people who
appeared to be introverts or extroverts. Participants openly discussed several
methods of understanding personality type to help make space for participation.

Strategies for Responding to Personality Type

Understand Communication Styles and Approaches Vary by Person

Participant 4 suggested meetings must accommodate a variety of communication
approaches. His organization had trained project leaders to approach meetings
in ways that support introversion. One method was to provide multiple ways of
giving feedback “for the people who don’t want to speak up in the group, or may
need to follow up in a different way.” That approach also manifested in design
sessions with opportunities to verbalize or write out ideas. Participant 4 also
believed many introverts worked harder to find spaces to participate and “to get
[to a] certain comfort level with the team.” Meanwhile, Participant 11 added
nuance to the introvert/extrovert discussion by naming four different personality
types regularly discussed by her organization: “Expressives, Amiables, Analytics,
 Communicating to Make Space for Participation 75

TABLE 3.2 Overview of Communication Factors and Strategies

Factor 1: Personality type

• Understand communication styles and approaches vary by person
• Understand that ICTs overwhelm some personalities
• Be self-aware of the effects of your own personality type
• Learn to talk less
• Use role-play to disarm people
Factor 2: Gender
• Find common interests to build relationships across gender
• Adopt a gender neutral role to fit in
• De-emphasize gender disparities
• Identify efforts to silence women
• Use organizational networks and backchannels to give feedback and receive feedback
Factor 3: Cultural and Linguistic Diversity
• Focus communication on project work instead of language barriers
• Give multilingual people time to prepare and respond to requests
• Understand the influence of national cultural identity on meeting spaces
• Translate confusing language
• Use plain language
• Realize a person’s relationship to their cultural context is unique
• Be patient and give the benefit of the doubt
• Recognize cross-cultural disagreements exist
• Be interested in cultural difference
Factor 4: Building and Maintaining Relationships
• Embrace unscripted moments
• Learn about people’s intellectual background
• Use organizational networks as a sounding board
• Check on people’s perception of a communication or meeting
• Choose ICTs that get the job done (not always the latest technology)
• Embrace face-to-face communication
• Notify those affected by project changes ahead of time
• Learn who is being overworked and do something about it
• Recognize good work publicly
• Listen actively
• Be empathetic
• Be available to meet/talk outside of meetings
• Don’t waste people’s time
Factor 5: Attending to Psychological Safety
• Be available after meetings
• Make safety with structure
• Change the meeting structure to suit the teams
• Use ICTs to support feedback loops
• Create space for people to draw their own conclusions
• Understand how people experience safety
• Know that leadership personality can negatively impact safety
• Share in the risk of trusting people

continued
76 Communicating Project Management

TABLE 3.2 continued

• ICTs as surveillance can erode safety

• Use feedback loops
• Seize moments for feedback
• Create a dependable rhythm for communication
• Use kickoff meetings to normalize communication expectations
Factor 6: Development Methodologies
• Efficiency is less important than impact
• Adapt methods to the team or organization
• Adapt methodologies to the team or organization
• Use development approaches to influence work, but don’t apply them as a rule
• Address methodological confusion
• Be strategically agnostic
• Remember each organization, project, and team is unique
Factor 7: Organizational and Team Culture
• Learn the team’s origin story
• Contemplate organizational context
• Read hierarchies of influence
• Work to develop a culture of inclusion
• Remove Silos

and Drivers.” She explained, “there are different ways to talk with those types of
people. And different ways to make sure they both stay committed to common
goals, but also stay effective and on board with all the work that is being done.”
Finally, Participant 6 argued that introversion was far less important than a
person’s propensity for and interest in learning new things.

Understand that ICTs Overwhelm Some Personalities

Participant 2 explained an interesting phenomenon that for introverts, sometimes
ICTs can come across as loud or overwhelming. At times people think of ICTs
as offering people time and space to think through and respond to an inquiry.
Participant 2 further explained:

People think of online mediums as easier for the introvert, or that people
will participate more there. But we have had a couple things where we will
have these super long, like hundred message email threads, where the entire
company will have conversations, which is equally overwhelming. That’s
terrifying and loud.

Meanwhile, Participant 4 explained the importance of flexibility offered by

different media, sometimes participation is influenced by the amount or timing
of information.
 Communicating to Make Space for Participation 77

Be Self-Aware of the Effects of Your Own Personality Type

A sense of self-awareness of individual personality type and tendencies also
seemed important to participants. For instance, Participant 3 identified herself
as an introvert and explained that it influenced how she contributed to team
situations. She explained, “when I was talking about preferring asynchronous
communications, in a lot of ways, that’s part of my introversion coming out there.
I’m more anxious about having a real time conversation about things that I am
thoughtful about.” As Participant 3 continued, she explained that the best project
managers would “over-communicate.” She thought more about it for a moment
and explained, “I don’t know if over-communicate is the right word, but at least
lean more towards clarity and making sure that that’s available.” In her mind,
effective project managers needed to provide clarity, and that took self-awareness
of their own communication abilities.

Learn to Talk Less

Being self-aware also means knowing when, as project manager, you were talking
too much. Participant 14 jokingly explained, “so you probably figured out by
now that I am not shy for saying what is on my mind, and I do that a lot. And
I probably should shut up sometimes.” Participant 14 felt as though he dominated
conversations too often and pointed to a specific example where he asked team
members to be openly candid about giving feedback to deadlines during a
planning meeting. What happened, he explained:

[Is] nobody will say anything. So my strategy has been, and it hasn’t
worked yet, is like: “If you’d rather come and talk to me one-on-one or
send me an email about your concerns that is absolutely perfectly fine. You
don’t have to give me an answer now.”

Use Role-Play to Disarm People

Participant 8 described using a game to help introverted team members feel
more at ease. He called it “an old seven hats technique,” where people are
assigned roles for the duration of a meeting. The roles could be anything from
an idealist to a devil’s advocate, and the role of the project manager is to “create
space for each person to talk in this role that they are playing.” Next, the project
manager asks each person how they would play the role they were assigned,
which gives each person a chance to speak. He explained that asking such
questions could help people feel more comfortable participating. He thought of
the game as a way to make space for people who many not otherwise participate
in a meeting.
78 Communicating Project Management

Factor Two: Gender

Those who commented on gender as a factor for making space offered compelling
ideas that suggest it is an important and overlooked contributor to the social space
of project work. While some participants strongly perceived gender issues, others
remained unaware of them. Most of the discussion of gender was offered by
women participants.4 Also, it seemed that some participants just did not have a
vocabulary for addressing gender in the workplace. While examples related to
gender disparities or its influence on organizations and project communication
were pointed out, participants also expressed reservations, even skepticism,
about what they experienced. The strategies specifically reported by women
participants often demonstrated a resilient response to discovering space for
themselves to participate despite experiences with gender disparity. Overall, the
strategies explained in this section are perhaps indicative of more widespread,
systemic problems that project managers should be aware of when working to
make space for participation.

Strategies Related to Gender

Find Common Interests to Build Relationships Across Gender

Two participants reported building relationships across gender could be difficult.
For example, Participant 4 noted how he worked to build relationships with other
men: “I’m fluent with the guys that I am working with now, what games they
are playing, who their girlfriends are, what kind of cars they drive, what hobbies
and interests they have.” Participant 1 gave a similar answer, but also pointed
out some nuance when it came to building relationships with women:

It’s more likely that when I’m communicating internally with my own IT
staff [. . .] I will bring things [up] about video games and comic books and
techie stuff. When I deal with my own staff, they tend to be more male,
whereas when I’m communicating with a stakeholder that is a female, I’m
not necessarily bringing that up.

While Participant 1 might have also been reflecting on the formality of rela-
tionships across teams and stakeholders, particularly external stakeholders, he
was also suggesting that finding common interests is an important part of
building relationships across genders.

Adopt a Gender Neutral Role to Fit In

Participant 2, who was early-career at the time of the interviews, explained
working to downplay her gender and how it influenced the way she participated
 Communicating to Make Space for Participation 79

in project teams and work: “In being on a team that’s all guys, I do actively try
to make myself not gendered. Making sure that I’m being one of the guys and
cool.” In this way, she made space for herself in the social environment of the
team by working to downplay her gender.

De-Emphasize Gender Disparities

Even when gender disparity was apparent, not everyone agreed it was problem-
atic. Participant 12 who was mid-career, explained:

Even though my whole executive board at this company is white and male,
I don’t think gender is a thing. Even though the only female . . . I think
there’s one in HR and there’s one in QA . . . otherwise the managers are
male. But I mean, from my perspective, I don’t feel any kind of shift based
on gender. I’m not sensitive to it.

For Participant 12, a lack of gender equality seemed less important because
she felt as though she was treated well by her managers.

Identify Efforts to Silence Women

Participants explained how women were silenced or ignored during team
meetings using a variety of tactics. Participant 5, for instance, explained “I have
heard someone make a statement, ‘I made a comment on a strategy and an issue
and they didn’t listen to me. Then, a man reworded the statement again and
everyone listened.’” Participant 2 said that also happened to her:

I have had situations in the past where, and I don’t know if this might be
the ways that ideas are adopted, but I will say something and say something
and say something, then later when ideas are coming up from someone
else, and they start repeating it it’s like “Oh yeah, that’s a great idea!”

Even so, Participant 2 later explained gender issues were elusive because it is
unclear that gender caused the sequence of events. She explained, “I don’t know
if it’s in the way I am presenting it or just if that’s just the good way ideas are
spread.” Making space for participation also means giving credit to people for
their contribution (see Turner, et. al, 2017).

Use Organizational Networks and Backchannels to Give and

Receive Feedback
When asked how she might respond to a situation where she felt ignored or
silenced at work, Participant 5 explained she would utilize the networks inside
80 Communicating Project Management

her organization. She offered, “I want to say that at the moment, in that situation,
I would be more reserved and would wait to address it with someone else after
the fact.” Additionally, Participant 5 explained:

I have never been in that situation where I think in my head, “oh, because
of this situation I need to plan ahead.” That’s something gender-specific—
I have never proactively worked on it. It may be more of a reactive situation
to know how to deal with it the next time.

The use of workplace networks as a means for participating is particularly

important, as it appeared that these networks, often made up of trusted mentors
and advisors, were an important approach for responding to the uncertainty of
communicating across project teams. It would serve a project manager well to
both open spaces to participate in those networks and attempt to support this
form of communication.

Factor 3: Cultural and Linguistic Diversity

Every participant acknowledged working with remote workers or distributed
teams, and these experiences often led to meaningful interactions with people
from different cultural and linguistic backgrounds. Sometimes teams were
globally distributed, with core team members living and working all across the
world. In other instances, teams outsourced certain functions such as technical
writing or engineering to those who lived elsewhere, often in different countries.
Project managers often focused on understanding how different cultures com-
municated or participated during public interactions. Participant 8, for example,
believed project managers had to create space and implement strategies for
culturally and linguistically diverse teams to work together productively. Others
saw their role as translating ideas across groups of people or understanding
that the goal of the project manager is to facilitate and negotiate understand-
ing during confusing moments and then coordinate accurate information
accordingly.

Strategies for Considering Cultural and Linguistic Diversity

Focus Communication on Project Work Instead of Language Barriers

Participant 1 noted that focusing communication primarily on project work
during meetings would help “English as a second-language” speakers feel more
comfortable. In his experience, he had worked with “people who are from
Central and South America that haven’t been in the country very long but speak
very proficiently about the technology that we are trying to use.” He had learned
 Communicating to Make Space for Participation 81

that confusion more often had to do with misunderstanding “the project or their
own professional deficiencies, rather than their language [abilities].” Participant
11 had similar experiences and told the story of her first report that was from
India. She gave her employee instructions on how to complete an installation
and was surprised the next week to learn the person had not started. The person
explained, “Well you gave me the instructions but you didn’t tell me to start.”
For such reasons, Participant 11 felt being explicit rather than implicit when
communicating across cultures is important.

Give Multilingual People Time to Prepare and Respond to Requests

Participant 4 and Participant 8 suggested that giving people less comfortable
speaking in English extra time to prepare and respond to information requests
during meetings was useful. Participant 4 said the extra time was helpful when
people didn’t speak English and needed time to plan their response. Participant
8 explained he tried to approach each situation individually. For example, he’d
asked people to write something up for meetings so people could distribute
information without being put on the spot. He explained, “A lot of people I know,
Indians and Chinese, will write English better than they can speak it, so given
the opportunity and time to put their thoughts down into words, will appreciate
that opportunity.” He also advocated asking someone to work with that person
to make sure they were writing what they intended.

Understand the Influence of National Cultural Identity on

Meeting Spaces
National cultural identity is important to how meetings are organized and how
organizational hierarchy plays out. Participant 6, who had experience manag-
ing workers from Sweden and Finland, pointed out differences in individual
and collective views on managing. She explained, “In Sweden we like more
consensus. We like to discuss it and decide together. In Finland it’s the opposite,
it’s the manager deciding.” As a result, Participant 6 noted she had to stop using
Scrum because the technique was unproductive for the Finnish members of her
team.

Translate Confusing Language

Some of the participants noted that part of the job of a project manager is to
translate confusing information for people on the team. Participant 7 and Parti-
cipant 14, for example, felt that physical artifacts were important for commu-
nicating tacit information. To help translate confusing information, Participant
7 explained, “One of my communication patterns is to be the person who says,
82 Communicating Project Management

‘So what you mean is . . .’” She called it “restating.” In doing so, her goal was to
“[make] sure that it was heard in all of the different languages. And if three people
say they are saying the same thing, but don’t understand each other, then you
have to keep working at it.” Participant 8 explained this as being an advocate for
people. He told the story of one person on his team who bowed every time he
met someone. He eventually took him aside to tell him bowing too often was
making people in the group uncomfortable, and that bowing once to the entire
group would be more appropriate.

Use Plain Language

Participant 8 explained, “I have come to find out this idea of communicating
content rather than the form of the content.” In other words, Participant 8 worked
to remove barriers to communication by using plain language (see Willerton,
2015). He told a story where a team was becoming defensive because of how
information was being presented. He further explained:

So I find out, that the program manager had full-blown Asperger’s. So all
of these things started coming together. Things that were initially extremely
aggressive, weren’t intended in that way, and I was responding like they
were coming off as aggressive.

From this interaction he learned that people on teams can take sides over a
divide between the context and content of a message. Removing that barrier is
important for effective communication to occur.

Realize a Person’s Relationship to Their Cultural Context Is

Unique
Working in a truly global organization, Participation 10 explained that culture
could sometimes be negated because there was so much of it around, with little
time to address any associated problems. That said, she noted that her own
relationship to her ethnic culture and where she lives often came into contact
with her work. As a result, she felt flummoxed by how people would respond to
her because of where she lived rather than her performed identity as a project
manager. She explained,

Because I am Indian I can be direct, [and] they just assume that I am going
to be American in the way I deal with them, which is a strange thing to
work through. It’s more about organizational culture. It’s the way they see
headquarters culture, and satellite offices, that kind of thing. Anytime I go
to visit Spain or any other missions in whichever country, it’s like I have
 Communicating to Make Space for Participation 83

New York on my forehead. No matter what I say or how I do it, [they think
I’m saying] “go fuck yourself, get it done.” There’s nothing I can do about
it, and I have to just deal with that.

Be Patient and Give the Benefit of the Doubt

Other participants noted the importance of being patient when working with
people from other cultures. Patience is important because miscommunication
can occur in ways that seem intentionally ill-mannered. Participant 10 explained
that much can be lost in translation, especially when people are using tools to
translate from their language to English. She explained how someone on a team
wrote they thought she was “pretending” to do something, but did not actually
follow through. She learned, “he meant ‘intend’ but he was using Google
Translate software. Before I met them, I would have been worried, but because
I met them and I know that they are really honest, good kids I was able to not
worry about it so much.” Participant 8 argued for a similar approach, especially
avoiding thinking it is related “to stupidity on the other end.” He had found “too
many times that there are brilliant people who will run into the wall of
communication and not be able to get their ideas across in English” and noted
that he often can’t speak their language either. As a result, he assumed mis-
communication first in instances where he was working with people on
distributed teams or from different cultures.

Recognize Cross-Cultural Disagreements Exist

Sometimes issues related to people from different cultures emerge on teams during
project work. For example, Participant 8 explained that certain combinations
of cultures can present challenges in unexpected ways. He said, “I’ve had the
Turkish guy and the Greek in the same room, and that doesn’t work. Maybe
eventually, but not until they stop thinking about each other as the Turkish and
Greek guy.” While he did not provide a strategy for working through these issues,
he noted it is important to know that cross-cultural disagreements can exist, and
must be navigated.

Be Interested in Cultural Difference

Participant 8 grew up in an international family, and explained that he was
genuinely interested in differences between cultures. He felt this genuine interest
had helped him better manage international teams. He explained, “I can always
ask people about their name, clothing, food, their families—these things that are
universal and people love talking about them.” Learning about people on teams
also helped him avoid assumptions when miscommunication inevitably surfaced.
84 Communicating Project Management

Factor 4: Building and Maintaining Relationships

All participants noted the importance of building relationships as central to
making space for participation. Much of the relationship building activity
connected with Drucker’s (2009) ideas about the importance of sharing experi-
ences at work, but also simply taking an interest in the people that you work
with and demonstrating that interest through some sort of regular interaction.
As a factor for making space, building and maintaining relationships was reported
as essential to learning how people felt most comfortable in team situations.
Additionally, participants frequently evaluated existing relationships as a means
for communicating specific kinds of messages. Often teams tend to be assembled
around projects and because of the nature of project management it is likely they
will work together in the future on newly configured teams and different projects.
It seemed to be a shared belief of participants that building relationships internally
across the organization helped to make project management activities more
successful, and also helped establish productive social spaces.

Strategies for Building and Maintaining Relationships

Embrace Unscripted Moments

A common approach to building relationships and rapport was to engage
people in short, informal discussions about non-work topics, such as recapping
recent episodes of television shows or talking about family life. Sometimes these
discussions occurred at the beginning of team meetings, but other times, as
Participant 6 noted, “Everybody is going to have a coffee break and you talk about
work or family or things.” Participant 4 also found this sort of unscripted
approach valuable for building trust, particularly when looking forward to future
urgent requests that might be made: “I try to keep most communication light
and friendly, kind of two-thirds work and one-third friendly tangent.” Some
participants believed that building relationships with people would help make
future project-related requests receive more attention, but also they appeared to
suggest these relationships were genuine.

Learn About People’s Intellectual Background

For some participants, the background of people on the team is an important
consideration because it helped them understand the types of space that makes
different individuals comfortable. Considering intellectual background was useful
for shaping communication or understanding the best way to present something
in a meeting. Participant 6 worked to “find out the background of people,
have they worked together a lot? Have they been there a long time?” For Partici-
pant 6, these kinds of considerations were balanced with how technologically
 Communicating to Make Space for Participation 85

inclined and engaged a person seemed to be, and how to best engage with them
during informal instances where discussion about non-work items would occur.

Use Organizational Networks as a Sounding Board

The use of organizational networks was not limited to making space for
strategizing issues related to gender. Participants discussed using networks to get
feedback or as a sounding board. Participant 4 explained, “If I feel like I am out
of line, there are a few people out of work where I will check myself and wait a
minute. It’s usually other UX people and I will explain the situations and say,
‘Am I thinking about this wrong?’” Participant 6 explained a similar process of
engaging these networks to help sort through problems or confusing situations.
She described the process as, “So what I do is try to analyze, and before I act I
confirm my thoughts with someone I trust.” Participant 12 noted following
a similar process as well, but more so when or if she had questions about a specific
activity related to her job.

Check on People’s Perception of a Communication or Meeting

Several participants noted that making space also meant checking the accuracy
of someone’s perception of a meeting or communication. Participant 4 explained,
“I think a lot of communication is the perception of the people who are being
communicated to. I think that messaging or vocabulary can be taken wrong
sometimes.” Participant 11 brought up how regular meetings, like sprint
retrospectives can be used to do similar work. Prompts can be introduced to the
retrospective that focus on perception, like ‘Do we think this is still working?
Are we OK? Are we covering the right topics? Are we spending all of our stand
up time appropriately?’ ” Participant 1 used a similar approach and said,
“Sometimes it’s just an email that you send to them personally. You’ll say “Hey
I just wanted to make sure that you’re OK with everything as far as the project
is concerned.” Participant 1 also used open-ended questions before moving
forward during meetings to give everyone the space to participate. Additionally,
Participant 5 discussed the importance of following up with people after meetings
to make sure all is well, especially if they don’t comment on items directly
related to their work.

Choose ICTs that Get the Job Done (Not Always the Latest
Technology)
Participants noted the importance of making space by choosing ICTs that
supported the team’s needs. Participant 3 noted that teams often choose the ICTs
to communicate with each other because “when a project manager has tried to
do that, it has been less successful.” Additionally, Participant 3 explained that
86 Communicating Project Management

“one-stop-shop” approaches to choosing ICTs rarely proved effective because

“people have Skype open all day, this guy prefers a direct text message, this guy
prefers face-to-face and if you email them they are going to walk right over to
your desk.” Participant 4 explained that sometimes the latest technology did not
always work the best for teams that were distributed. In one example Participant
4 pointed to, “there were a lot of emails going back and forth, but we found it
easiest to go through the most issues with a good old-fashioned conference call.”

Embrace Face-to-Face Communication

Every participant highlighted the importance of face-to-face communication over
the use of ICTs, especially to address conflict and problem-spaces. While ICTs
were useful for sharing information, participants generally felt that face-to-face
communication allowed for more tacit information to be passed. Participant 11
highlighted, “if there is some amount of conflict in the discussion, I’ll try to pull
up face to face, and certainly I’ll do that more often with people who will react
quickly to the message.” At other times, face-to-face communication seemed more
effective for communicating project parameters or client needs. For example,
Participant 14 explained a process of standing in front of a Kanban Board and
physically moving cards rather than relying on digital scheduling platforms. He
felt this face-to-face contact helped people see the project and ask questions.
Participant 7 related a story about how the office environment at one organization
was an open floorplan, “So we spent a lot of time pulling up next to somebody’s
computer and talking to them and seeing what was going on.” In this example,
it appeared that the face-to-face communication also supported more
opportunities for mentoring.

Notify Those Affected by Project Changes Ahead of Time

Some participants noted checking in with people before and after meetings as a
strategy for building goodwill and preparing people for changes. Participant 8
explained how introducing ideas to some people at work before meetings was
important because if there was a dissenting opinion, he wanted to negotiate buy-
in before the meeting. The approach Participant 8 described is also useful for
making sure people are not surprised in the moment: “Some people call it
dropping dimes, where you make someone else look bad. If anything is coming
down, the person that it’s impacting should be notified before the team.”
Participant 11 felt that notifying people of changes or presenting them with
information, such as a project roadmap, was an important part of understanding
how projects help organizations meet business goals. The need for clarity is why,

for any conversations like that, I try to make sure that they have multiple
opportunities not only to see it, but also to chime in. For quieter folks on
 Communicating to Make Space for Participation 87

the team, I make sure that they have time to review and have time for
feedback, before communicating it out to the rest of the firm.

Learn Who Is Being Overworked and Do Something About It

Participant 7 noted the importance of monitoring workload as a way to build
relationships. Learning about employees and their workload was important
because, “if someone was having a rough week, I wanted to know about it so
that I don’t pile it on, because people who have it piled on don’t do good work.”
This approach also worked for taking time off to help refresh employees.
Participant 7 felt that when people worked long hours getting a project done,

Then I want you to take that comp time immediately. So go home, do your
laundry, see your kids, wash the car, sleep—I don’t care. But I want you
rested and rejuvenated so that you can come back to work.

Also, building time off into project cycles was essential for negotiating
timelines, roadmaps, and so on.

Recognize Good Work Publicly

Participant 8 suggested the importance of publicly giving people recognition for
their hard work as one way to make space for people. He explained, “I also take
every opportunity to find a way to outwardly recognize important contributions
that that person makes.” And while not everyone gets the same amount of recog-
nition, Participant 8 emphasized:

What I care about is that my time with this person produces a more
significant output to the product, and that’s what I am paid to produce.
So taking the time to call out the contribution, stuff like that relationship
building is really important.

Listen Actively
All participants discussed the importance of active listening in making space for
participation. Participant 9, for example, mentioned that listening could influence
the quality of project outcomes. Participant 3 tied learning about active listening
to her training in education and human development, although she also
cautioned that it “doesn’t help me move my ideas forward.” When asked what
advice they would offer people looking to work on project management skills or
to become a project manager, many noted something similar to Participant 10:
“Leave a lot of room to listen and really hear what other people are saying.”
88 Communicating Project Management

Be Empathetic
Participant 10 explained how empathy can materialize in a range of ways, and
as a result, project managers have to sometimes give people space to ideate even
when it isn’t practical, because it makes work exciting for the moment. Participant
10 also felt when asking people to adopt new tools, “for that kind of thing you
just have to shut the fuck up, because for them it’s more like a mind change, and
an adjustment to their reality.” Participant 1 echoed this sentiment, but focused
instead on installing enterprise software in organizations, where a great deal of
his work was situated. From his view, “you have to be pretty tolerant and have
a lot of empathy for what your users are going through.” At another point in the
interview, he offered additional need for empathy: “the whole philosophy of a
project is that it’s something new to the user.” Participant 1 stated his experience
taught him that pushback on new initiatives like he described was normal,
and that he worked to understand pushback as “emotional or professional
constraints” rather than some sort of personality defect.

Be Available to Meet/Talk Outside of Meetings

Participants suggested the importance of being available outside of formal
meetings to field questions, build rapport, or to even allow someone to blow off
steam. Participant 2 noted that her organization had an open-meeting policy,
but said most people did not take advantage of it. Meanwhile, she had taken
advantage of the open-door policy of managers, noting that it can be helpful after
contentious or confusing meetings. Other participants noted the importance
of being available for lower-stakes meetings, like lunch or coffee meetings.
Going to lunch or coffee during work hours was useful for some participants as
a method of solving problems or airing grievances. Participant 11 mentioned an
incident at work where someone was confused about the delay in a request, “So
I just went out to lunch with him, and we were able to talk through why, and
just after lunch he was able to reach out to the developer who was waiting for
him.” Participant 11 argued that finding opportunities for communication was
especially important on distributed teams, and that project managers could
facilitate those discussions through informal interactions during meetings.

Don’t Waste People’s Time

Participant 8 recalled a time he had a call and mistakenly noted it for the wrong
time zone. In his estimation, mistakes like that erode trust, especially in new
relationships. He explained, “when it’s a new relationship and you’re relying on
deadlines and you don’t really have time to build up that trust, it seems to bog
down everything.” In addition, Participant 8 explained the importance of having
back-up communication channels ready to go for distributed teams to avoid
 Communicating to Make Space for Participation 89

wasting time, noting that he expends a lot of mental and physical energy in order
to not waste people’s time.

Factor 5: Attending to Psychological Safety

Team Psychological Safety constitutes “a shared belief that the team is safe for
interpersonal risk taking” (Edmondson, 1999, p. 354), and “must characterize
the team rather than individual members of the team, and team members must
hold similar perceptions of it” (pp. 354–355). Edmondson’s argument suggests
safety is essential to effective team formation. While not explicitly mentioning
the term psychological safety, all participants highlighted the importance of
feeling as if teams constituted or represented a safe space. Conversely, interviews
also seemed to suggest safety was felt or experienced at the individual level. That
is, participants suggested teams could have a high level of psychological safety,
but had to negotiate it by making space for individual people on the team.
In some ways, this finding demonstrates that psychological safety could be
temporary and relatively fragile because it is built on trust. At the same time, for
some participants, psychological safety was achieved by structure or through useful
feedback—forms of reassurance that helped them surmise their value to the
team. Also notable is that discussions about psychological safety most often
overlapped with elements of other factors, particularly building relationships and
organizational and team culture.

Strategies for Attending to Psychological Safety

Be Available After Meetings

Assembling multiple platforms and opportunities for participation enhances
psychological safety by avoiding the silencing of people. For example, Partici-
pant 4 had seen people silenced in previous meetings because of a dominant
personality and had noticed that “People either waited for the meeting to
conclude and spoke in smaller circles, or just came to me directly and said ‘I didn’t
get a chance to put this out there, but I really wanted to say this.’”

Make Safety with Structure

Developing clear structure was another strategy used to create safety on teams.
Structures seemed to help make sure everyone could participate, surprises were
diminished, and people could more readily where a project was going. For
Participant 3, this manifested itself in meeting spaces: “I think the environments
where I felt the most safe have been structured meetings, where someone has
reminded everyone about that expectation and there is some mechanism to ensure
it.” The mechanism might have been rules for engagement or consequences for
90 Communicating Project Management

breaking the rules. Participant 6 explained how meeting agendas were also used
to support safety, specifically to limit fear. When she planned meetings for
people “who were more afraid of technical things, I had a very clear agenda so
they knew in advance what we were supposed to be talking about. There was no
surprises at all and it was very clear.”

Change the Meeting Structure to Suit the Team

When working across cultures, Participant 6 told a story where some meeting
spaces didn’t contribute to psychological safety. Earlier I mentioned that she had
worked in Sweden as a project manager, but also spent time managing people
in Finland at a distance. When trying to build in Scrum meetings to make space
for collaboration, it didn’t work because of the makeup of the team. To address
this issue she planned other meetings for “those that were more technical” so
they could get into more details about the project.

Use ICTs to Support Feedback Loops

Participant 12 explained how almost every call with her team focused on
brainstorming because of the nature of their work. She noted how the features
of the software made it easier to avoid interrupting people in the middle of a
conversation. During a recent call “somebody pinged in and said ‘Why don’t we
consider having an IP address as an option for the input command?’ And two
other people put +1 +1.” In the end, the team used that feedback and added that
option. In describing the interaction, Participant 12 explained, “It was all very
kindly phrased, very gently suggested, and embraced.”

Create Space for People to Draw Their Own Conclusions

Participant 11 told a story about how his current organization was working to
emphasize a strategic direction for the company through project work. To do
so, they developed a slideshow that demonstrated the need for the change by
providing data about the company and its products. Participant 11 explained,
“I think, as people see the data, and see more about why we are doing these things,
they get on board as well.” When I asked why he wouldn’t just go tell people to
change, he responded, “letting them come to their own conclusion is a more
effective way to get more people on board.”

Understand How People Experience Safety

Of the work she did at a company, Participant 7 explained, “We worked really
hard to make it a safe place to tell you what was going on, and tell you what was
really happening.” The concept of safe space was something that often came up
 Communicating to Make Space for Participation 91

repeatedly in interviews. Participant 8, for example, explained that creating a safe

space can be challenging because “Sometimes, what I find is the person goes back
into their cocoon but they are happier about it. Other times, having that breach
in the damn means later they start speaking up, getting the conversation to flow.”
In other words, safe spaces can be temporary or can produce unexpected out-
comes. When I asked Participant 8 how he knew when or if a safe space had been
created for someone, he responded, “the defining moment where space has been
created for someone is where everyone stops and looks expectantly at someone,
and that someone is not in mortal terror.” In these instances, people seem to feel
as if they are operating within their own expertise.

Know that Leadership Personality Can Negatively Impact Safety

Meanwhile, there was also discussion about the kinds of situations and
personalities that do not produce safety, or perhaps inhibit it. Participant 9 told
an interesting story about being on a team with a project manager who “was a
great guy, but he was a retired military colonel, and believed that you couldn’t
beat schedules. The team got used to not telling him the ugly truth that it wasn’t
working.”

Share in the Risk of Trusting People

To create safety, it seemed some participants argued the project manager had to
take some risk as well. For example, Participant 10, who often worked with
distributed teams, explained,

You don’t get a sense of—I don’t mean to sound hippie—but, energy until
you are around [the team]. You get a sense of cool or not cool. You get a
sense when working with them too, and you get a sense of trusting people.
I think the big thing for me is that you trust them to (a) have your back,
and (b) not fuck up.

ICTs as Surveillance Can Erode Safety

Participant 12 explained how her team’s tool for project management replaced
a traditional project manager. From a functional standpoint, it seemed she
believed the tool worked well. On the other hand, it recorded everything that
was entered into the system in perpetuity. She was very careful about what she
added to the system. She explained, “there is very high visibility and accountability
for the tickets and who owns the ticket, who is the assignee, who is the reporter.”
As a result, if she were behind on her work, everyone on the team knew. The
team and organization had a culture of accountability, but it also seemed as if
the stakes were always high because of the systems general functionality.
92 Communicating Project Management

Use Feedback Loops

Participant 5 explained two main forms of feedback: the first

is more business-oriented. Does this conflict with anything or is there

something I should be aware of and the success of the project? Then there
is the second type of feedback, usually constructive feedback, lessons
learned, and that is done at the end [of the project].

Feedback also took the form of paying attention to how people were
participating and comparing it to previous experiences. Participant 5 discussed
noticing if people seemed distracted or not paying attention during meetings,
and then would follow up with an email or in-person conversation to see if all
was well. Participant 7 saw this form of feedback as a way to protect people. Her
way of paying attention was to measure progress during project meetings. She
explained, “So if I heard the same thing two or three weeks in a row, we would
stop and have a discussion about that.” Her reasoning was that

I wanted to hear problems on the horizon before they happened. If you

think the client is antsy about something, then I want to hear about it before
they are on the phone with me. That way, I can protect you. If I don’t know
what’s going on then I can’t protect you.

In this way, feedback could also lead to a sense of safety.

Seize Moments for Feedback

Participant 7 explained the importance of seizing opportunities to discuss
progress being made and give feedback as part of performance reviews. In this
instant, the “moment where both the manager and the worker ask ‘Are you
developing as we expect?’ ‘Are you developing as you expect?’ ‘And are we sup-
porting you as you hoped?’” For Participant 1, moments for feedback can be
produced serendipitously. He explained productive sessions are “walking the
hallways, going to someone’s cubicle, just saying ‘Hello,’ and having a more
personal conversation and just saying that they’re OK with everything.”

Create a Dependable Rhythm for Communication

When comparing Agile and Waterfall approaches, Participant 9 noted how the
rhythm of communication was different in the two methodologies. In Waterfall,
for example, “the communication typically comes from the project plan.” In
Agile, he explains communication as a conversation that happens at specific times,
such as daily Scrums. He believed that for teams, “You really rely on these more
informational conversations coming up, as opposed to formal communications.”
 Communicating to Make Space for Participation 93

The rhythm of project communication seemed to be an important way for

people to create safety, and this work was often done in participation with others
on the team. In some instances, as for Participant 12, the system at the center of
the work would manage the communication through automation, which assured
people when work was completed.

Use Kickoff Meetings to Normalize Communication Expectations

Participant 7 planned project communication early on in kickoff meetings. The
goal for the meeting was to work on norms and decide how and when the team
would meet. This session also helped to create expectations among people on
the team. She explained, “you established a rhythm for communication for that
project, which in these cases was rarely anybody’s primary work.” By creating
these norms for interacting, each member of the team had a blueprint of sorts
for what to look forward to in terms of the project, which would limit any
unnecessary surprises.

Factor 6: Development Methodologies

The project management methodologies participants discussed most were Agile,
Scrum, Lean, Six Sigma, and Waterfall. Each methodology was used for different
purposes and in varying contexts, but the overwhelming view was that none of
the methodologies were practiced as intended. That is, teams applied the
methodologies like a heuristic because that is what worked best for the team,
the organization, and the project. Also, the methodologies were often hybridized
with elements of each other. For example, teams practiced Lean and Scrum,
but did not work in clearly defined sprints. As described in Chapter 3, many
organizations and project teams did not feel compelled to adapt any methodology
as a template. In other words, methodologies were adapted in ways that helped
teams participate in collaborative efforts in productive ways. As well, the adapted
methodologies appeared useful for making teams more efficient as a result of
their ongoing collaboration. As a factor for making space, development method-
ologies provided more of a contextual and collaborative look at the social space
of project work. That is, the development methodologies could prescribe a range
of communication situations, such as Scrum, process improvement exercises, or
even activities like adapting methodologies and methods to a given organ-
izational, team, and project context.

Strategies for Communicating Within Development Methodologies

Efficiency Is Less Important than Impact

Participant 11 made an interesting observation about methodologies and
approaches to managing projects. In his interview, he argued, “It’s not about the
94 Communicating Project Management

efficiency of the project. Sometimes it’ll take twice as long to do something, but
if we are doing the right thing, it can have a huge impact on the business.” Rather,
he argued for an approach that focused more intently on businesses meeting their
goals and anticipated outcomes.

Adapt Methods to the Team or Organization

While Participant 9 felt the Scrums in his organization were very helpful, and
using them to support work “is something that I have really admired greatly in
the two companies that I worked at that use Agile.” He also explained it was
difficult to understand why the approach worked so well. He pointed to the
possibility that the success of Scrum could have been “the corporate culture, or
the culture of those teams, or something about the nature of Agile,” which he
believed produced a certain kind of honesty in teams. However, Participant 3
seemed to disagree that Scrum was effective, explaining she was one of the
people not really participating until someone asked for her report. Participant 9
did note during his interview that he believed the form of disengagement
Participant 3 described was possible.

Adapt Methodologies to the Team or Organization

Participant 2 described a scenario where approaches, like Scrum, were adapted
to the team. They called these meetings stand-ups, where “you have the
opportunity to say ‘oh, I am really struggling with this, does anyone know how
to solve this so I . . .’ that kind of thing.” As well, the team had turned to ICTs
to help support discussions about the project schedule. In addition, “some teams
will have weekly demos where they show off; ‘This is what I did for the week’ or
‘This is what I got done’ [and] ‘This is what we are planning on working for the
next week.’” In these scenarios, Participant 2 noted there are more “ad hoc in-
person conversations.” Participant 14 also explained that when his organization
began to experiment with Scrum, they chose to do so without hiring on a Scrum
Master to facilitate the sessions, but did put a development manager in place
to help fulfill that role. Participant 13 explained that adapting methodologies to
an organization is important because each organization is unique. He explained
that, “Kanban assumes that your work is same-sized.” In other words, the
methodology has to be adapted or it becomes more of a hindrance than a help.

Use Development Approaches to Influence Work, but Don’t

Apply Them as a Rule
While participants reported some philosophical separation between project
management and Agile (for example, Participant 14: “Sometimes project manage-
ment and Agile don’t always work”), a broad array of responses indicated the
 Communicating to Make Space for Participation 95

Agile was more of an influence than a strict methodology. Every participant knew
that it had changed the ways in which people work. Some spent time comparing
the differences between Agile and Waterfall, actually noting that using a Water-
fall approach was more appropriate for large companies. On the other hand, it
seemed Agile’s influence was pervasive. For example, Participant 7 explained, “To
me, Agile just showed up as a daily Scrum” and also explained, “I have seen design
studio influence as much as Agile.” Yet, as a way of working, there was also an
expectation that everyone was Agile. Participant 12 went so far as to say, “I think
you can’t be in this industry if you’re not [Agile].”

Address Methodological Confusion

What some of the participants referred to as purist arguments (methodologies
implemented exactly as they were conceived) it is more common to adapt them
to specific organizational contexts. Participant 14 said, “There is one thing that
you learn about [our organization] is that whatever method that exists out there
in the real world, we just don’t adopt the method, we always kind of do our own
thing.” Participant 5 also had a similar story about how there was a general attitude
that teams need to practice process improvement and Lean, but she felt the
application of Lean was lacking in her current organization. She explained that
“people use these key words and say that they are doing Lean,” but they are not.
Sometimes adaptation of methodologies surfaced because people felt confused
by what Agile actually comprised. Participant 2 summarized these conversations
by saying:

I always feel that my understanding of Agile is lacking, or that people

mean different things when they say it. For example, the company where
I am at, we say that we are Agile and we do things Agile, but then some
people say “Well no, we don’t really do Agile. Agile is this . . . or this . . .
or this . . .”

The conversation Participant 2 brought up was echoed by others in the study.

For example, Participant 4 pointed out a contradiction he’d seen:

We have a tendency to say that we are Agile, but then we also have a
tendency to have one shot at a feature or goal, and then are left with a list
of things that we wanted to accomplish or features that were either cut for
unknown reasons or just never got back to completing.

In other words, Participant 4 believed there was a disparity between Agile in

practice and Agile in theory. Addressing this confusion is important to how people
perform and engage in work.
96 Communicating Project Management

Be Strategically Agnostic
There were also accounts of agnostic Agile. That is, participants knew the
methodology had some benefits to offer, but did not, one way or the other, feel
tied to a specific way of being Agile. Participant 11 summed up his thinking this
way: “I’m agnostic. I believe in Agile methodologies, but I don’t subscribe to one
in particular.” The most common methods used to be Agile seemed to be Scrum
or stand-up meetings and working in sprints, although there were exceptions.
Participant 12, in particular, noted not having a specific process because if
something in the documentation was broken, the team would just go ahead and
fix it by resolving the ticket in the system. Participant 7 had a similar comment:
“They talk about Agile, and all that, but it doesn’t really affect my part of it. What
has changed by the way, isn’t so much that, it’s the number of Post-It notes that
appear in big team meetings.”

Remember Each Organization, Project, and Team Is Unique

Participants seemed to note that a major reason for all the adaptation and
hybridization of methodologies was due to the unique qualities of organizations,
projects, and teams. In short, not every one is the same. Because of this,
methodologies and methods seemed adapted to localized contexts. Participant
10, for example, explained that many of her projects are Agile, but some just don’t
fit the mold. She explained:

We do our stories, we have our backlogs, but we don’t do daily Scrums or

that kind of thing. Things take too long for that to make any sense. But
then there are also projects like last night where they wanted a website put
up in 18 hours, “Can you turn it on?” That’s a different kind of project—
break all the rules and get it done.

Participant 9 further made this argument by explaining, “That’s the problem

we have with most project management. We make an ill-informed scope of the
project, and we treat that like it is science.” Instead, project management has to
adapt to the situation.

Factor 7: Organizational and Team Culture

Finally, each organizational context influenced, to a large extent, how teams were
formulated and configured. For instance, in organizations with fewer than ten
employees, teams and teaming activities manifested differently than in organ-
izations with hundreds or thousands of employees. The organizations where my
participants had worked tended to organize around projects. As a factor, the
organizing quality of projects directly influenced the ways in which development
 Communicating to Make Space for Participation 97

teams participated in project work. This finding demonstrates that while every
project is unique, so is every organization. Understanding the shape of teams helps
project managers assemble a context for making space for people on the team.
Less frequently, teams were organized around products. In the data, project
managers did not note this sort of team configuration occurring all that
frequently. Participant 9 was the sole person to note,

Most of my project management involvement has typically been in IT

[information technology] kinds of environments, developing software—
part of the product development life cycle. Been involved in a couple of
ways sometimes as the documentation manager, whose job was to get the
documentation in parallel with the software.

Even so, a caveat was added that these teams were always coordinating
information across the organization with other teams to make sure everyone was
on the same page. As a constraint, participants situated organizational culture
as a large influence on their communication practices. Interestingly, organiza-
tional culture seemed to influence teams and project work, but participants noted
teams could have their own cultures inside of the organization. When describing
cultural influence on project work, participants believed it to be one of the most
central factors in how space is made for people. In some instances, the culture
of an organization was praised, and in others, criticized as problematic.

Strategies for Responding to Organizational and Team

Culture

Learn the Team’s Origin Story

When people participate across organizational networks and team orientations,
an important factor is how the team was formed. If the team has a history, then
that history is part of what they consider when making space for people and
communicating about project work. The results of interviews explained there was
a clear tilt toward project-based teams. As Participant 8 explained, “I have not
had a job that had a fixed team. It’s all been fluid and project-based.” An
emphasis on skillsets needed or as a value-add seemed to be important to team
makeup. The goal appeared to be to include a variety of skills to staff a given
project.

Contemplate Organizational Context

The strategies participants discussed about working with organizational context
focused on treating it as a kind of constraint of project work. Organizations come
in all shapes and sizes, which directly influences the need for how projects can
98 Communicating Project Management

be managed. Participant 2 explained, “The first company that I worked with out
of college was a very fixed team, but there were only nine people at the company,
so there wasn’t really a lot of change.” In larger organizations, Participant 7
explained more matrix-like formations were implemented.

Read Hierarchies of Influence

Participants noted the importance of looking for markers that demonstrate
organizational and team values. Doing so seemed to help teams develop their
own culture. Participant 2 believed, “there’s only so much you can do to subvert
that company culture.” These layers appeared to be at the individual, team, and
organizational level. Participant 2 believed each layer influenced the other, but
that there was also some room to resist bad leadership. There were conflicting
views of the power of hierarchy in the layers, however. For example, Participant
4 argued “bottom-up” approaches make people feel valued, especially from the
executive level. In contrast, top-down approaches often influence the ways teams
communicate with each other. Participant 3 made a similar comment, because
too often the person who makes the most money in the room decides how teams
will work together. Participant 2 made an interesting remark about the influence
of hierarchy, noting, “At the project level, I think that the person can only do so
much to . . . contradict the broader company culture.” In this way, hierarchies
of influence had an important impact on how space for participation was
perceived.

Work to Develop a Culture of Inclusion

Participant 9 described inclusion as “a culture of collegiality. Cultures that
reward smart failures.” In his view, these cultures helped eliminate toxic personal-
ities. In instances where organizations work to have conversations and solicit
feedback to support a more inclusive culture, there are still challenges to changing
culture. While Participant 9 believed toxic personalities could be addressed
through a healthy culture, Participant 2 seemed to believe that inclusion was more
complicated by that. He explained that at his current workplace there had been
a lot of discussions about encouraging more open communication, but that, at
times, individual experiences seemed to sabotage that effort. He asked pointed
questions during the interview: “Why do people come to meetings and sit there
and be quiet for the entire meeting, and then immediately after go find someone
and talk one-on-one and shut the door? Why are people not feeling like they
can necessarily speak out in meetings and having that watercooler culture?”
Participant 2 believed that part of the problem are the tacit messages sent about
organizational culture that can be elusive and are individually experienced (such
as shutting down contrary opinions or undermining people’s contribution).
 Communicating to Make Space for Participation 99

Remove Silos
Some participants discussed siloing, or compartmentalizing, as problematic for
making space for participation in project work. In these instances, teams were
not working in cross-functional ways. At times, participants believed that had
to do with national cultural identity traits. At other times it simply had to do
with issues related to territorialism. Participant 7 gives an example of one
manager, who was being left out of informal discussions about the project.
When she asked why, her coworkers explained that she was too hard to reach,
even though she was just one floor above in the same building. She concluded,
“it was really because it was a departmental lines thing, and they really didn’t
like that she was part of the team. And it was really more of a personality issue,
then a logistical issue.” Participant 7 did not necessarily think siloing was an
organizational culture problem, however, and likened it to cliques at work.
Addressing that sort of approach to working was important when assembling
teams. She explained, “I think that the most clever teams I have worked on that
were cross-siloes actually rearranged the seating.”

Implications for Making Space

Further Evidence of a Paradigm in Transition

The strategies and factors reported in this chapter provide compelling insight
into the transformation of project management from an efficiency paradigm to
one focused on participation. Evidence of the tension that exists between
efficiency models and participatory approaches can certainly be seen in the
interview results. For example, interviews demonstrated how project managers
worked very hard to include people from different cultural and linguistic
backgrounds on their teams by making space for their contribution. They also
worked hard to build relationships as a way for creating trust and learning how
to make the kind of space people need to be successful. And the conversations
about psychological safety most certainly identified the importance of participa-
tion on project teams as socially constructed, although individually experienced.
The strategies that the interviews uncovered frequently demonstrated how project
managers and leaders of development teams think very carefully about how teams
share experiences and work together.
This chapter also further clarified how communicating project management
is inherently spatial. Even though every communication strategy cited does not
necessarily result in the making of space, interviews demonstrate the importance
of space in communication. Thinking about making space or taking it away
from people in the context of development teams is a productive method
of communicating project management. In a participatory paradigm, space is
co-constructed with people. In an efficiency paradigm, space is experienced in
100 Communicating Project Management

different ways. Efficiency models do not always prioritize space for people in the
project. Time and again interviews showed this tension in interpersonal strategies,
particularly when teams would interact through meetings to support project work.
While some participants still argued that focusing on the project rather than
communication was key to success, others argued for the importance of the
social—even at the expense of productivity.

Making Space Is a Business Interest

Making space in the ways that the participants in this chapter suggested is also
a concern related to productivity and business interests. Many of the participants
argued that making space for people made for better teams and project outcomes.
Making space with people can actually lead to more productive interactions. The
strategies used were meant to build trust, relationships, and to improve individual
and team experiences in project work. The implicit argument was if project
management owned the progress of a project, then making space for participation
was often the most efficient way of advancing the work. Further, advancing
work—getting a project done well—is good for employees and for businesses.
Additionally, some of the results, especially those related to gender, were
disheartening and pointed to what others have argued are systemic gender-
stereotyping in the technology sector (see Sibley, 2016). While the generalizability
of the results in this chapter are limited to the participants I interviewed, I also
suspect that issues related to gender, like workplace bullying, are elusive and
challenging to distill for many people and organizations. Nonetheless, if making
space for people is essential under a participatory paradigm, then systems that
obfuscate issues related to gender, communication, and power must be further
investigated and understood. Doing this sort of work at the project level may
help teams and organizations make space inside the team, where subtleties and
implicit norms can be interrogated and addressed. In a participative paradigm
for project work, such issues must be socially encountered and addressed.

Agency as an Invitation
For the project managers and leaders I interviewed, agency manifested in the form
of an invitation to participate. The factors and strategies discussed during
interviews were used to shape how the invitation was delivered. That is, project
managers worked to find the appropriate invitation and did that communication
work through learning about individuals, teams, and organizations, and did this
work by engaging as a member of a community (see Blythe, 2006). When con-
sidering an organizational context, they would look to how the culture shaped
the work of people. On the other hand, if they knew specific people identified as
introverts, that they would have to find other avenues to extend the invitation
to participate. They worked within constraints presented by the individual and
 Communicating to Make Space for Participation 101

situation. In some instances, communication strategies were perhaps less

productive, although agency was still flexed. For instance, the strategies related
to gender showed unproductive stereotyping and silencing of women. In those
instances, women participants looked for other ways of participating in the
ongoing conversation about project work.
The intended goal of the invitation to participate seemed to be to distribute
agency across the team. In other words, the goal was to remain productive
through activities project managers have long practiced, such as negotiating buy-
in to a project approach or building trust. Such activities tend to generate positive
project outcomes and help minimize risk related to personnel and staffing. At
the same time, there was a distinct emphasis on making people feel comfortable
and working to create conditions that would locate agency inside of project teams.
This finding most clearly surfaced in the factor attending to psychological safety,
where project managers deliberately worked to make the team environment a
safe space. To do so, some of the participants explained they tried to share in the
risky proposition of trusting people to do their work or even to give members
of teams space to process information. In this way, some invitations to participate
were simply about making decisions about how to best respond to a situation as
it occurred.

Outcomes for Participatory Communication

At the end of Chapter 3, I described how project management communication
can be understood as having three overlapping characteristics. The interviews I
conducted help explain these characteristics and offer examples of them in more
depth in the form of strategies, specifically identifying ways in which they interact
and overlap. As a point of reference, participatory communication is intentional
and reactive, focused on future action, and systems-based.
Figure 3.1 offers a broad overview of how these factors fit together in the over-
lapping framework. As the figure demonstrates, communication flows back and
forth from individuals to the team, from the team to the organization, and from
the individual to the organization. The flow of communication is multidirectional.
In interviews, the factors personality type, gender, and cultural and linguistic
diversity seemed to have strategies that tended toward an intentional and/or
reactive response. Factors related to building and maintaining relationships and
attending to psychological safety seemed most closely aligned to the concept of
future action. Finally, the factors of development methodologies and organizatio-
nal and team culture seemed to most align with strategies that were systems-based.
These alignments are not fixed, by any means, but they do help to visualize how
the characteristics of a participative approach apply to communicating project
management in a flexible way. Further, it shows how the factors and strategies
interface with communication situations, demonstrating how agency arises out
of interactions between individuals, teams, and their organization, but also how
102 Communicating Project Management

FIGURE 3.1 Construction of Participative Communication with Factors

the delivery of the invitation to participate was structured as part of a broader

construct. In the following paragraphs, I further review how these characteristics
were connected in the interviews as a way for making space for participation.

Intentional and Reactive

In the factors cited, there are clear examples of intentional and reactive
communication when considering personality type. For example, reacting to
personality type often seemed useful for thinking about the best ways for
communicating with people in different social settings. Sometimes this meant
being self-aware of how people respond to a project manager’s personality. That
is, if you have a dry sense of humor, others may be confused and think you are
being sarcastic, so in the future a project manager tries to give more context about
a joke to avoid that confusion. At other times, it showed how role-playing games
can be used to make introverts more comfortable contributing to teams, with
the hope that the game would help introverts feel more comfortable in the team
atmosphere in the future. By being reactive to the existing communication
system, project managers could take action and make space when they saw
certain communication approaches were not working for people. In those
instances, the project manager might try talking less to give the team more space
in meetings or to give feedback in multiple ways to make space for growth in the
hope that it will lead to more participation in the future.
Gender seemed to influence implicit circumstances and perceived working
conditions. For example, some of the male participants noted that teams tended
 Communicating to Make Space for Participation 103

to be staffed by men, so they intentionally developed methods of building

relationships in that context. Seemingly in conversation, Participant 2 reacted to
similar team environments, and explained she actively made herself not gendered
to fit in over the long term. In this case, this was an intentional and reactive
response to her read of a situation. In this system, space existed for some, but
not for others. To make space, Participant 2 demonstrated a sort of rhetorical
resilience (see Flynn, Sotirin, & Brady, 2012) that helped her engage with the
system, because the system was not being adjusted to make space for her.
Participants often worked to make space for people from different cultural
or linguistic backgrounds. These conversations tended to focus on distributed
teams, but had several interesting insights to offer. For example, Participant 10,
despite her intentional efforts, could never seem to shake her team’s perception
of her as a New Yorker. Like Participant 2, her identity was seemingly pre-
programmed into a systemic view of New Yorkers, even when she tried to
demonstrate otherwise to change future interactions. Other participants saw that
some people less familiar with English felt more comfortable communicating by
writing out reports before meetings. The goal of changing these practices was to
make future reporting situations more comfortable and improve the system by
making space for people.

Future Action
In building and maintaining relationships there were similar examples of the
overlapping traits in practice. For example, some participants noted the
importance of telling certain people of changes ahead of time, likely a reaction
to a previous situation where someone was caught off-guard and responded
poorly. The goal of telling this person was to make the meeting where the rest
of the team learned about the changes more productive. In the example I’m
pointing to, Participant 8 knew that one person’s reaction unproductively
influenced how space was made for others on the team to process the changes,
so explaining the information to that one person was a better way to make space
for the group.
Participants directly worked to facilitate psychological safety by reacting to
issues that harmed trust and provided very little space for people. For example,
Participant 6 intentionally changed the structure of team meetings as a reaction
to failures that occurred in the past. The goal of changing meeting structures was
to make the team more comfortable in the future and a more productive system
as a result. Others noted the importance of feedback, and so making space for
that kind of interaction was both intentional and reactive to the needs of the
team and the project. The goal of these interactions was to build trust for the
future and improve the system.
104 Communicating Project Management

Systems-Based
When considering the role of development methodologies in making space for
people, there are several examples of the overlapping traits. For instance, project
managers and leaders intentionally worked with organizations to adapt
methodologies, making ongoing changes to the use of meeting spaces like Scrum,
to suit the project and team needs. The goal was to improve team processes and
make a better system for managing projects in the future. Participants also noted
the purity debates about methodologies, specifically about the differences between
practice and theory. This is further evidence of teams and organizations reacting
to methodologies in ways that support process improvement.
Finally, the consideration of organizational and team culture was equally
pervasive as the other considerations. In some of the interviews, participants felt
that organizational culture could weigh heavily on team culture, so it was import-
ant to understand how hierarchy influences the ways in which teams can
communicate. For example, Participant 12 worked on a distributed team where
everything put into the project management system was stored in perpetuity.
Understanding such dynamics influenced what she would write into the system
because she was concerned about how it might be seen in the future. The system,
in this instance, had a direct influence over how she communicated. In other
examples, the role of siloing across a system affected how teams would interact
with people in different departments. By working to remove silos, development
teams could improve communication and find spaces to support collaboration
and achieve improved project outcomes.

Conclusion
In this chapter I explained the results of interviews in the context of making space
for participation. While not every important social factor surfaced during
interviews (for instance, ageism, accessibility, or discrimination related to sexual-
ity or gender identity were not discussed), the interviews did provide a foundation
for considering social factories in communicating project management. The
discussion offered in this chapter shows that making space manifests in several
ways that sheds light on how people, through interaction, exercise agency and
participate on development teams. It also raises a question about how individual
project managers approach making space from a systematic standpoint. In other
words, do project managers follow a prescriptive set of rules to make space? Or
is their application of a participatory approach to communicating intuitive to
their experience managing development projects?
In the next chapter, I demonstrate two models of leadership, and how
leadership values influence the way people approach communicating project
management. To explain these models, I use two metaphors about how to best
assemble and lead development teams. The first metaphor is gardening and the
 Communicating to Make Space for Participation 105

second is cooking. In using these metaphors, I am deliberately trying to explain

that different leadership mental models influence how space is made for people
on project teams. If this chapter showed the factors and strategies project
managers consider when making space for people, then the next chapter demon-
strates how they perceive communicating in-the-moment, and how their own
approach influences the ways they consider each factor. Finally, as the accounts
offered by the participants in the next chapter will also demonstrate, there is no
single approach for extending an invitation to participate, but there are individual
philosophies that influence how the invitation is shaped.

Notes
1 For additional direction as to how I approached data analysis early on as the book
developed, a more explicit example is available in the Journal of Organizational
Knowledge Communication (Lauren, 2017).
2 See Berkun (2008) for a discussion of project management titles and job activities. Note,
however, that the conceptualization of project manager varies by organization and field.
A construction project manager has a different role than a development team project
manager. Also, recall from the first chapter that when I refer to project manager, I
am broadly addressing project management activities. As such, a broad array of
participants provided a better look at project management communication.
3 I want to highlight that I chose to embed information communication technologies
into each factor, rather than make it a factor of its own. There are two reasons for this.
The first and more important reason is that information communication technologies
were rarely discussed out of context during the interviews. That is, they were always
brought up alongside one of the factors listed below (for example, if Person A is this
way, I would not email them, which I would code as personality type). The second
reason is that habits of use produced information that was not all that interesting other
than noting a generalized widespread adoption. In other words, everyone used
information communication technologies as part of their work. What I did find notable
is that most participants preferred face-to-face communication when it was possible.
The general consensus was information communication technologies still cannot
replace face-to-face communication.
4 As a caveat to this statement, I would also like to acknowledge that as a white male,
some of my participants may have felt uncomfortable discussing gender issues
with me.

References
Amidon, S., & Blythe, S. (2008). Wrestling with proteus: Tales of communication managers
in a changing economy. Journal of Business and Technical Communication, 22(1), 5–37.
Aristotle (1994). Physica. (R. P. Hardie, and R. K. Gaye, Trans.). Retrieved from http://
classics.mit.edu/Aristotle/physics.html (Original work published in 350 BCE).
Berkun, S. (2008). Making things happen: Mastering project management. Sebastopol, CA:
O’Reilly Media.
Blitefield, J. (2000). Kairos and the rhetorical place. In F. J. Antczak, C. Coggons, and G.
D. Klinger (Eds.), Professing rhetoric: Selected papers from the 2000 Rhetoric Society of
America conference (pp. 69–76). Mahwah, NJ: Lawrence Erlbaum Associates.
106 Communicating Project Management

Blythe, S. (2006). Agencies, ecologies, and the mundane artifacts in our midst. In P.
Takayoshi & P. Sullivan (Eds.), Labor, writing technologies, and the shaping of
composition in the academy (pp. 167–186). Cresskill, NJ: Hampton.
Corbin, J. M., & Strauss, A. L. (2008). Basics of qualitative research: Techniques and procedures
for developing grounded theory (3rd ed.). Los Angeles, CA: Sage Publications, Inc.
Drucker, P. F. (2009). Management as a social function and liberal art. The essential Drucker:
Selections from the management works of Peter F. Drucker [Kindle version]. Retrieved
from Amazon.com.
Edmondson, A. (1999). Psychological safety and learning behavior in work teams.
Administrative Science Quarterly, 44(2), 350–383.
Flynn, E. A., Sotirin, P. J., & Brady, A. P. (2012). Feminist rhetorical resilience. Logan, UT:
Utah State University Press.
Gaonkar, D. (1993). The idea of rhetoric in the rhetoric of science. Southern
Communication Journal, 58(4): 258–295.
Geisler, C. (2004). How ought we to understand the concept of rhetorical agency? Report
from the ARS. Rhetoric Society Quarterly, 34(3), 9–17.
Grabill, J. T., & Pigg, S. (2012). Messy rhetoric: Identity performance as rhetorical agency
in online public forums. Rhetoric Society Quarterly, 42(2), 99–119.
Hewlett, S. A., Marshall, M., & Sherbin, L. (2013). How diversity can drive innovation.
Harvard Business Review. Retrieved from https://hbr.org/2013/12/how-diversity-can-
drive-innovation.
Kelly, D. (2012). Forward. Make space: How to set the stage for creative collaboration. Institute
of Design at Stanford University
Lauren, B. (2017). Experience sampling as a method for studying in situ organizational
communication. Journal of Organizational Knowledge Communication, 3(1), 63–79.
Miller, C.C., & Rampell, C. (2013). Yahoo orders home workers back to the office. New
York Times. Retrieved from www.nytimes.com/2013/02/26/technology/yahoo-orders-
home-workers-back-to-the-office.html.
Peeples, T. (2003). Professional writers produce social space. In T. Peeples, (Ed.),
Professional writing and rhetoric: Readings from the field. London: Longman.
Phillips, K. W. (2014). How diversity makes us smarter. Scientific American. Retrieved from
www.scientificamerican.com/article/how-diversity-makes-us-smarter.
Potts, L. (2014). Social media in disaster response: How experience architects can build for
participation. New York, NY: Taylor & Francis.
Rainie, H., & Wellman, B. (2014). Networked: The new social operating system, Cambridge,
MA: MIT Press.
Shirky, C. (2010). Cognitive surplus: How technology makes consumers into collaborators.
New York, NY: Penguin Group.
Sibley, S. S. (2016). Why do so many women who study engineering leave the field? Harvard
Business Review. Retrieved from https://hbr.org/2016/08/why-do-so-many-women-
who-study-engineering-leave-the-field.
Simmons, W. M., & Grabill, J. T. (2007). Toward a civic rhetoric for technologically and
scientifically complex places: Invention, performance, and participation. College
Composition and Communication, 58(3), 419–448.
Spinuzzi, C. (2012). Working alone together: Coworking as emergent collaborative activity.
Journal of Business and Technical Communication, 26(4), 399–441.
Swarts, J., & Kim, L. (2009). Guest editors’ introduction: New technological spaces.
Technical Communication Quarterly, 18(3), 211–223.
 Communicating to Make Space for Participation 107

Turner, H. N., Nguyen, M., Keller, B., Sackey, D. J., Ridolfo, J., Pigg, S., . . . Grabill, J. (2017).
WIDE research center as an incubator for graduate student experience. Journal of
Technical Writing and Communication, 47(2), 130–150.
Willerton, R. (2015). Plain language and ethical action: A dialogic approach to technical
content in the 21st century. New York, NY: Taylor & Francis.
4
ON SITE WITH THE GARDENER
AND THE CHEF
Project Leadership and Communication

Agriculture isn’t entirely controllable. You enrich the soil, you plant seeds, you
water according to the latest theory, and you hold your breath. You just might
get a crop; you might not.
(Demarco & Lister, 1999, p.143)

But just as a chef with excellent experience uses the guidance of good cookbooks
and recipes to create consistently delicious meals, an experienced project
manager needs to use industry standard processes [. . .] as a cookbook to help
reproduce consistently effective PM results.”
(Lammers & Tsvetkov, 2008, n.p.)

I’ve come across two metaphors used to describe leadership philosophy at the
project team level. The first, offered by Demarco and Lister (1999), suggests that
teams can be grown, but not built. This leadership approach describes project
managers who cultivate the conditions for teams to succeed as a member of a
team. The second approach was described by Lammers and Tsvetkov (2008), and
it positioned project managers as chefs because they must deliver successful project
results consistently. The chef, they argue, uses “industry standard processes” to
achieve these results. Chefs tend to have a more complicated power relationship
with the team, as they are very clearly responsible for managing its processes and
procedures. Leadership models in project management offer important insight
into communication practices. This chapter explores leadership at the project
level by embodying the two metaphors of gardening and cooking to understand
how these leadership values influence approach to communicating. Through a
closer examination of two participants, this chapter explains how leadership values
influence communication at the project level, and to what extent they shape
invitations to participate in project work.
 On Site with The Gardener and The Chef 109

To study the relationship between leadership and communication, the chapter

leans heavily on examining the communication of two participants who were
previously introduced in Chapter 3 as Participant 3 and Participant 8. To ensure
clarity, I’ve identified the same pseudonyms here. In this chapter, however,
Participant 3 is “The Gardener” because she tends to communicate in ways that
focus on growing and cultivating the growth of people to help a team succeed.
Meanwhile, I refer to Participant 8 as “The Chef” because he tends to focus on
making and assembling a recipe for success, usually through industry standard
practices and the kinds of resources and people needed to successfully complete
a project. As the chapter will explain, their individual positionality on the team
also influenced how they performed leadership. Given these metaphors, how each
participant approaches communicating project management is very different, even
though they work toward the same goals: to complete project work successfully
and to make space for people to participate.
This chapter begins by reviewing the literature on leadership in project man-
agement. It continues with a discussion of experience sampling as a method for
data collection and analysis techniques. Then the chapter introduces The
Gardener and presents the data from our work together, which illustrates her
approach to growing and contributing to project teams. After this, The Chef is
introduced and I explain how his approach to communicating focused on
following proven recipes for success. Next, the chapter explores how their
leadership approaches are linked to specific ways of communicating; how they
give presence to certain values. Finally, the chapter ends describing the role of
leadership identity as a form of rhetorical performance.

Communicating Leadership, Positionality, and Identity

As a scholarly interest and workplace practice, leadership contains a broad range
of topic areas. For example, there are a number of books that focus on how to
best lead (such as Asghar, 2014; Maxwell, 2007) or attempt to teach students
to be effective leaders (Northouse, 2015; Kouzes & Posner, 2017). Often the
published work in leadership traverses academic and practitioner spheres.
Particularly useful is Higgs’s (2003) work, which assembled a trajectory of
leadership research in a Western tradition, including the trends and schools
of thought emerging since the ancient Greeks. In his article, he argued that
scholarship in leadership tends struggle with its paradigm, oscillating between a
focus on personality or behavior (p. 274). A focus on leadership personality asserts,
for example, the importance of an individual’s character and charisma; whereas
a focus on behavior is concerned with how leadership can be developed as a
skillset. Higgs (2003, p. 274) explained, “A personality-based paradigm would
argue for selection as being the main focus, whereas a behaviour-based one would
argue for development. In essence this is the debate around whether leaders are
born or made.” This chapter seeks to add to this conversation to argue that
110 Communicating Project Management

leadership at the project level is a kind of rhetorical performance that is based

on a set of implicit values that shape communication activities.
In this view of leadership, communicating project management is both
situational and contextual, but also reliant on the positionality of the project
manager in the group. When a team shares in project management work, the
positionality is different than when a person is hired to exclusively act as a project
manager. As Amidon and Blythe (2008, p. 21) learned from interviewing
communication managers, “Those who reveal a situated, contingent notion of
agency [. . .] understand that their ability to act often comes not from autonomy
but from their position within a larger group.” In other words, positionality of
the project manager influences how they lead, and also, how they perform their
identity as a leader. While Amidon and Blythe (2008) are quick to dispel the notion
that identity is fixed, they also understand it to be situated in the workplace and
linked to personal and professional experiences (such as education and training).
Similarly, in their study of the online forum Science Buzz, Grabill and Pigg
(2012, p. 116) explained, “identity is often synonymous with authority due to
their ongoing presence in the conversation, their rhetorical skill, and their status
in relation to the site.” In other words, in online forums identity is performed
“in small, momentary, and fleeting acts” and is leveraged to “create argumentative
space by shaping how the conversation unfolds and enables the exchange of
information and knowledge” (p. 101). In comparable ways, project managers,
via organizational networks, enact agency by shaping conversations and activities
to create a space for project work to get done using analog and digital means
(that is, using information communication technologies and during face-to-face
meetings). A project manager’s agency is awarded through interactions, through
building relationships and trust via such communication activities.
When leadership is expressed as a kind of performance of identity and
positionality, it becomes clearer that leadership arises out of rhetorical situations
that circle project work. To help illustrate this idea, I turn to Biesecker (1989),
who explained “the rhetorical situation as an event that makes possible the
production of identities and social relations” (p. 126). Her treatment of the
rhetorical situation suggests that leadership identities are not fixed—that “the
rhetorical event may be seen as an incident that produces and reproduces
the identities of subjects and constructs and reconstructs linkages between them”
(p. 126). Through these linkages, people build relationships and trust as they work
on projects. In other words, by assuming our leadership identity is not fixed—
that it is constantly in a state of transformation—rhetorical events or incidents
can be transformative to how someone perceives their role as a leader. Biesecker’s
(1989) ideas connect with Drucker’s (2009) thoughts that the most powerful
way of communicating as a manager is tied to shared experience. It is through
communicating—through designing approaches to making space—that
leadership is performed. Consequently, it is also through communicating that
the values of a leader are exposed.
 On Site with The Gardener and The Chef 111

Capturing Leadership Communication with Experience

Sampling
To study the leadership values of project managers, I used a form of diary study
to capture self-reported communication events at work. Specifically, I used what
is termed Event-Contingent Reporting (ECR), which tracks information imme-
diately after specific events (e.g., write down how you feel five minutes after aerobic
exercise). Diary studies are used to examine the workplace by a range of
scholars—from disciplines such as psychology, anthropology, and professional
and technical communication (see Hart-Davidson, 2007). Work by Bolger and
Laurenceau (2013) refer to experience sampling as an intensive longitudinal
method, which “allow[s] researchers to study the relationships within and
between everyday behaviors, activities, and perceptions” (p. 12). As a method,
experience sampling is particularly useful for revealing an individual’s perception
and reaction to communication events with a clear beginning and end (see
Moskowitz & Sadikaj, 2012).

Data Collection Methods

To participate in the ECR protocol, I sought participants who were currently
working as project managers or leaders in an intentional manner. My goal was
to learn about their values as communicators and how these were tied to their
leadership mental models. After approval by my institution’s institutional review
board, I recruited two participants and worked with them over a period of
approximately four weeks using an ECR approach. Purposefully, I was not
looking to recruit a large group of participants because I wanted to look more
deeply into how leadership influenced approaches to communication, and the
corresponding values and beliefs that surfaced.
To begin the reporting period, participants were given a coaching script that
defined each reporting event in depth. Each participant was also asked to fill out
a report immediately after the defined event occurred for a period of one week.
The reporting form we used was initially piloted by each participant with a goal
of being able to fill out and submit the report in approximately 90 seconds
(following the advice of Hart-Davidson, 2007).
Additionally, before the reporting period commenced, I spoke with both
participants about the process. We talked over the reporting form, but also dis-
cussed piloting the form. After working with the form for one day, I followed
up with participants to learn if there were any usability issues. Discussing the
process of submitting the reporting form became a regular part of weekly
interactions with participants. For instance, both participants noted at one point
feeling bad because they had not done a thorough job of sampling experiences
that week. We were able to discuss any missing data during weekly interviews,
stimulating recall from the missing events and documenting important
experiences with the audio-recorded interview.
112 Communicating Project Management

At the end of the reporting period, I asked each participant to sketch a mental
model of their communication around project work. The mental model was a
useful artifact for better understanding their approach to communication.
Fairhurst and Sarr give a useful rationale for this approach:

Leaders who understand their world can explain their world. That is the
principle that makes mental models important to communication. Mental
models of how the world works (or is supposed to work) help us to size
up situations and formulate goals for communicating.
(Fairhurst & Sarr, 1996, p. 23)

In this way, the mental models each participant produced helped to illustrate
their perception of project communication, and how their leadership values were
enacted into a response to the rhetorical situation.

Data Analysis Methods

Upon completion of data collection, each interview was transcribed and
assembled into communication events. Then, data was assembled into compo-
nent parts of each situation, answering questions like who? What? When? Where?
How? And why? As well, I assembled what was submitted in each of the reporting
forms into diagrams using the same elements. While each filed report was meant
to capture a single communication event, I sometimes had to adjust the approach
to consider duration of time and when an event occurred. For example, one event
could take 1–2 minutes while the next might last 60 minutes. I treated longer
communication events the same as shorter events. In instances where some of
the information regarding a communication event was missing, I used interview
data to fill in any missing or confusing context.

Introducing The Gardener

As the first epigraph for this chapter indicates, project managers who lead as
gardeners are cultivating conditions for teams to grow together as individuals
and as a collective. They do this work positioned inside the team—as an equal
member of the team. When DeMarco and Lister (1999) discussed the agricultural
metaphor in Peopleware, they were reflecting on their own struggle to develop a
prescriptive approach to creating what they called a “jelled”1 team. As they
wrestled with how to best make teams jell, they concluded:

You can’t make teams jell. You can hope they will jell; you can cross your
fingers; you can act to improve the odds of jelling—but you can’t make it
happen. The process is much too fragile to be controlled.
(Demarco & Lister, 1999, p. 143)
 On Site with The Gardener and The Chef 113

As they asked what could be done to create the circumstances teams needed
to jell, the authors noted they needed to change their terminology. “We stopped
talking about building teams, and talked instead of growing them” (p. 143,
emphasis in original). As it turns out, the metaphor of gardening is also not new
to professional and technical communication either.2 The gardening leadership
model for project management values team-building and developing people, and
as a result, a gardener approach is more appropriate for shared control over
leadership and internal processes. In a cultivation model, project management
is treated as a more democratic process that requires frequent input from people
on the team.
When the research for this chapter began, The Gardener had just started a
new job at an automotive company designing infotainment experiences. Her title
was Senior User Experience Designer. When I asked how she was involved in
managing or leading project work, she explained how she did so from inside the
team:

Here at my new position we don’t have project managers specifically

[. . .] I like things to be really well defined and scheduled and I like to plan
and I like being able to do that as much as I want with my own parts of
the project.

She did qualify this statement with an important point that she was not the
team lead, although she had an informal role in how the work of her team was
done.3 She explained how she participated in project management:

Some of the stuff that I do naturally like scheduling things, and laying out
timelines, or taking more detailed notes. I have been sharing that
somewhat—almost to get a sense of how much other people appreciate it
and if other people find it helpful.

Given that The Gardener was new to the company and team, her approach
made sense because she was looking for ways to add value to her surroundings.
She wanted to fit in, but also make an impact inside of the organization. She
explained one way she was adding value to project work—which had influenced
how it was being managed—was building a shared calendar. She felt that by
creating timelines in this calendar, she could help other people on the team see
the dependencies of the project. She explained the team had previously used a
slideshow template, but that it wasn’t visible enough. She translated that
information into something she felt was more effective and thought,

hey, I can do it in this way and I can share it with them and if it’s appreci-
ated then I can kind of manage that piece of things or it can be adopted
by everybody and then we can all kind of manage that piece.
114 Communicating Project Management

In the end, she explained that the team adopted her approach to scheduling
and making dependencies visible.
The Gardener described the approach to project management at her company
was Waterfall, but with some Agile elements practiced only by her team. This
structure made sense because The Gardener worked for an automotive company,
and much of her team’s work had to do with people’s experience in the car—
perhaps the most flexible space of an automobile. The Gardener explained, “we
do design thinking as an approach to problem solving, and there have been
discussions with my team in particular about trying to incorporate some of the
methods of those methodologies,” such as a Kanban Board. To potentially help
facilitate some of this transition, The Gardener practiced using a Kanban Board
to guide her own work, but did not introduce it as a collaboration tool with her
team during data collection.

Leadership Values of The Gardener

The communication I observed via experience sampling were events like
negotiating buy-in to project timelines, defining scope of a user interface,
beginning a community-based project, assembling a team presentation, and
discussing design outcomes. These communicative events did not define The
Gardener, but they did illustrate her values as a leader: to cultivate the conditions
that would lead her team to individual and collective growth. That is, for her
team to “jell,” to use DeMarco and Lister’s term. And she approached that work
positioned as an equal member of her team, taking the lead where and when it
made sense for her to do so. Importantly, participating in this way was intuitive
for her because it aligned with her personality, but it was also a reaction to her
situation as a new employee and to her perception of the organization as a context
for project work. Further, the data showed there were clear communication
practices associated with the values of The Gardener as a leader. I describe the
values here and provide examples from the communication events she reported.
While these values are not all encompassing of gardeners as leaders, they
demonstrate how one person inhabits the role in the ways she communicates
with people on project teams.

Value 1: Teach Methods of Effective Collaboration

The Gardener frequently mentioned the importance of modeling behavior or
teaching others how to effectively collaborate on her team and those surrounding
her team in the organization. For her, modeling desirable behavior was an
instructional act, which she did by demonstrating specific kinds of action and
occasionally embracing inaction to construct effective boundaries. She further
explained during an interview that “I am a firm believer in that you teach people
how to treat you.” Several reporting events demonstrated The Gardener working
 On Site with The Gardener and The Chef 115

to teach people how to treat her or how she hoped her behavior would influence
others. For example, she reported receiving an email request about a feature of
a product from a coworker who had authority over her in the organization’s
hierarchy. The email asked her to immediately give feedback to a proposal. The
Gardener felt the request was unreasonable, and responded she would get to it
soon as she could, but did not make promises about when that would be. Since
her response was written as an email, she used a polite and diplomatic tone, but
remained firm that she did not have the time to get to this specific request at the
moment. Her thought about responding in this way was “I didn’t want to teach
him that he could get me to react by communicating in that way.”
Another example manifested itself for The Gardener during an informal chat
session with a new person at her organization. The event occurred because the
new person was working to understand how to use the scheduling system, and
felt confused by it. During the event, the new employee instant-messaged with
The Gardener, who clarified how to use the system. In this example, The Gardener
used this opportunity to express her value of modeling behavior. By helping this
person, even though it wasn’t a part of her job, The Gardener was modeling the
kind of flexible and informal communication she wanted to see in others within
the organization. Further, The Gardener believed this communicative act could
potentially develop a rapport that seemed to be missing in the group. She said,
“I got this sense that there’s not a lot of proactive sharing here,” although she
also acknowledged she did not believe it was about “hoarding information” either.
By spending time walking this new person through the scheduling system she
explained:

There’s no reason that I should be spending my time doing it other than

I felt the pain myself and it’s almost like challenging that culture a little
bit. I don’t want other people to feel the pain of that.

The Gardener was working to grow the knowledge of a teammate, while also
making visible the kind of interactions she hoped others would adopt on the team.
She described her motivation also as a way to support future action when/if others
needed to access the scheduling system: “when she asked me for help I thought,
‘Man, I should really go in here and update all this and pull it together—like
update this page—so that the next person can have something to go towards.’”
Of the situation, she concluded, “there are things that I can have some control
and influence over in terms of culture and that’s how I communicate with other
people and how I teach people how to communicate with me.”

Value 2: Learn About Teams and Organizations

A focus on learning about her team and organization also proved important as
a means for understanding how to navigate, engage, and lead as a member of
116 Communicating Project Management

her team. The audience of a communication is The Gardener’s essential con-

sideration in how she communicates as a leader. Supporting learning about the
audience was her background as a user experience professional. She noted that
learning about customers had always been a high priority for her, but more
recently had turned that training toward learning about the people on her team.
For example, during one of our interviews, she noted that the timing of project
work seemed more relaxed at this company than at other places she’d worked,
which would require some adjustment for her. Timing of work significantly
mattered to The Gardener, and her efforts at learning about the organization
helped her think about ways to improve how her team approached project
dependencies. She explained it in this way:

I could really manage a lot more than I am right now, but I know I don’t
know everything I need to know to understand where the boundaries are.
So, I’m kind of backseating a little bit just to see how things play out—to
get a sense of the culture.

Examples of learning surfaced throughout the sampling period in many

situations. In one, The Gardener overheard a group of people discussing a
project team she knew something about, so she popped her head up from her
cubicle to offer some information to the group. The group turned and looked
at her as if they were surprised, and did not say anything. She read their individual
facial expressions and body language and sat back down feeling somewhat
dejected. Her goal was to build rapport with the people in the group, but learned
from the interaction that even conversations in common spaces in this
organization could be somewhat exclusive.
Not just because of this situation, but because of her interest in learning, one
of The Gardener’s main learning strategies was to ask a lot of questions. These
questions were based on genuine curiosity and appeared to support her belief
about the interrelationship between audience, organizational culture, and
leadership. For example, during a meeting she once asked how decisions were
made in her organization. She felt compelled to learn about how decision-
making in the organization functioned and wanted to share that information with
others who had asked about it. Her goal for asking the question was to improve
transparency about decision-making. She explained:

This could be a gender thing—I’m still making first impressions and I don’t
want to come in and give people the impression that I’m going to railroad
people or take over all the work or just be a difficult personality or anything
like that.

Since her design team had scheduled a meeting in a private room at work,
she chose this moment to ask a question about organizational hierarchy. Rather
 On Site with The Gardener and The Chef 117

than continue with the meeting as planned, the group spent a great deal of time
discussing organizational hierarchy and explained how it influenced decision-
making at her company. When reflecting on what she learned in that moment,
The Gardener once again noted how her organization treated the timing and
dependencies of project work as more open-ended from previous places she’d
worked, and she found flexible deadlines somewhat disorienting.

Value 3: Communicate to Include

A clear leadership value of The Gardener was to communicate in ways that
included people. In the previous sections, we saw how she enacted inclusion by
teaching effective collaboration, modeling behavior, and prioritizing learning
about her team and their context to intentionally find areas where she could lead
from within her team. She operationalized these motives to be inclusive of the
people on her team, and to find ways to make space for people to participate.
She explained how her goal of inclusion played out in different kinds of
communication events at work. For example, she once sent an email to her
supervisor notifying him that she’d be off-site at a training. The email was meant
to be purely informational, but she also chose an email on purpose to protect
her supervisor’s time. She felt a more formal face-to-face discussion would have
been disrespectful of her supervisor’s time for such a simple notice. In The
Gardener’s view, there were formal and informal methods she used to
communicate to include. She defined informal methods as strategies she indi-
vidually developed and adopted and were perhaps less visible to people. She
explained informal as pertaining to her individual practices, such as “making sure
that everybody has a say and can be heard as part of the collaboration process
or our team meetings,” or circling back to those she’d mistakenly interrupted
“so that it didn’t feel like any one person was dominating the conversation or
the design process.” Meanwhile, formal strategies had been developed and
adopted by the team (e.g., developing a communication plan or workflow) and
as a result were more visible. She explained formal methods as “really making
an effort to communicate how I think that we should share ideas in terms of
providing rationale and more detail around why we’re making certain decisions
throughout the design process.”
In another example, The Gardener discussed a team meeting that focused on
presenting designs and getting feedback from team and project stakeholders. She
felt that her team meetings, especially focused on design critique, contained a
cultural representation of social rules and team norms. In this example, the tenor
of the meeting was in part influenced by how The Gardener participated in and
facilitated the meeting with her team. She felt quite attuned to making sure the
feedback sessions were inclusive, and during our interview she openly wondered
if the informal and formal approaches she used were more or less her projection
of a desirable social order or communication ideal. She ultimately settled on the
118 Communicating Project Management

idea that she wanted the team to understand there was an “expectation we
should have of each other when we’re coming to the table with something [for
feedback].” In this case, she relied a great deal on modeling that inclusive
behavior for people, and in this particular example, hoped that her informal
strategies would cultivate more formal inclusive practices across the team.

Value 4: Be Responsible to the Team

As the examples so far have shown, The Gardener intuitively communicated and
acted in ways that demonstrated a loyalty to her team over the project. This loyalty
was rooted in the belief that effective teams lead to successful project work. Project
work was high priority for the Gardener, but in the social spaces of work, she
often prioritized the team over the project. When an individual would break from
the team, The Gardener felt as though it violated some sort of unspoken rule
that required explanation. The emphasis on being responsible to the team was
also about making sure people were contributing and collaborating in good faith.
One example from a community project she’d worked on showed how The
Gardener viewed the importance of celebrating individuals in the context of teams.
The Gardener was part of a group of people who were working to resurrect a
chapter of a local professional’s association. To honor one of the senior people
on the team, she advocated for creating an emeritus role to keep the person
engaged and give them an opportunity to participate with the group.
Another event The Gardener reported was working on what she called a design-
a-thon. She explained the situation as:

I was with the same group of people over the course of two days and it was
essentially figuring out how to work together, how to attack a problem,
and then what space in which to do that from a cadence perspective given
what we had to accomplish.

By “cadence perspective,” she meant how quickly the team would need to
collaborate. She could tell, based on the reaction of people in the room, that there
was some resentment surfacing across the group. A person on the team seemed
disengaged and disinterested in the work. The Gardener could sense the tension,
so she brought it up to the team during the meeting after the collaborator
unexpectedly walked out and did not come back. People on the team were
feeling as if the person had dishonored an unspoken rule and team norm. The
Gardener saw this as a moment for learning and took note of how the context
of the situation was influencing the group. She said, “I feel like I’m always
thinking about context. I think [about] choosing how to conduct my work,
whether that’s actually designing something or whether that’s collaborating with
people.” The Gardener believed, had this person felt more responsible to the team,
 On Site with The Gardener and The Chef 119

he would have explained why he left the session and did not come back. Without
additional explanation, the team did not know if there was an emergency or if
he was upset with how the collaboration was going, and was left to assume the
worst.

Value 5: Empathize with People

Building from the previous examples, one of the most important leadership values
for The Gardener was to empathize with people. She saw it both as a strength
and weakness of her leadership. At one point she explained, “I probably practice
a little too much empathy. I feel like I let people get away with things in a
productivity sense a lot more than I should.” Later, she further explained the
importance of balance: “There’s a balance between empathizing with others and
setting them up for success—however that plays out—and then balancing that
with your own needs.” She had been taken advantage of before because of her
ability to empathize with people on her team. Empathy was important to The
Gardener’s leadership philosophy because she believed it helped put others into
a position to succeed. One way this surfaced in her communicative activities was
in the importance of withholding judgment in the face of uncertainty or
ambiguity. She described moments where she had asked her team to try new or
unfamiliar ways of working as a means for facilitating growth. In this way, she
needed people on her team to empathize with her as well.
The Gardener gave several examples where she’d empathized with people at
work. She reported one meeting that was called for a project that was stalled and
had fallen behind schedule. She empathized with the prototyping team lead, who
was overworked and had fallen behind. She asked if he needed more time to work
to take the pressure off of him. By empathizing with the prototyping team lead,
she helped to get the project back on track. Her empathy led to a schedule change.
True to The Gardener’s leadership values, she was also teaching her team how
she would want them to communicate and interact with her should the same
circumstance arise. In this example, we can see how The Gardener’s practice to
empathize also intersects with each of her other motives as a leader and as a team-
mate.

A Mind Map of Communicating from The Gardener

I asked The Gardener to develop a mind map of her communication practices
as a reflection tool for our final interview. Figure 4.1 is her visualization. The
Gardener’s mind map shows her communication practices are inherently
rhetorical as she communicates as a member of her team. Her focus is specifically
on the team, which is a primary concern of a gardener leadership strategy.
During our final interview she explained her development of the mind map in
120 Communicating Project Management

this way: “I started with audience, essentially, because that’s what determines how
I communicate with people. So, I kind of tried to lay it out by some of the
significant groups that I work with most often.” Each strand is thusly organized
by the audience. As we follow the flow of each strand of her mental model we
eventually arrive at her depiction of situation, which directly influences how she
perceives herself as a communicator. An underlying theme across her mind map
is the importance of collaboration and working together.
Moments of collaboration appeared to be where and when The Gardener felt
most comfortable asserting herself as a leader. These were moments where she
could engage in practices like teaching people how to communicate, modeling
desirable behavior, and learning about the people on her team. Her sampling
reports showed she focused a great deal of energy empathizing with the people
she collaborated with during meetings. As a result, she looked for more
opportunities to collaborate because she felt it allowed her to add value to the
work of the team. She also pointed out that meetings often influenced cultural
or logistical factors, which means that the frequency of many meetings are out
of her control. Thus, she had to find and choose specific moments to lead. She
felt there were social forces at work in meetings, and that is also why these settings
proved so important to be inclusive rather than exclusive in terms of communi-
cation. How her leadership surfaced in communication activities had to be
timely—woven into the fabric of the team in predictable and unpredictable ways.
As a result, she perceived leadership as situational and reactive to context, which
was one reason she emphasized being responsible to the team. Honoring the social
rules and norms of teams was closely contributed to the production of psy-
chological safety.
Overall, the most important thing about The Gardener’s mind map was
that her leadership mental model contained specific communicative practices that
relied heavily on her perception of the different audiences she encountered at
work, as well as her position in those groups. These practices helped her to cultivate
effective team environments and behaviors by empathizing with people on the
team as they worked together. Jointly, the experience sampling and mind map
suggested The Gardener tended to lead by emphasizing people over the project
without diminishing the importance of getting work done. To invite participation,
she started with considering communication factors and strategies that related
to people on her projects.
The Gardener’s focus on people is important as a descriptive feature of her
leadership mental model. When we compare that with The Chef in the next
section, we see that he tends to focus on the project over the people. While he
certainly does not minimize the impact or importance of people, his mental model
tends to position him to make space for participation in the system used to manage
project work, especially in terms of coordinating workflow and dependencies.
The people that inhabit that system tend to be secondary in his value system.
 Can range from design collaboration and
feedback gathering to social chit chat; doesn’t
Informally
occur as often as I would like
F2F
Design direction decision making, feedback
discussions, requirements gathering. Feels less
Scheduled Meetings
collaborative

Used for document sharing or straight-forward

questions; often followed up with informal F2F Work Project Teammates
Email
communication

Quick questions, urgent messages Chat

Mostly used for document sharing and calendar

event sharing (vacations, project milestones).
Everyone hates it, but it’s the prescribed
Sharepoint
collaboration tool
Video Chat

Phone Call

Chat
Mostly project-oriented Community Teammates
communication of questions about Twitter
Informally
larger departmental concerns
Email
F2F
Gather feedback on job performance, ask My Communication
questions or have discussions about how we Slack
Scheduled Meetings Manager
work, and status updates

Mostly for FYI and CYA messages Email

Only for urgent questions of FYI messages Chat

Occasional duck-in chats for quick

Informally
questions or FYI’s

F2F This seems to be where the bulk of

communications occurs; the penchant for
meetings is often cultural, sometimes
Scheduled Meetings
Work Stakeholders logistical

Often used for confirmation of decision

Email
making or other CYA scenarios

Chat Often only for a quick FYI’s or feedback

FIGURE 4.1 Mind Map of The Gardener’s Communicative Strategies

122 Communicating Project Management

Introducing The Chef

Chefs, as the second epigraph suggests, purposefully assemble industry standards
to consistently create a tasty mix of the resources and people needed to help a
project succeed. In the article the second epigraph comes from, Lammers and
Tsvetkov (2008) discussed the 80/20 rule of project management, which broadly
focuses on maximizing return on investment.4 When they turned to the metaphor
of cooking in the article, they refer directly to the Project Management Institute
as a “cookbook” of industry standard practices. These practices are formalized
into a body of knowledge that can be used in different organizations to deliver
effective results. That is, a chef can bring their cooking skills in just about any
kitchen. As well, chefs generally have training (The Chef in this chapter is
certified as a Six Sigma Black Belt). In a cooking model, the project manager tends
to emphasize the importance of the project over individuals. If gardeners tend
to work from within the team, then chefs are the opposite, working more
deliberately as a de facto team organizer. As well, chefs deliberately work to develop
and curate the management system teams use to stay organized, and some chefs
will do that work with the team.
During the sampling period, The Chef was working as a consultant for an
organization that worked in healthcare. He was specifically brought in to help
the organization solve problems that had boiled over and had created a lot of
tension across the team. He described the department he worked for in the
organization as experiencing a huge influx of work that they were struggling to
manage. He explained it this way: “they’re trying to shift away from just reacting
to all of the inflow of work that’s coming in towards being prevention-oriented.”
His role was to help coach the team to become more productive and to simul-
taneously help them limit the amount of work going into their area. As he reflected
on his role, he talked about how a lot of the work he’d done in healthcare was
complex. Most of the complications arose from healthcare being viewed as a
business, and The Chef believed too many companies would often write-off work
instead of filing claims (and making money). Additionally, The Chef was
positioned as a contractor the organization hired to help address business
problems from a project management standpoint. He told me that the problems
had been developing over several years and were neglected for so long, and he
identified the unfortunate result: the team had developed many bad habits that
would have to be reversed.
When I asked The Chef about the kind of project management methodologies
used by the organization, he noted that it was elusive and did not really fit a
traditional definition of Waterfall, Agile, or Lean. He said that the issue for the
project he was managing is that there was literally no system in place. He
explained, “even the concept of Waterfall and talking about flow just is not even
part of the lexicon.” The group had worked with the rest of the company to buy
a project management technology solution to help centralize communication and
 On Site with The Gardener and The Chef 123

create awareness of the intersection across all the different departments, but the
adoption of that system was more about creating an improved customer experi-
ence across business units. He noted his role was partially to help address this
issue: “this is me coming in after the fact and telling you my impression of it
—a combination of company culture along with the product that they bought.”
During the research, The Chef focused intently on the social aspects of
communicating in a high-tension environment that was focused on making
productive change. He worked to invite participation across several layers of the
organizational network—from executive management to individuals on his
team.

Leadership Values of The Chef

Given this context, the communication that I observed during the reporting period
with The Chef focused on developing a system for managing project work. There
were meetings with individuals, teams, and at the executive level where issues
related to organizational and team culture clashed and made it challenging for
him to do his work as their project manager. At the same time, there were clear
tensions across project managers in other areas of the company regarding how
to solve these problems (or even agreeing on what the problems constituted).
Working through these issues was challenging for The Chef because he felt that
the organizational issues made it near impossible for him to do the job as he
wanted to do it and believed it needed to be done, and it also clashed directly
with how he understood the role of a project manager. The Chef wanted to develop
a system with the team that would be useful for them moving forward, and
encouraged senior leadership to participate in that process by outlining clear goals
and outcomes to support his efforts.

Value 1: Keep People on Task

An important value for The Chef was to keep people on task, particularly during
meetings. To support this motive, he frequently acted in ways that would help
make each meeting as productive as possible. He devoted a great deal of time
preparing for meetings and learning from previous mistakes. Too often he felt
blindsided by people’s reaction to information he had prepared and presented.
At one point, he told a story about a past experience where this happened with
a Vice-President. In preparation for that meeting he asked around how meetings
with this person tend to go. He asked what kinds of reports the Vice-President
wanted to see. The Chef explained this approach as “I try to come up with a sort
of hypothesis of what’s driving them and then I actually test it during inter-
actions.” He noted a variety of strategies he used to keep people productive,
most of them driven by reflecting about people’s personalities and about his own
124 Communicating Project Management

mistakes working with teams in the past. He called this approach “loss avoid-
ance,” where you avoid losing productivity or harming a relationship because of
a preparation error. In this way, The Chef put a lot of pressure on his own personal
performance to deliver successful projects.
To provide another example, during a phone meeting, two people on the line
derailed the meeting agenda by engaging in a pop-up conversation. He explained,
“I could feel the cyclical nature of this conversation and not feeling like it was
progressing. And only two people were talking.” His purpose for communicating
was to get the meeting back on a productive track, so he acted by asking the two
people to follow-up with each other after the meeting. He noted that no one
seemed offended by him requesting the two to follow-up after the call, and that
he even heard a few laughs. He also reflected that this wasn’t the first time he’d
asked this specific group to stay on task, and that in previous meetings he’d
wadded up a piece of paper and jokingly threw it in someone’s direction to get
them to focus. As a result, he communicated his leadership value to the team
that staying on task is important, but worked to do so in an inclusive, good-
humored way.

Value 2: Assign Roles to Individuals and Teams

The chef also believed in the importance of everyone playing their role on the
team, which included him as project manager. Of his role, he said, “I am exactly
in the middle of everything because I own nothing except the progress of the
project.” He would use several communication practices to show people that
sticking to their assigned role was important to the success of the project. For
example, he would arrange meetings, send follow-up emails, and embrace
serendipitous check-ins to make sure people were aligned with the project. In
these moments, The Chef would remind his team of the importance of roles in
terms of the goal for the project. In reflecting on this during one of our interviews,
he noted encouraging executive leadership to give a clearer charge to the team
as it would make implementing a system a far more productive process.
In one situation he reported, The Chef discussed a common act: writing an
email. The purpose of this particular email was to ask someone for feedback on
a deliverable. He believed talking to this person directly and putting them on the
spot to give feedback would be an uncomfortable conversation, so he decided
an email would likely make this particular person more comfortable and the
interaction more productive. In this example, the purpose of requesting feedback
was transformed by the low-stakes and low-urgency request of the email. In our
discussion, he reflected on how this request face-to-face might have produced
an awkward conversation because it demanded immediate feedback, which
would have been problematic for this particular person, whom he believed was
already flustered. He felt his role as project manager was to make sure interactions
with people were not wasteful and would not harm relationships. In his view,
 On Site with The Gardener and The Chef 125

interactions ought to be about building trust. In another example, he explained

that productive conversations were often about knowing your role. He explained
this idea in the context of his role as project manager: “I’m responsible for making
sure this conversation finishes. Meanwhile, a VP is the person whose conversation
it is, and someone else is responsible for doing all of the heavy lifting so that I
can facilitate the conversation.” The Chef believed everyone had a role to play,
and this belief guided how he engaged people in project work.

Value 3: Communicate to Clarify the Goal

In addition to keeping people on task and assigning roles, The Chef
communicated in ways that would clarify project-related issues. For The Chef,
clarifying information was as much about productivity as it was about not
surprising people or catching someone off-guard. In moments where there was
communication bottlenecks, The Chef moved quickly to remove the roadblock
to get people back to work on the project. Sometimes these issues were
interpersonal in nature, and at other times they had to do with clarifying the goal
of the project for people on the team. He believed that in this particular
organization, a lack of clarity about the team’s role was a deeply embedded issue
that he continually needed to overcome to help the team be successful.
In one example, The Chef reported on a meeting with an internal stakeholder
about how his team had behaved in a meeting where he was not present. The
purpose of the meeting was to resolve her frustration and to make an action plan
for avoiding similar behavior from the team in the future. Apparently, his team
had been disengaged. People were late to the meeting and spent most of their
time distracted by laptops and other devices. As a result, The Chef listened to
and acknowledged this person’s feelings about the meeting. The act of
acknowledging the frustration helped him learn how to address the lack of
engagement. The Chef was able to develop a solution and the internal stakeholder
trusted him to do so. To communicate and clarify expectations for his team, he
explained to the stakeholder he would create a list of ground rules for the team
to honor, which included using the fruit bowl technique, where everyone was
required to turn over their devices at the beginning of the meeting to ensure they
were present and participating.

Value 4: Be Responsible to the Project

One of the major values of The Chef was to continue productivity toward the
goal of a project in his actions and interactions with people. He would spend
time investigating and learning about the existing project as a system to discover
any issues that could easily be fixed. His training in Six Sigma certainly helped
in this respect and he noted the importance of process improvement during our
interviews. And, since The Chef was also trained in user experience, he had a
126 Communicating Project Management

strong sense of how touchpoints in a management system could influence how

people participated in project work. To get a view of these touchpoints, he
would engage with people across different units to learn how information was
coordinated. His goal for doing this work was to make sure people were honoring
deadlines and understanding the dependencies of project work. He explained of
his coworkers in different departments and of his teams, “You need them to
understand for the business to do things, a deadline has to be a deadline. As in
the line that you are dead if you do not cross.”
In one report, The Chef emphasized the importance of deadlines and project
dependencies by reviewing the goal with people on his team individually. He felt
that by reviewing the goal of the project and hyper-communicating, it would lead
to more productivity and honoring deadlines. As noted earlier, The Chef
perceived talking in person as more urgent, so when he arranged face-to-face
conversations, he hoped to communicate timely and important requests. He
explained the method he commonly used to set up these meetings like so:

[I] set a goal for the team to reach by next Friday, in order to make our
work sync up with other efforts in the system. I first sent out an email
yesterday, and today I followed up with each person individually to
reinforce and make sure they understood the goal and purpose.

He felt this approach could help make people more productive. In this way,
The Chef enacted his view that the team needed to be responsible to the project
in order to produce successful outcomes.

Value 5: Empathize to Motivate Action

The Chef confessed he had a very difficult time with the concept of empathy.
Not intellectually, but ethically. He felt that since his application of empathy was
to make progress and motivate action—that because it was goal-oriented—it
somehow was less genuine. That said, The Chef did employ empathy as a
leadership value, but his aim was to make progress on the project. He seemed
to believe any emotional output that did not lead to productivity was bad for
the project—and anything bad for the project was bad for the team. He also felt
discussing emotions and people at work was dangerous. The Chef would almost
always rather discuss the system of managing work, and would tolerate feelings
if it led to action. The system, in his view, was safe to talk about. In regard to
empathy, he concluded that, “If you want my opinion you’ve got to put an action
on it.” This view makes sense given The Chef’s interest in evaluating productivity
and metrics in general. The importance of measuring success directly correlated
with his training in Six Sigma.
In one report, a coworker came to him to discuss “sensitive issues.” The Chef
felt the purpose of the meeting was to help her to solve a problem, which was
 On Site with The Gardener and The Chef 127

ultimately good for the project and for the team. He acted by engaging in a
discussion about the situation of his coworker, as she worked through feelings
about someone she felt was directly rejecting her authority. The Chef perceived
his role as offering a “because?” As in, this person has frustrated me, and his role
was to ask her why. When I asked him to reflect on the situation in our interview,
The Chef said, “The two metrics results and retentions—everything else falls into
those.” In other words, “if she wants to get action on this, [the outcome] needs
to be linked to results or retention.” So, his application of empathy was strategic
and action-oriented. He certainly felt conflicted by his use of empathy because
during our interview he explained, “I still in my mind link empathy with some
sort of action that is showing support for the feelings, but I do think it is
important in order to get things done. It is important to acknowledge that
people’s feelings are a valid source of data.” In other words, The Chef perceived
empathy as a useful way to act if it motivated action that benefited the project
in some way.

A Mind Map of Communicating from The Chef

As with The Gardener, after the sampling period ended I asked The Chef to
develop a mind map of his communication processes and approaches as a
reflection tool for our final interview. Figure 4.2 is his visualization of his
communication practices. The Chef’s mind map shows how his communication
activities were often based on the existing relationships he had with someone.
Each strand of the mind map is focused on two areas that he placed in order of
importance. The first in that order is “the goal,” which The Chef explained as
something that was the central focus of his work as a project manager. He
explained, “I’m always starting with the goal. Part of this is ‘what do I see as my
function?’ And my function, as I understand it, is to achieve a goal.” The Chef
had important reasoning here in terms of his role as a leader and how it
influenced the ways in which he communicated project management. He
explained:

I try to stay focused on the goal when I’m communicating because this is
kind of that safe space to talk about the system; to talk about the goal rather
than what someone is doing. Because in my experience I’m not going to
get much traction talking to someone about what they are or are not doing.

As a point of emphasis, The Chef’s conceptualization of “safe space” was related

to the system that the team used to manage project work. In his estimation, it
was safer to talk about that system than address a person’s emotions or feelings.
We can see examples of this in his values as a leader. For example, keeping people
on task or empathizing to elicit action both demonstrate his understanding of
safe space. For The Chef, emotions at work felt too unpredictable and were difficult
128 Communicating Project Management

FIGURE 4.2 Mind Map of Communicating from The Chef

to quantify in terms of productivity. Instead, he advocated for people to play

specific roles and be responsible to the project.
The second area The Chef’s mind map addressed was the “person,” which he
admitted was a secondary consideration for him as opposed to the goal of the
project. With people, he clearly thought in terms of building and maintaining
relationships for future action. Following the strands of the mind map, it becomes
clear that his communication practices seek to be more intentional than reactive.
The Chef did not care for surprises, which is why his approach to communication
focused on predictability of the outcome of an interaction. If there was an
uncertain response, he might email someone to prepare them ahead of time,
especially in the case that the news affected their job or their part of a project.
For this reason, The Chef embraced communicating to clarify the goal of the
project. He had learned from experience that surprising people never goes well,
and often led to a lack of productivity in meetings (i.e., more talking and less
measurable action). Instead, The Chef wanted to find avenues for enhancing
productivity when possible. As a leader, The Chef communicated to make space
for participation by maximizing opportunities for people to play a role in the
management of a project as a system.

Comparing Communication Values of The Gardener and

The Chef
So far we’ve seen how The Gardener and The Chef embody two different leader-
ship identities in the context of project management. Their values are important
to acknowledge because they demonstrate how being a gardener or a chef influ-
ences project management communication and how they perceive making
space for people to participate. The Gardener focuses on her audience first and
the project second, whereas The Chef focuses on the project first and then the
audience. Both believe in encouraging participation, but The Gardener is
positioned to cultivate it from within her team by communicating her values to
 On Site with The Gardener and The Chef 129

TABLE 4.1 Comparing the Values of The Gardener and The Chef

The Gardener’s Values The Chef’s Values

Teach methods of effective collaboration Keep people on task

Learn about teams and organizations Assign roles to individuals and teams
Communicate to include Communicate to clarify the goal
Be responsible to the team Be responsible to the project
Empathize with people Empathize to motivate action

people. Meanwhile, The Chef took a different role of making space by focusing
on creating and iterating a management system for the project to succeed, which
would ultimately benefit the team and the business.
Table 4.1 is a comparison of the values discovered across the two leadership
profiles in this chapter. I present these values not to position one approach against
the other as more or less desirable, but to demonstrate how values influence how
leaders communicate. I placed each of the elements in relation to each other to
make comparisons easier to make.
The unique positionality of The Gardener and The Chef also demonstrate
an important aspect of their leadership values and agency as project managers.
That is, The Gardener also acted in specific ways because of her role on the team.
The situation and context helped to determine how she perceived this role. At
the same time, The Chef was brought in as a consultant because of his train-
ing and experience. His role was to act as a chef. From what we’ve learned from
The Gardener and The Chef, leadership communication can be understood
as a rhetorical performance that builds from the project manager’s positionality
and is refined through interactions with the team and extensions of the team.
Leadership values are linked to the rhetorical context and situation. Further-
more, a leader’s identity is not fixed, but its value-centric identity is constantly
shifting. The Gardener and The Chef show how leadership identity is formed
and reformed through rhetorical performance. In other words, leadership identity
can be formed through interaction and participation, but an individual’s values
are far more reliant on other factors, such as training, education, and other pro-
fessional experiences. These values are sense-making guideposts for The Gardener
and The Chef, and help them shape approaches to communication.

Leadership Identity as Rhetorical Performance

If the communication practices of project managers under a participatory para-
digm focus on making space for people, then what we learn from The Gardener
and The Chef is that leadership philosophy influences how space is or is not being
made through communication. Leadership as a practice is rhetorical because, to
be effective, it requires consideration of context, situation, and positionality before
acting. We can also understand these considerations by extending the concept
130 Communicating Project Management

of terministic screens. Herrick (2009) described terministic screens as “any set

of terms used to describe an object, event, or person simultaneously directs
attention toward some factors and away from others” (p. 228, emphasis in
original). For example, the language The Gardener and The Chef used to describe
communication events was key in revealing how they perceived the event. For
example, The Gardener described the “pain” she felt for someone else as she
worked to access the scheduling system. Using the term “pain” signaled her value
of empathizing with people on the team. Meanwhile, The Chef described a
meeting as “running rampant” demonstrating his value of keeping teams on task.
Leadership values, in essence, also help illustrate the philosophies underlying
choices made about communicating. Both The Gardener and The Chef hope to
extend invitations to participate, but their values help to determine what sort of
participation they find productive.
However, just as development methodologies should not be applied as a
template over people, leadership values are not implemented devoid of situation
and context. The language used to describe the communication events can
only help illuminate what someone is paying attention to at a given moment—
what they perceive in that moment as most important. For example, let’s turn
back to an example with The Gardener. She noted that a new coworker instant-
messaged her about accessing the team’s scheduling system. The Gardener
stopped what she was doing and saw an opportunity to model the kind of inter-
action she wanted to see occur more often across the team. The Chef, we can
speculate, might have identified there was a problem with the system and tried
to work with this person to isolate the problem to improve it. The Gardener and
The Chef may have experienced the same moment, but turned their attention
to different aspects of that situation, producing different outcomes. The reason
that leadership approach matters so much at the project level is because it can
produce these different kinds of outcomes. As Drucker (2009, p. 268) said,
“Leadership is a means. Leadership to what ends is the crucial question.”
Suffice to say, the communication events discussed in this chapter also suggest
that a project manager’s leadership philosophy seems shaped quite a bit by their
positionality in the group. These factors appear far more implicit. That is, what
is charismatic in one context appears brutish or crude in another. Prescriptive
leadership approaches decline to acknowledge the role of the social in enacting
leadership at the project level. While the case in this chapter suggests an alignment
across individual personalities, beliefs, and values, it also emphasizes the rhetoric-
ally responsive nature of leadership as informed by situation and embedded in
context. Simply put, The Gardener inhabited the role of a gardener on her team
because she was hired in that role. In addition, her personality tended toward
sowing seeds and helping them grow. The same goes for The Chef. He was
contracted by an organization to come in and cook. So that is what he did.
In the context of this chapter, the production of identities and social relations
is important because it helps to further illustrate the effects of a paradigm shift
 On Site with The Gardener and The Chef 131

from efficiency to participation. That is, the identities, or knowledge, of

individuals and teams are not fixed. As such, communicating for participation
also means making space for growth, what Biesecker calls “radical possibility.”
Project teams that approach communication events as identity-forming can still
focus on exigence, such as discussing a disagreement about a new feature of a
mobile application. However, what Biesecker’s argument suggests is that
leadership is socially coordinated through and by participation of the team.
Communication on teams is transformative. So much of the knowledge-work
today focuses on individual and collective learning, either through structures
unique to a project, like a project retrospective, or through professional develop-
ment activities, such as certification or training. When leadership works as a means
of facilitating this participation, project managers have to make space for people
because leadership values can give space to certain ideas while, perhaps unknow-
ingly, limiting space for others. In this way, leadership values at the project level
can also be a constraining construct, giving presence to certain concerns and
behaviors while diminishing or potentially silencing others.

Conclusion
In this chapter we learned about two prevailing metaphors for describing
leadership in project management. To illustrate these metaphors, we met The
Gardener and The Chef and learned about their experiences communicating at
work. The cases demonstrated two leadership models and uncovered their asso-
ciated values for communicating. These leadership approaches also demonstrated
how space for participation can be constructed according to different mental
models. The implementation of participative approaches to communicating are,
in a way, constrained by the leadership values of a project manager. Furthermore,
the chapter discussed how agency is enacted through the positionality of a project
manager on a team, which is also reinforced and modified through interactions
with the team and other stakeholders. The chapter ended with a brief discussion
of how leadership identity is also linked to social factors, and can be influenced
by communication events focused on project work.
So far in this book, we have isolated individuals’ experiences and views to learn
about communicating project management. In the next chapter, we will turn our
attention to a team working through a large change management effort that had
a significant impact on project work. Broadly speaking, the team was making a
transition to a participatory paradigm for project work by changing what they
developed and how they developed it. We will learn about how the team
communicates and participates in the change process, and what disruptions
surfaced during the reorganization that negatively impacted their productivity.
As the final case study in this book, Chapter 5 provides an important social view
of communication and participation in project management.
132 Communicating Project Management

Notes
1 In Chapter 1, I briefly mention jelling as a concept for team formation, specifically in
the context of being a musician. DeMarco and Lister (1999) describe them as having
a few qualities: “low turn-over” (p. 136); “a strong sense of identity” (p. 136); “a sense
of eliteness” (p. 136); “a feeling of joint ownership over the product being built by the
jelled team” (p. 137, emphasis in original); and, a sense of “obvious enjoyment”
(p. 137).
2 Bill Hart-Davidson (2001) used the work of Bonnie Nardi and Vicky O’Day (1999) to
suggest that technical communicators are also well-suited to act as gardeners on IT
development teams.
3 Leading parts of projects and initiatives is something we saw reflected in the interviews
in Chapter 4 because some products involve multiple project teams. We will also see
a similar situation in the team that makes up Chapter 6.
4 The 80/20 rule suggests project managers spend 20% of their time on project
management activities that will lead to an 80% return on investment in the future.

References
Amidon, S., & Blythe, S. (2008). Wrestling with proteus: Tales of communication managers
in a changing economy. Journal of Business and Technical Communication, 22(1), 5–37.
Asghar, R. (2014). Leadership is hell: How to manage well—and escape with your soul. Los
Angeles, CA: Figueroa Press.
Biesecker, B. A. (1989). Rethinking the rhetorical situation from within the thematic of
“différance.” Philosophy & Rhetoric, 22(2), 110–130.
Bolger, N., & Laurenceau, J. (2013). Intensive longitudinal methods: An introduction to diary
and experience sampling. New York, NY: Guilford Press.
Demarco, T., & Lister T. (1999). Peopleware (2nd ed.). New York, NY: Dorset House
Publishing Company, Inc.
Drucker, P. F. (2009). The essential Drucker: The best of sixty years of Peter Drucker’s essential
writing on management [Kindle version]. Retrieved from Amazon.com.
Fairhurst, G. T., & Sarr, R. A. (1996). The art of framing: Managing the language of leadership.
San Fransisco, CA: Jossey-Bass Inc.
Grabill, J. T., & Pigg, S. (2012). Messy rhetoric: Identity performance as rhetorical agency
in online public forums. Rhetoric Society Quarterly, 42(2), 99–119.
Hart-Davidson, W. (2001). On writing, technical communication, and information
technology: The core competencies of technical communication. Technical
Communication, 48(2), 145–155.
Hart-Davidson, W. (2007). Researching the activity of writing: Time-use diaries, mobile
technologies, and video screen capture. Studying the mediated action of composing with
time-use diaries. In H. McKee, & D. DeVoss (Eds.), Digital writing research:
Technologies, methodologies, and ethical issues (pp. 153–169). Cresskill, NJ: Hampton
Press.
Herrick, J. A. (2009). The history and theory of rhetoric: An introduction. Boston, MA:
Pearson.
Higgs, M. (2003). How can we make sense of leadership in the 21st century? Leadership
& Organization Development Journal, 24(5), 273–284.
Kouzes, J. M., & Posner, B. Z. (2017). The leadership challenge (6th ed.). Hoboken, NJ: John
Wiley and Sons.
 On Site with The Gardener and The Chef 133

Lammers, M. & Tsvetkov, N. (2008). More with less: The 80/20 rule of PM. TC World.
Retrieved from www.tcworld.info/e-magazine/content-strategies/article/more-with-
less-the-8020-rule-of-pm.
Maxwell, J. C. (2007). The 21 irrefutable laws of leadership workbook: Follow them and people
will follow you (revised and updated 10th anniversary ed.). Nashville, TN: Thomas
Nelson.
Moskowitz, D. S., & Sadikaj, G. (2012). Event-contingent recording. In M. R. Mehl and
T. S. Conner (Eds.), Handbook of research methods for studying daily life (pp. 160–175).
New York, NY: The Guilford Press.
Northouse, P. G. (2015). Leadership: Theory and practice (7th ed.). Thousand Oaks: Sage
Publications.
5
MANAGING A REORGANIZATION
PROJECT AT DTI
Participation and Making Space for
Communicating Change

Too often, change communication is entirely top-down.

(Suchan, 2006, p. 30)

Stories help us negotiate between those factors that restrict and limit our
possibilities and our free ability to pursue our own choices.
(Faber, 2002, p. 25)

Workplace change can be an exciting, nerve-wracking time for employees. A

change, such as a reorganization, can represent productive movement toward a
new structure that could truly be transformative. And yet, workplace change is
also so constant in today’s technology companies that it is often treated skeptically
or dismissively by employees. Teammates are shuffled, job titles revised,
department lines redrawn. Indeed, change at work is a constant force. As Jim
Suchan explained in the first epigraph of this chapter, how change is managed
and communicated is important to its outcome. Without participation of
employees, change processes are more likely to fail. For the team that this
chapter is based on, a reorganization of their department proved promising
to some and frustrating for others. Before the reorganization, or “the reorg,” as
several participants called it, the team’s work had been focused on writing
technical documentation largely for customers. To facilitate their work, they had
established a stable workflow managed by an automated system that assigned and
resolved tasks. The reorganization was, in part, about rethinking what the team
produced and how they produced it. No longer would they rely on automated
tasks. Instead, the team would be learning and implementing more participatory
approaches to designing multimedia content that focused on collaborating with
customers and colleagues in other departments at the organization. The team
 Managing a Reorganization Project at DTI 135

was now responsible for developing customer experiences that “inspired delight,”
to quote one of the participants in the chapter.
Technical and Professional Communication as a field has documented similar
organizational and structural changes in its scholarship on content strategy and
user experience. For example, the shift in how the team at DTI was working
might have been thought of as the organization “coming to content management”
(Hart-Davidson, Bernhardt, McLeod, Rife, & Grabill, 2008). That is, the organ-
ization had begun to see content as knowledge assets, and the delivery of content
as representative of customer experience and the public perception of its
products. Inevitably, the participants in the study understood that their role in
the organization was rapidly evolving, repositioning them as central to building
positive customer experiences—a development process that could not be
automated. The problem from my view was the team didn’t fully understand
why this change was needed. Also, some of my participants did not appear to
know when and how the changes would occur. While upper management
had made clear that the change would be good for DTI and for each person on
the team, the rollout of the reorganization was incremental, so each person
on the team experienced the reorg at a different time. In other words, their agency
to participate in the reorganization as a team was constrained by the system
designed to implement it. Furthermore, management implemented the change
rollout without involving employees in the process, leaving them little space to
shape the system..
As a point of clarity, reorganizations such as the one depicted herein can be
understood as a kind of project. This chapter considers what disrupts participative
approaches during reorganization projects by discussing the communication of
the information development team at DTI during the early stages of the process.
At the center of this discussion are the circumstances the team faced when
struggling with the changes presented to them. The reorg as described so far might
have been popular with employees as it created opportunities to participate in
project work in cutting-edge and even career-defining ways. Yet, by the time I
began visiting people on the team at work, there was a sense of anxiety and
paranoia weighing heavy around the office. As this chapter illustrates, one reason
for the discomfort surrounding the change appeared to be a central contradiction:
the organization wanted to use more participatory approaches to collaborate with
customers, but instituted that change without involving employees in the con-
versations about how to implement these new ways of working. In short, it was
a top-down effort. Because employees had not participated in conversations about
the change process, and also because of an unfortunate series of events—like the
departure of their manager and the arrival of a new, unfamiliar manager—
psychological safety on the team had been eroded.
This chapter explains how lack of space in participation can influence
organizational change projects. To do so, the chapter explains the organizational
change project and situation at DTI, providing an analysis of the team’s
136 Communicating Project Management

communication activities throughout the process. On a larger level, this analysis

illustrates how members of the team invented spaces to respond to disruptions
in their work. Additionally, the activity analysis helps to highlight a central
contradiction that surfaced in the data: the reorganization changed the rules for
engaging in project work without also addressing issues with the division of labor
and tools needed to implement these changes. At the end of the chapter, I
explain how this case study illustrates the ways in which participation and
communication function in stable, albeit nonlinear ways.

Organizational Change and Project Management

Traditionally project management and change management are considered
independent workplace practices. That is, change management projects are
treated differently than other projects in organizations. Some scholars have
called on this lack of integration to change, arguing that project implementation
and success are undoubtedly affected by organizational change efforts. Hornstein
(2014), for example, argued that new project managers should be trained in change
management methods if teams are to be successful. In Hornstein’s view, project
managers must specifically engage with the social and psychological elements of
addressing organizational change because projects are often used as instruments
of change.
This view also reflects what Suchan (2006) outlined regarding the need for
effective communication frameworks to help people manage change in
organizations. It can be challenging for workers to change, and most change efforts
fail. Thusly, Suchan (2006, p. 42) recommended managers start a dialogue with
workers to examine “cognitive underpinnings, assess them, and begin the
construction of different or more robust individual interpretive schemes linked
with strategy and goals.” No doubt, with recent descriptions of today’s organiza-
tions as networked and decentralized entities (Brafman & Beckstrom, 2006;
Rainie & Wellman, 2014; Spinuzzi, 2015) that continuously expand into emerging
economic and talent markets, the need to manage all the change we experience
at work seems practical. But, as Hornstein (2014) also observed, thinking about
managing change at the project level is still a relatively new idea.
Prominent views on organizational change tend to focus on two theories:
Theory E and Theory O. Theory E “emphasizes economic value—as measured
only by shareholder returns” (Beer & Nohria, 2011, p. 138, emphasis in original).
During a Theory E change initiative, the organization “boosts returns through
economic incentives, drastic layoffs, and restructuring” (Beer & Nohria, 2011,
p. 138). Theory O seems to offer a more people-focused approach, which “focuses
on developing corporate culture and human capability, patiently building trust
and emotional commitment to the company through teamwork and communica-
tion” (Beer & Nohria, 2011, p. 141). It seemed DTI, as Beer and Nohria (2011)
noted most companies do, was trying to implement a change strategy that
 Managing a Reorganization Project at DTI 137

oscillated between or combined Theory E and Theory O. To implement the new

working strategies forwarded by the reorganization, DTI appeared to take a careful,
incremental approach, providing workshops on design thinking and giving
people some choice over the kinds of project work that interested them. What
DTI did not appear to account for in their process was to involve employees in
their change process. In other words, there seemed to be few opportunities for
the kind of dialogue Suchan called for.

Organizational Change as an Activity

To study the team’s interactions and communication during the reorg, I
conducted an Activity Theory analysis. Activity Theory posits that people
cyclically work toward specific objectives, and that their work activities transform
these objectives to an identifiable outcome. It focuses on analyzing what people
do as they work, and then seeks to explain what is informing those practices,
including an individual’s motives (or goals). Engeström (1999) outlined the
elements of what he termed Third-Generation Activity Theory, as depicted by
Figure 5.1. By examining Engeström’s activity system, we see that a person
(subject) works toward an objective in a specific community. The context of the
work influences the outcome of the labor. Also, Engeström argued that the division
of labor, implicit and explicit rules, and the tools used to support knowledge work
also influenced the outcome of it.
In technical communication, we generally assume both written and oral com-
munication is mediated by technology because language, including alphabetic

FIGURE 5.1 Engeström’s Third-Generation Activity System

138 Communicating Project Management

text, is itself a technology (see Ong, 1982; Hart-Davidson, 2001). Further, as Faber
(2002) explained of stories and storytelling in the second epigraph of this chapter,
people are sometimes limited—perhaps even confined—by the affordances
of language as a technology. Language can be a kind of constraint. Activity Theory
makes similar assumptions that work is mediated by tools and technologies, but
also that people always act as part of a social system. Activity Theory works to
establish a context for understanding what influences how people work. As a
method, it is useful for understanding the reorganization experience of the team
at DTI because participative environments tend to operate with norms that
support team psychological safety. These norms are the “rules” of the
“community,” and influence everything from “division of labor” to a person’s
perception of their own subject-positioning.
In the case of DTI, as psychological safety eroded during the organization’s
change, some people on the team grew more resistant to transforming their work-
flow. There are similar examples we can point to in the literature on Activity
Theory. For example, Daniels and Warmington (2007) explained how they used
Activity Theory to examine professional learning in British workplaces. Particularly
important was their discussion about resistance to change among workers,
despite understanding that modification in professional practice is necessary.
Resistance to change was somehow related to the participants’ identity and
perception of agency over their own labor practices. In other words, as Participa-
tory Design forwarded (see Ehn, 2008), people ought to be involved in decisions
made about how they work. Activity Theory affords us the ability to understand
how people work toward supporting organizational change as an objective.

Methods
To assemble a strong understanding of the activity system of the team, I used
the following methods. The approaches build on Spinuzzi’s (2013) approach
discussed in Topsight and Hart-Davidson’s (2007) on ideas on diary studies (which
I refer to as experience sampling).

Observations
To observe a first-hand account of how each employee worked, I observed each
participant as they worked at the DTI office. During observations, events were
hand-recorded on a legal pad. During natural pauses, I asked each participant
questions as he or she worked to help me better understand his or her various
activities and to make sure what was happening was clear to me. The questions
asked were unscripted and mostly took the form of prompts to explain what was
happening when an activity stalled, similar to think-aloud protocol. Then, notes
were transcribed to a text file and arranged alongside other data collected for the
study. All observations were completed over a three-week period.
 Managing a Reorganization Project at DTI 139

Artifact Collection
Throughout observations, artifacts were collected from each participant’s work-
space related to the study. Artifacts included copies of project plans, to-do lists,
training documentation, generic contracts, visual plans, books, screenshots,
timelines, and email. Participants redacted these artifacts before turning them
over for analysis. Participants decided which artifacts he or she felt comfortable
turning over, and sometimes artifacts could not be secured if they were categorized
as sensitive information.

Interviews
Immediately following the observation session, I conducted one semi-structured
interview with each participant. The interview used questions including many
of those recommended by Spinuzzi’s (2013) Topsight. As well, I developed
additional questions related to what was observed during each session. To come
up with these additional questions, I wrote down larger questions during the
observation to discuss during interviews. A second semi-structured interview was
conducted with each participant after analyzing experience sampling reports. As
with the observation session, interview questions were based on what was
observed in experience sampling reports.

Experience Sampling Reports

After each observation session, participants were tasked with completing four
experience sample reports over a period of two weeks. Each participant randomly
chose the days to complete experience reports, although they were also coached
to fill out reports on typical, rather than atypical days at work.

Analyzing Data
A modified version of Spinuzzi’s (2013) method of analysis for detecting patterns
across the micro (individual), the meso (team), and the macro (organizational)
levels was used to analyze the data. The goal for adapting Spinuzzi’s analytical
approaches was to understand what contradictions and disruptions occurred as
the team communicated about project work. As data was assembled, I worked
to discover how the reorganization seemed to be affecting communication.

Research Participant Profiles

Below I describe each of the people who elected to participate in this study. The
names used are pseudonyms. Each participant was on the newly formed customer
experience team and were co-located at a satellite office in the southeastern United
140 Communicating Project Management

States. These participants also worked together on several cross-functional projects

even though they were assigned to a fixed team. While teams at DTI were often
assembled around specific projects, the customer experience unit was staffed by
technical communicators working on similar tasks, albeit on different projects.

Participant 1: Bob
Bob had a college education in the humanities and training in Stanford d.school
methods (listening and innovation). Bob regularly completed DTI-sponsored
on-site courses in areas such as difficult conversations, giving presentations with
impact, and conducting behavioral interviews. Also, Bob’s position at DTI
frequently required cross-organizational collaboration on projects. During the
initial survey with the team, Bob noted a great deal of information-sharing
technology used in various projects, ranging from GoToMeeting, internal instant-
messaging programs, and telephone. Bob relied on tools such as a WYSE virtual
desktop, a laptop, an iPad, an iPhone, a whiteboard, and Post-It notes.

Participant 2: Tom
Tom also had a college education in the humanities and training in Stanford
d.school methods. Tom regularly completed DTI-sponsored onsite courses
on how to be a better coach, presenting with impact, and resolving difficult
conversations. As the Senior Manager of the Customer Experience Department,
Tom’s position required project and people management, working through
others, and setting direction. Tom reported, “Teams I work with—Development,
Test, Product Management, Program Management, Customer Experience
(Product Design, Customer Insights).” To support work, Tom noted tools such
as email and instant messaging, and also human resource tools for tracking the
goals of employees. The devices Tom used to access information related to work
were an iPad, a PC (at home and work), a WYSE virtual desktop, and an Android
smartphone.

Participant 3: Don
Don also had a college education in the humanities, and training in management
and employee personality assessment. Don’s position involved people and project
management in the information experience organization of DTI. Don’s focus at
DTI was an experimental evaluation program mixing traditional (e.g., text-
based) and nontraditional (e.g., digital) technical documentation. To support
sharing information at work, Don mostly used the team’s project management
system. The devices Don used to access information were a tablet and notebook
computer. Don most frequently worked with others overseas, particularly in other
DTI offices, and so routinely connected with others using digital technology.
 Managing a Reorganization Project at DTI 141

Participant 4: Tammy
Tammy had a college education in the humanities, and instead of specific train-
ing, reported “I’ve observed role models, learned by doing, and received feedback,
good or bad, from my managers or supervisors and other stakeholders.” Tammy’s
position entailed managing the projects of a technical writing team working on
how-to documentation for enterprise-level software that will be released
concurrent with the product. Tammy also used a range of digital and analog tools
to support work, including email, video-chat and a telephone. Generally, Tammy
used a laptop computer docked through a WYSE system with external monitors,
keyboard, and mouse.

Participant 5: Steve
Steve had a college education in the humanities, and reported no additional
training, certification, or education in teamwork and communication. Steve
explained the current position at DTI: “I am on the newly renamed information
experience team. We’ve recently been moved to the Customer Experience
department. Prior to that, we were in Engineering and were called Technical
Publications.” To communicate with peers, Steve explained “I prefer in-person,
telephone, [video chat,] email because they are direct and I know they are
happening. I don’t like social media for important information because it requires
I always check it to discover the information exists.” Steve used a laptop computer
docked through a virtual desktop with dual monitors, keyboard, and mouse.

Participant 6: Sheila
Sheila had a college education in the humanities, and regarding training,
explained “the only thing I remember is a Dale Carnegie course that most [DTI]
employees were required to attend several years ago, and an email course.”
Sheila’s current position required a great deal of communication with employees.
To do so, Sheila reported “daily standup meetings, weekly or biweekly status
review meetings, project management system workspace, project plans, and
[other] meetings.” She also explained:

We operate with transparency and all plans and reviews are published so
anyone on the project can see them or look them up. Meetings are recorded
for the benefit of those in other geographies (e.g., India) and are available
for anyone to review.

Similar to all the other participants, Sheila used a laptop and WYSE sys-
tem, but also used a personal laptop and tablet occasionally when working from
home.
142 Communicating Project Management

Organizational Changes at DTI

The team at DTI experienced organizational change at the project level in several
ways. As explained earlier, the team had previously spent the majority of their
time addressing bugs in technical documentation. They would receive customer-
submitted bugs, research the problem(s), address the bugs in the technical
documentation, and then notify the customer of the outcome. At the heart of
this work was an automated ticketing system. Essentially, each submitted bug
represented a kind of mini-project that was managed by the ticketing system,
which helped to assign bugs to the right information developer. That is, instead
of a person managing the communicative tasks associated with addressing bugs,
a system managed the division of labor, acting as an intermediary between
technical writers, engineers, and customers. The process was key to resolving bugs
efficiently.
While it was clear the team’s technical documentation had been valued and
would remain valuable, the long view of their role as technical communicators
was being totally reimagined. In fact, their job titles were even changing from
technical writer to “information experience designer” or “information experience
developer,” depending on which team in the organization they belonged to. The
organization itself was now focused intently on creating effective and valuable
customer experiences. Meanwhile, the writers at DTI who had grown accustomed
to creating technical documentation and fixing bugs would now be tasked with
designing customer experiences for the company. There was also a great deal of
discussion about learning how to leverage big data and discovering ways to
monetize content as a way to create additional revenue streams.
The stories told to me about elements of the reorg were not always positive,
and management seemed to have a sense that it was challenging for some on the
team. Take, for example, the level of clarity provided by Tom regarding the change
project:

As far as where the department is heading, I have a good sense for it, but
there is still fuzziness around what it’s going to look like and how we’re
gonna get there. We recently had a leadership [summit] off-site with some
of the most senior people in management to walk through a few things.
We are still digesting it. It takes a while to shift from the way you’ve been
doing something for a long time to a new way of doing things, especially
when you have to build up those skillsets. For me, I’m certainly flexing some
of the change management skills that are necessary to keep members of
the team focused. At the same time, I understand that it falls to each member
of the team to handle the changes that are happening around them and
that there is some uncertainty. The best thing I can do is be upfront with
them about what I know.
 Managing a Reorganization Project at DTI 143

The discomfort related to the reorg was further reflected in interviews. When
I asked each participant in the study about where they saw the organization
in the future, many of them were unsure about what the reorg meant for them
as employees of DTI in the short and long term. Some thought the team would
be dissolved. Others believed the team would need to evolve, which would
naturally force some people to find new jobs. Even so, the response of my
participants to the reorg was mixed. Some of the participants believed that
that technical documentation was still necessary for DTI’s customers, and felt
the new direction could alienate those who required special accommodations.
At the same time, there appeared to be a lot of collective enthusiasm about the
potential for individual and career growth. Meanwhile, the uncertainty hung heavy
because many people on the team still had not started these new projects. That
is, they had only heard about the changes that were behind the reorg because the
rollout was incremental, so they had not experienced the changes in any
meaningful way.
Adding to the uncertainty, a new manager had recently been hired at the
same level as Tom. There was a lot of distrust of the new senior manager across
most of the participants. Since he was new, he was often associated with many
of the changes afoot, and his interpersonal skillset seemed to frustrate a lot of
people because he was very direct and asked a lot of questions. As a result, there
seemed to be a sense of paranoia surrounding how people approached work.
For example, one of my participants created a private virtual workspace to colla-
borate “unmolested,” because team dynamics felt so strange at that moment.
Purposefully, only a few trusted people on the team had access to that workspace.
Another one of my participants regularly used a tinted piece of plastic over her
computer screen at work because she was worried about privacy when sending
and receiving messages. There were inside jokes told that clearly spoke to things
communicated at previous meetings about the goal of the reorg. The confusion
grew throughout the study as people continued to be reassigned and tasked. While
people were informed of new roles they would have in the organization, they
weren’t sure what those roles meant in practice or how they would be evaluated
in them. Later, the team’s senior manager was let go, and the new senior manager
put in his place.
Some of my participants felt the problems associated with the new senior man-
ager were cultural issues. Don explained during our observation session that there
was a great deal of confusion about the new senior manager’s role and what value
he brought to the team. Don also explained there was a perception on the team
that the new senior manager did not come across as transparent in how
he collaborated. Further, Don said that people on the team wanted to work with
the new manager, but they also didn’t trust him. Compounding these issues, the
new manager burned bridges with other managers on the team. Don felt he was
getting involved in too many ongoing projects, which was causing some division
144 Communicating Project Management

of labor issues and a lot of off-the-record conversations. People felt scared when
he asked them to meet because they could sense the political changes. From my
view, there was a palpable tension across the team’s management in meetings.
For example, during a meeting I attended, one of my participants took a screen
capture of the new senior manager’s calendar, which he had mistakenly opened
as he shared his screen over video chat. After the meeting, three of my participants
huddled to see what they could learn from the screen capture. It was clear they
did not trust the new senior manager, and felt threatened by his role in the reorg
as well.
The disruptions related to the reorganization were not always explicit. They
were sometimes tacit or hidden from view, such as the secret workspace or the
use of tinted plastic to cover a computer screen. By disruptions, I mean breaks
in participation and stalled productivity. That said, the disruptions seemed to
present themselves at the project level as individuals on the team worked under
the new set of rules introduced by the reorganization. The new rules suggested
people collaborate face-to-face as often as possible, especially to do “high-touch”
or “physical” activity, such as affinity diagramming using sticky notes. From
my perspective, the goal of the reorg was to remove silos and spark more colla-
boration among the group. It placed technical communicators at the center of
developing valuable customer experiences. Furthermore, it put technical
communicators into leadership positions as they would act as content developers
and strategists. Nonetheless, to accommodate the changes in processes, DTI
implemented some new tools. The main one was a project management system
that looked and operated quite a bit like a social network. There was a timeline
that streamed information that could be scrolled through. A user could also email
and video chat with someone using the software. As well, DTI implemented a
few workshops to train people in design thinking or in new tools. The remainder
of the changes seemed to be handled at the project level. So, while the rules of
their work changed (more collaboration on multimedia content), people on the
team tried to implement them with largely the same division of labor and tools.
Without opportunities to participate in the change project, however, people on
the team had no way to point out this contradiction presented to them by the
new rules of the reorg.

DTI and Project Management

DTI had offices all around the world, and as a result, often had to facilitate project
management across times zones and continents. Workers from each office
frequently collaborated on projects using tools the company provided. As well,
the company itself was often involved in building their own collaboration tools.
The organization was truly networked in the ways described by Rainie and
Wellman (2014), with employees connecting via video chat and working on virtual
servers. As a result, close attention was paid to establishing best practices in
 Managing a Reorganization Project at DTI 145

connecting as a virtual team. But, the division of labor made people somewhat
insulated from each other. Each technical writer at DTI incrementally learned
to manage projects, which seemed tied to their title. For example, a lead technical
writer may have several people that report to them, whereas a more junior level
author would be tasked with managing smaller portions of projects, like
addressing bugs.
To connect globally distributed virtual teams, DTI was using several virtual
environments to support project work, such as asynchronous project manage-
ment software or video-chat tools. Activities typically relegated to a specific
physical space, administrator, team, or unit could become, instead, extended
around the globe virtually to those best positioned or suited to do the work at a
given time. Even so, many of the participants felt absolutely tethered to their desks
since many of their collaborators did not work in the same office, state, or time
zone. To accommodate integration of distributed team members, managers had
to learn to schedule common times. Meeting rooms also had to be flexible and
incorporate people working at a distance.
The tools the team used to manage projects also had to be flexible. In the past
they had used several platforms to support collaboration on technical
documentation, such as SharePoint, OneBug, Kampile, and so on. Authors were
well-versed in Darwin Information Type Architecture (DITA), for example, and
many of them felt quite comfortable writing technical documentation using
programs such as Xmetal. One tool caused quite a bit of controversy, however.
As noted earlier, a new project management system had been implemented to
centralize and make communication more transparent, but the system seemed
to be too far a leap for some people on the team. The system incorporated a social
networking approach to coordinating teams and information, but some of the
participants just didn’t see its benefits to managing project work. In fact, these
participants felt it was actually a detriment and there were better tools already
in place.

Participation and Communication at DTI

One of the values forwarded by the reorganization was DTI’s interest in
emphasizing face-to-face communication among employees, rather than relying
on virtual interactions. Even though the organization did allow for employees
to spend one or two days a week working remotely, there seemed to be a clear
sense that face-to-face collaboration was now preferred over virtual. This shift
mirrored a similar call back to the office by other well-known organizations, such
as Yahoo (Miller & Rampell, 2013). One of the reasons for this preference for
face-to-face collaboration was DTI’s interested in the power of design thinking,
which they felt argued that everyone should work together in a room. Even though
the emphasis on face-to-face was clear, the data suggested real-time collaboration
was also leveraged through virtual means, and both approaches were, at times,
146 Communicating Project Management

used interchangeably out of necessity: people on the team worked in different

offices, including managers.
Sometimes the arrangement of communication varied depending on which
members of the team were involved in the project as well as the size of the group.
Instead of using asynchronous methods to work together, workers were
encouraged to meet with someone and complete a portion of the project while
being physically co-located together. To rationalize these shifts from an
organizational perspective, Steve suggested during a conversation with another
information designer that video chat technology could get in the way of
collaborative work because “physical activities must be done in physical spaces.”
Similarly, in an interview, Tammy described how new projects that emerged from
the reorganization stressed more physical, face-to-face (what she termed “high-
touch”) communication. Further, much of the face-to-face communication
observed during the study required the use of digital tools, such as their project
management or email systems.
But while real-time and asynchronous approaches were used to support
collaboration at DTI, there was also a pattern to how virtual real-time collabora-
tion was most often used: to discuss and share project information. Such activities
could be classified as low-touch instead of high-touch because there was not a
physical element (such as huddling together to create a journey map). In this
configuration, project leads scheduled synchronous video chat meetings to
coordinate low-touch collaboration. In the examples I collected, this approach
was used for long-term projects that could not be completed over a period of a
few hours, and also when the project involved employees distributed across
different offices.
Tammy explained how the reorganization transformed her approach to
collaborating with people on the team during her interview. She described a recent
activity to develop a list of customer journey points for an upcoming product
release, and said, “we sat in Sheila’s office and wrote on the whiteboard and used
Post-It notes.” Apparently, the face-to-face real-time collaboration was a variance
from previously used procedures. Tammy continued:

The old school ways of doing things—two months ago [another employee]
and I were working on the previous project and we actually did this in Podio.
We did a [video chat] and we started in a Word document, and we said,
“What do we need to do between now and the product release?” And we
came up with a schedule. I was at my cube and she was at home on her
phone.

In this example, Tammy gave an account of completing similar activities face-

to-face and virtually and noted how the “old school ways” of approaching the
work had changed. The following paragraphs provide additional examples that
detail these disruptions in context and explain how they influenced worker
 Managing a Reorganization Project at DTI 147

participation. I frame each of the examples into themes that represent each of
the broad disruptions employees experienced.
Although there was a strong push for face-to-face communication, there was
still a great deal of asynchronous work being done by the team. Asynchronous
collaboration at DTI tended to be classified as low-touch, which under the
rules of the reorganization, was a less desirable way for people on the team
to collaborate. Additionally, asynchronous collaboration had been an important
part of the team’s work. The process of farming bugs, for example, was an
asynchronous way of working because it relied on coordinating information across
the team in steps that did not occur in real-time. During the study, members of
the team were still farming bugs for technical documentation while also working
on other projects. One of the problems associated with asynchronous methods
of communicating was that it was ingrained into the team’s method of working.
They used email to share important information, such as meeting notes, but email
was generally asynchronous. Management wanted to do away with email for
coordinating work, and instead asked for those updates to be posted in the project
management system.
The disruptions in the section are all related and in some important ways,
they overlap. While the disruptions demonstrate a technical problem with the
reorganization in terms of technology, it also shows human elements that are
both cultural and primordial. Change can be hard for some personalities on teams.
Time and again the participants across Chapter 3 and Chapter 4 would discuss
how to approach different situations and audiences to deliver a message and move
a project forward. So, while the resistance to the project management system was
largely masked as technical, there were also hints in the data that suggested the
problems were also about finding space for exercising agency during this specific
moment of change.

Disruptions During Synchronous Communication

Disruption 1: Infrastructure and Information Communication

Technologies
Supporting participation during organizational change requires access to stable
infrastructure and information communication technologies. Without stable
infrastructure and information communication technologies, people on the
study were not always able to participate.
During my site visit, Steve collaborated in real-time on a video chat platform
to prepare informational videos in support of an upcoming product release. The
videos were being used to highlight new features of the product, but he wanted
to make sure that the software selected to record screen captures would work if
operated remotely. Steve set up a video chat session with a member of his team
working at home that day and they ran a test of the software together, working
148 Communicating Project Management

on different configurations to make sure their plan would succeed. During the
session there were issues with communication because of interruptions in the
internet connection. While they were able to discuss issues related to the project
and test the software, the connectivity issues temporarily stalled participation.
Internet lag was the most common infrastructural disruption observed, and it
would occasionally require an employee to repeat what he or she had said.
Technical issues with the organization’s virtual desktop software also influ-
enced participation, making it more difficult to access tools and files. For example,
during one of the visits on site, the DTI virtual desktop app was not functioning
for the whole organization. Throughout the visit employees explained they felt
lost without the ability to access their virtual desktops. The reason for this was
that participants used a cloud computing system to connect to DTI servers and
used a virtual desktop to work. Employees were unable to access apps they had
grown accustomed to using to support work. Also, on a different day and during
a product demonstration, I watched as Steve experienced difficulty getting his
virtual desktop to work. He restarted the computing device in the hopes of making
the app function. It didn’t work, and he eventually gave up, opting to describe
rather than show the benefits of the product. During another site visit, issues with
DTI software required Bob to make a phone call to the DTI help desk.
Additionally, technical issues with software functionality sometimes impacted
connections between employees. During my interview with Sheila, I asked about
an impromptu comment made during the observation session regarding
discomfort with video chatting. Sheila explained, “I don’t like it as much because
the way the camera is positioned is not the same as making eye contact.” Later,
she continued, “I can’t see their face if I’m looking at my camera and I expect
the opposite is true.” To avoid video-chatting, some participants preferred email
conversations and others would instead make phone calls or try to schedule face-
to-face meetings. A person’s comfort level with the software would, in part,
determine how they would connect to others on the team.
Technical and infrastructure issues did not disrupt participation permanently,
and had a minimal amount of impact on productivity. These issues did
occasionally influence how people chose to interact with others while working,
and caused disruptions related to the digital infrastructure of the work environ-
ment. In some instances, employees would prefer to speak to a colleague face-
to-face or over the phone, especially when technology failed or caused issues.
Those conversations would still lead to productive ends, however, and sometimes
the digital tools appeared to stall participation rather than support it.

Disruption 2: Virtual Collaboration

Limitations of virtual real-time collaboration seemed to have greater influence
over participation and productivity than infrastructure and information commu-
nication technology issues. High-touch collaboration did not often occur virtually
 Managing a Reorganization Project at DTI 149

because the team’s tools did not appear to support it. Sometimes, the use of the
tools by participants made high-touch virtual collaboration difficult, particularly
when working with others at different sites. In speaking with Tammy about this
disruption, she explained, “It’s a little weird for DTI because one of the things
we sell is anywhere, any device, any way. So I think we actually have to develop
the tools to have high-touch at a distance.” In other words, the team’s tools
demonstrated a propensity for sharing information, but not for real-time
collaboration teamwork that would support multiple forms of participation.
I observed a snippet of remote user test during one site visit. The user test
was being hosted at another DTI office, presumably in a usability testing lab. The
moderator dialed in members of the team through video chat and they watched
as the user worked with a product. Meanwhile, when members of the team noticed
usability issues, they filled out virtual sticky notes. There was also an instant
messaging backchannel transpiring across the team, discussing what they were
watching. The team could see, in real-time, what was being updated on the virtual
sticky notes. It appeared, however, that employees were taking turns filling out
each note and there were also some delays that caused minor interruptions to
the internet connection. There also appeared to be limitations to the amount of
participants able to work at once. More than ten people filling out the sticky notes
would have been too chaotic, particularly because the screen size of the device
made it difficult to see all of the ongoing activities simultaneously. On the other
hand, because participants were taking turns updating each sticky note, it likely
enabled backchannel communication to run more freely.
Steve explained that many employees use video-chat software differently.
Some people would use video, some preferred only voice without video, and still
others opted for instant messaging, depending on internet speed or the person’s
location at a given moment. Also, because configuration of software can be
individualized to the user, it could be easy to overlook something as simple as
an instant message given the screen size and view. The team’s video chat software
provided many avenues for communicating, but at times that flexibility also
caused disruptions when participating.
I learned, either through observations, interviews, or experience sample
reports a variety of examples of one-on-one activities that were highly collaborative
and others that were more one-to-one, where the manager simply gave feedback
to help the person move forward on the project. For instance, Bob and Tom
worked face-to-face in a conference room on a survey designed to help them learn
more about the customer experience. The collaboration was serendipitous in that
questions were being reformulated together on the spot through reimagining what
the survey could learn. Earlier that same day I observed a one-on-one meeting
between Tom and Steve in the same room about an ongoing project to curate
documentation for products no longer being supported by DTI. Tom gave
feedback to Steve and told him how to proceed. There seemed to be very little
planned serendipity in that specific session. Both of these sessions were completed
150 Communicating Project Management

face-to-face, but used virtual tools (a computer, a projector, and a project screen)
to assist the work. In other words, face-to-face collaboration did not always lead
to similar kinds of participation.

Disruption 3: Sharing and Retrieving Information

Interviews, observations, and experience reports also emphasized issues with
information retrieval when collaborating in real-time online or face-to-face. The
data also showed that information used to support collaboration was sometimes
posted or found in unexpected places, and that this approach slowed participa-
tion. These issues illustrated confusion on the team about how and where to share
information with each other.
I observed what Tom called a routine “check-in” with Steve, and they ran into
difficulty finding information previously stored on the project management
system needed for the meeting. Tom noted that the interface design had recently
changed, and these changes caused him some confusion. Even more, Steve and
Tom indicated some other general issues with the platform design, which made
navigating the system difficult for them. After several minutes, Steve found a wiki
that had been used when the project started some time earlier. He was then able
to find a link to the workspace where the information he was looking for had
been uploaded. After accessing the wiki, they were able to find the file with the
information needed. The unproductive nature of the search led to productive
results, however. This action seemed to suggest that storage of information at
multiple access points could potentially lead to enhanced participation.
Another example: Steve sent meeting minutes for a project through email
instead of uploading the file to the project management system workspace. There
was no preference given at the meeting where the minutes should be sent, but
he chose email to distribute the information. On an experience report from a
few weeks after this event, Steve chose to do the same thing and emailed meeting
minutes to the team instead of posting them in the project management system.
Experience reports, observations, and interviews all showed inconsistent use of
methods of sharing information with the team, which hampered real-time
collaboration. Tammy explained “Basically you never know what’s going to pop
up in [the project management system].” Steve corroborated this explanation,
adding that email was a “push” service, while [the project management system]
was more of a “pull” platform, which meant it was easier to miss something
published in it than if it was emailed.
It seemed apparent that the team had disagreements about the best way to
share information during the reorganization. Some preferred the project manag-
ement workspace be updated while others preferred an email. The disagreement
about where to store information seemed to cause the most consistent unpro-
ductive disruption.
 Managing a Reorganization Project at DTI 151

In general, there was also disagreement in the team about which tools to use
for information sharing and retrieval to support real-time collaboration. There
was a frequent amount of redundancy of information posted in the project
management system and sent through email. Perhaps a result of this redundancy,
Tammy’s first daily reported activity (as noted on her experience reports) was
to check email and the project management system (always in that order). Other
participants took a similar approach, although sometimes it was voicemail and
then email, but the project management system was never the first place each
participant checked, perhaps indicating that using the platform had not yet
become a habit or that its adoption into workflow was still relatively new.
These issues were exacerbated by status updates, which were weekly reports
about the progress made on project work. These were usually sent to the relevant
members of a project via email. Later, the status reports were updated in the
project management system by the project lead. In discussing this process with
Sheila, she explained that people were overwhelmed by choices to share
information and that it would be much easier to manage projects if information
was only posted in the project management system. Others simply did not agree
and felt it was too much work to ask everyone to update the project management
system.

Disruptions During Asynchronous Communication

Disruption 1: Lack of Training in the New Project

Management System
One reason the project management system was not always used to centralize
communication seemed a lack of technical know-how. The system did not fit
the mental model previously used (see Disruption 3 in this section), and some
felt the change in the communication workflow was not needed. During an
interview, Steve explained that one difficulty encountered in his work had been
learning how to use the system:

There are hundreds of different apps—thousands maybe—of different

applications available that people could do things with. There’s a lot of
duplication. I don’t know why there is duplication, but there’s a lot
of duplication. You might do a search for apps that do meeting minutes
and you’ll get five or six or seven that give you meeting minute capabilities,
so how do you choose between them? There’s no information as to how
to do it. We weren’t taught how to create our own apps—there’s an app-
making tool. We were just told that you could do it. But, to do it, you’ve
got to figure it out yourself, and there’s a lot of trial and error involved
in that.
152 Communicating Project Management

Earlier, I referenced that Steve frequently chose to send meeting notes over
email rather than post them in the project management system. He took this
approach even though centralizing communication was one of management’s
goals for the reorganization. The project management system was meant to be
the communications hub of the team. Meanwhile, Steve noted the project
management system could be used to build apps, but he hadn’t learned how to
make them. When asked if he would be more interested in using the project
management system had this training occurred, the response was telling: “Yes,
if I didn’t have to spend a lot of time figuring out things for myself.” Additionally,
he also explained how he had used email in the past to survey his team, but had
trouble duplicating that approach in the project management system:

If I want to do a survey of what people think of something in the group,

I go out there to see if they have a survey app. Or can I make a survey app?
It’s things like that. Whatever comes into our heads. We go out to project
management system and see what exists or see if it’s something we can make.
But, the hammers and the nails and the screwdrivers and saw are there but
nobody teaches us.

Shedding light on training at DTI, Tammy told me that training had waned
in recent years at DTI. In her interview, she explained, “For specific skills we do
a lot of internal training. I don’t see this very much anymore. [Sheila] trained
everyone on [the project management system] and then we bring new people
in as things come out.” While a clear indication that some sort of training
was done to help people engage with the project management system, Tammy
also suggested that software training had recently grown less frequent. Despite
the training that had occurred, my observation session with Tammy reflected
her depth of confidence using the system. At one point she commented, “This
is a work in progress and I don’t even know what I’m doing. I’m on the path
but I can’t see but 10 or 20 feet in front of me.”
Even so, it was clear some sort of training had occurred with the system,
but there was a mismatch of expectations for the session. During my observa-
tions, I learned Sheila asked the team to play with the new project management
system for a period of time and then help her design a workshop by crowd-
sourcing suggestions, ideas, and general questions. The goal for this approach
was for the team to learn through experimentation with the product, and to
focus the training on the parts of the software individuals were struggling to grasp.
As Bob explained, it was not a hands-on workshop to teach people every aspect
of the software. Interestingly, the approach invited participation, but for some
it was not the kind of training they felt was useful. In his interview, Steve
suggested that one reason Sheila’s approach did not work well for him was the
deadline-driven nature of the team’s work made playing with new software
counterproductive. In his view, there were more important tasks to complete.
 Managing a Reorganization Project at DTI 153

To be fair, he made a similar claim after a meeting when he had not completed
a storyboard that a manager requested. He felt the request was a waste of time,
even though it invited him to participate in ideation surrounding a DTI
product.
The most obvious reason for the team’s struggles with the project management
system seemed to be the tension between productivity and participation. There
was a general attitude that employees were capable and smart so they should be
able to figure out new software without too much assistance. Sheila, for instance,
explained during her site visit that through blogs and training videos she was
able to learn how to use the project management system. Bob said learning to
use unfamiliar software was a skill he had learned in college, and the ability
to learn new software as needed was an ability DTI looked for in new employees.
As a caveat, Bob noted, “[The project management system] was really different
though. [It] took me a little longer to learn how than others.” This form of
participation, however, did not feel productive to others. They felt it would be
more productive to learn through comprehensive training, and that would make
centralizing communication in the project management system far easier to
leverage. Implementing the project management system proved challenging for
other reasons as well.

Disruption 2: Inconsistent Adoption of the Project

Management System Across the Team
Several instances of observations, interviews, and experience reports indicated
inconsistencies in the adoption of the project management system, particularly
in cross-organizational projects and other projects that started before the reorgan-
ization. For a variety of reasons, the inconsistencies in how different people used
the system created confusion about where information was stored about project
work. Some employees were working on projects that began before the reorgan-
ization, and because of that, had only heard about the new direction of the
organization without actually experiencing it. Tom explained this issue earlier
in the chapter, but further elaborates here:

We are being asked to shift what we produce, how we produce it, and how
we work. And there are people that are getting that and getting on board
with it just through being on projects where it’s starting to happen, but
it’s not like everyone is experiencing it at the same time.

One of the clear issues presented in the data was the project management
system was not yet being adopted by every group at DTI, and as a result,
employees were expected to navigate many different and overlapping tools, some
of which they believed worked better. During our observation session, Tammy
opened a SharePoint file and remarked how useful it had been when managing
154 Communicating Project Management

a recent project. Experience sampling reports detailed several similar instances

of SharePoint being used to manage projects currently underway. In addition,
experience reports showed that other projects were using wikis. Internal DTI
information resources, such as news about new products or acquisitions, also
used SharePoint and wikis to host content about authoring statements or to
demonstrate a new product feature.
In the Customer Experience Organization (where the team was situated),
employees would often avoid the project management system and backchannel
information through email or rely on other familiar tools to participate in colla-
borative work. Likely, this activity would occur because of simple familiarity and
habit. As seen in the previous section on training, even after being trained to use
the software, the project management interface was still difficult for participants
to navigate. As a result, it seemed many employees would use tools they already
felt comfortable with.
Experience sampling reports were especially useful in identifying how email
was being used serendipitously alongside other tools in handoff chains. The
handoff chains were not particularly complex, but they indicated that the project
management system was most frequently used as a place to store information
about a project, but not host ongoing asynchronous discussions or collaborations
that occurred as needed. On several occasions, threaded email conversations would
occur, and then eventually a document or status would be updated in project
management system on the same project. While avoiding the project manage-
ment system may have disrupted participation on the one hand, turning to email
enabled it on the other. In other words, it seemed they were strategizing
communication using familiar tools like email, and then posting in the project
management system once the strategy was assembled.
Steve also showed reticence with the rush to use it to centralize work in the
project management system. For example, he indicated that email did a better
job of notifying an employee when an issue needed immediate attention. In our
interview, this was referred to as the “push versus pull” method of commun-
icating mentioned earlier in the chapter. Sheila disagreed, however. In her
interview she reported, “I like [the project management system], but there are
people on the team who can’t or won’t use it.” Even more, during our site visit
she suggested that managing projects would be much easier if information was
all centralized in the project management system, particularly status reports. The
team did not agree on how the project management system should be used to
support asynchronous collaboration, but continued to participate through
reliance on common tools.

Disruption 3: The Existing Role of Email

Another important finding indicated that the existing role of email in the
organization influenced how asynchronous collaboration was completed. Until
 Managing a Reorganization Project at DTI 155

the reorganization, developing product documentation and fixing bugs had

historically been the function of the team. A typical scenario: a customer would
seek online documentation to help them complete a task, such as installing an
updated version of software on a device. When trying to complete that task,
something would go wrong and the customer would be unable to figure out the
problem because the documentation was incorrect. The customer would then
submit the error as a bug and an email message would automatically be sent to
the address of two lead information developers designated to work with bugs.
The developers would then assign the bug to a specific author. The author would
receive an email notifying him or her that a bug had been assigned. The author
would then work to solve the problem using a variety of internal software and
by connecting with other parties, such as engineering, as needed.
Once the bug was fixed, it would then be submitted for publication and
the author would update the bug ticket. Upon this update, an email notification
would be automatically generated back to the lead information developer,
who then would publish the fix after reviewing it for quality and accuracy. Once
the fix was published, if the customer was external to DTI, an automated email
would be sent to notify the person the bug had been fixed. If the customer was
an internal DTI employee, developers would notify the person through email
personally.
Key to the process described above is the usage of automated emails to
support work processes. A majority of the work for the team was automated
through email, and in many ways email was the central communication hub that
notified employees when work needed to be done. While the programs used to
support the bug fixing process varied, the use of automation helped to create
a seamless and familiar process that employees would rely on. For example, if a
meeting was requested through video chat, the invite and meeting information
was delivered through an email and updated in employees’ Outlook calendar,
which was also associated with that person’s email address. None of the existing
automated notifications liaised with the project management system, which
indicated, at least in terms of process, that using email was at times more efficient
in workflow that involved both synchronous and asynchronous collaborative
activities.
Email had also been historically used as a way to promote accountability in
project work. Both Tammy and Steve indicated this specific issue during my site
visit. The main concern was that email showed a record of communication, so
that if work was requested but not completed, email could be audited to support
that fact. While the project management system had similar functionality, there
appeared to be uncertainty about documenting work processes for the sake of
accountability. Such documentation is frequently important to Human Resources
Departments as well.
In addition, during observations I noticed that official DTI messages about
new products and company initiatives were most frequently sent out through
156 Communicating Project Management

email. Experience reports also supported this conclusion. While DTI posted
information in the project management system, I was not able to get a sense of
how or how much, so I do not fully know in what ways DTI as a company used
the project management system to share information with employees. Tom
indicated that an employee could reach the DTI helpdesk team through the project
management system because they monitored the activity stream, which showed
an active commitment to the platform. Nevertheless, based on my observations,
systematically moving away from email contained challenges not only with
behaviors and attitudes of employees in the Customer Experience organization,
but with the tools that were being used to support participation in work. During
my observation session with Tom, he indicated as much, and argued that it would
take a total culture change to widely adopt the project management system across
the team.

Participation in the Activity System

When consolidating the data from each communication activity and event, the
disruptions related earlier in this chapter show a contradiction in the working
environment. In particular, the consolidated activity system indicates disruptions
coordinating tools, rules, and the division of labor at the team and individual
levels, and that these disruptions appear to lead to a contradiction at the organ-
izational level. The central contradiction the team faced is that while the
reorganization had changed the rules of the system, such as participating in more
face-to-face collaboration and communication, the tools and division of labor
had not changed in support of this new focus. In other words, employees could
not follow the rules of the reorganization because their tools and division of labor
did not allow for it.
Earlier in this chapter, the data indicated that employees frequently turned
to familiar tools, such as email, when participating in real-time or asynchro-
nously. Across the organization, the use of tools varied depending on the project
and team. In supporting participation, there seemed to be no one single approach,
although management had asked employees to focus more on high-touch
methods. Given the distribution of the team, however, it was challenging to
arrange high-touch collaboration because the tools did not yet support it and
the level of familiarity with certain tools was unpredictable. Even more, parti-
cipants seemed to disagree about how collaboration tools could and should be
used. Figure 5.2 illustrates the activity system where contradictions appeared
to surface. The dotted lines are meant to indicate the areas where the contra-
diction affected participation.
It is interesting to consider how the activity system was influenced by the stories
I was told about the reorganization. There was clear evidence of distrust and
frustration enacted through the use of new tools and attitudes toward the change.
The stories also seemed to emphasize that people wanted to participate in some
 Managing a Reorganization Project at DTI 157

FIGURE 5.2 Consolidated Activity System1

meaningful way, both in project work and in helping the organization create a
vision for the future of customer experience and technical documentation at the
company. That dialogue, however, was not facilitated during my time with
the team.
From an activity perspective, the reaction to the uncertainty of the reorgan-
ization negatively influenced both participation and productivity. In some cases,
managers like Don spent a fair amount of time listening to people as they vented
over issues related to the reorganization. The first minutes of several meetings
focused on finding information in the project management system or with try-
ing to understand how the system itself functioned. While some of these issues
could be written off as part of any change project, they were also directly related
to how people used tools to connect and manage projects. In this case study,
organizational change was not just a concern of upper management, it seemed
to influence several communicative activities that facilitated project work. It influ-
enced attitudes toward people on their team and new technologies.
These results reflect back to Suchan’s (2006) idea that a communication
framework is needed to help managers support employees during change. The
results of my work with the team at DTI suggest that it is possible managers can
see resistance to change initiatives all the way down to the project level. To use
Suchan’s terms, the “cognitive underpinnings” were often displayed in how
people approached the new project management system. For example, the project
management system represented an “official” communication channel, but
people preferred to have discussions about project work outside of it. The results
also suggest that psychological safety was important for this team, but that the
method of rolling out the reorg seemed to erode trust, which directly influenced
158 Communicating Project Management

how people on the team approached project work. In other words, while the
nature of any reorganization is often difficult because it can end with layoffs and
loss of pay, a lack of participation from employees can cause problems at the
project team level.

Participation as Stable, Nonlinear, Productive

My work with the team at DTI also showed how participation can be understood
as flexing agency in circumstances where space for communication is constrained.
Interestingly, the contradiction presented by the activity system and the myriad
of disruptions experienced by the participants in this study also created
opportunities for inventing solutions to their constrained agency. Without being
invited to participate in the change project, the people in the study resisted certain
elements of it (the project management system) and embraced others (new
methods for working). Participants found ways to make space that worked for
them. In terms of the broader change project, however, this constrained space
did not make for productive transformations at work. Two of the managers in
the study, Tom and Bob, both felt there would need to be a culture change for
the change to occur. Perhaps an invitation to participate in the change project,
to implement some sort of an official and open dialogue about processes and
procedures, would have helped enhance psychological safety during the reorg.
In what ways can the work of the team be depicted as stable, but nonlinear?
Individuals’ process intersected in ways that were hard to predict, sometimes
serendipitous or just-in-time, and disruptions frequently raised questions among
participants about how the team could best work together across a variety of
environments and tools. For instance, an email conversation discussing a recent
bug or project status in the project management system can be seen as participa-
tive. The conversation exists to provide information, but also to challenge that
same information and to continue to move the project into new directions.
As well, the conversation happens when it needs to, sprouting up again in other
forms when it is disrupted by an event, such as a lack of a training in the project
management system or confusion with its interface.
One example of the nonlinear nature of tool use is that while there was a
top-down imperative to use the project management system, there was an
intentional, reactive response to employ email as a means to use the project man-
agement system. If the project management system caused a disruption, then a
backchannel could be created, just like if a root is interrupted by a rock, it either
breaks through the rock, grows around it, or stops growing. The tension itself
is not nonlinear, but the action of working through the disruption by creating
other pathways often could be. Some backchannels demonstrate a nonlinear
approach to working through unproductive disruptions, such as internet lag, by
using tools that required less bandwidth, like an instant messenger or a landline
 Managing a Reorganization Project at DTI 159

phone. In this way, nonlinear participation can actually be seen as a pragmatic

consideration, leading to productivity.
Participation was also sometimes attained in spite of a disruption and at other
times because of a disruption. For instance, in experience reports and observa-
tions, serendipitous face-to-face conversations would occur in employee’s
cubicles, whereas the same proximity caused noise disruptions that were
somewhat unproductive for some participants. For some, the noise disrupted the
work and annoyed peers sitting at the next cubicle. The work continued anyhow,
and some people would simply ignore noisy neighbors, deciding to work around
the disruption instead of through it. These serendipitous conversations appeared
to lead to new intersections of ideas and ended up being productive. While the
noise may have stalled productivity for a short time it did not stall it permanently.
On the other hand, for some the noise served no true purpose; some employees
did not believe it helped to create new connections or ideas because employees
essentially learned to quit listening to do their work.
Also, the lack of training in the project management system was also a pro-
ductive and unproductive disruption for participating. In fact, the confusion about
the project management system stalled participation most frequently, but also
created opportunities to engage in other ways. When a person did not know how
to use the project management system, they stopped and went to a familiar tool
relatively quickly. Metaphorically, the root decided not to grow through the
disruption, but around it. The same can be said about the team’s internal
disagreements about tools. The disagreement caused confusion and created
backchannels at times, but those backchannels also supported people as they
worked and appeared to enhance psychological safety. Participation in project
work would simply stall while a person spent time looking for information they
could not find.
Disruptions appeared to be productive in other ways as well. While manage-
ment had asked employees to avoid using email to support project work, many
resisted and discussed information over email anyhow. While I was not able to
read those emails specifically, experience reports indicated that progress was made
on projects discussed over email. Meanwhile, the request from management
seemed to motivate participants to reflect on their use of tools, especially Steve
and Tammy. The use of email, however, is an excellent example of the nonlinear
structure of this specific work context. Although the project management system
was not being used in the manner management expected, email was being used
as a substitute to backchannel information. The use of email created the type of
intersections and connections needed at that moment to move a project forward.
Also, the use of email to discuss project work created a dialogue in the team about
how to best collaborate, and that ongoing dialogue was often enacted in unpre-
dictable ways. Additionally, more time away from the desk in other workspaces
led to serendipitous communication—the kind that DTI was hoping to cultivate
160 Communicating Project Management

through the reorganization. I observed such an instance when Steve worked in

the small conference room to video chat about a video project. While he worked,
additional discussion surfaced unexpectedly about the lighting of the room.
That conversation would not have existed unless Steve arranged that meeting in
that room with the poor lighting.
Finally, an important outcome of these results is that project work, regardless
of disruptions, kept moving forward. Occasionally, a task was observed that totally
stalled productivity due to confusion or resistance, but none of those issues
disrupted productivity permanently. Instead, it seemed that the work would get
done another way. The ongoing conversation that came out of the reorganization
had more to do with the methods of working than with the outcomes. People
were getting their work done, just not in the way preferred or suggested.
Ultimately, some people managed to grow through the disruption and others
around it, but according to my observations, interviews, experience reports, and
other artifacts I collected, participation continued regardless of constrained
space. Understanding that communicating about the structure of work process
can be nonlinear, especially during times of organizational change, can help project
managers better understand the implications and effects of disruptions on project
work. Just like how space must be made for people to participate, there must be
space made for people to adjust to new ways of working, thinking, and acting,
and this is particularly true at the project level, where incremental change can
still represent a significant shift in how people participate in project management
activities.

Conclusion
The team at DTI provides an example of what disrupts and contradicts the
communicative activities that support participation in change projects. While
organizational change initiatives are not always described at the project level, they
do seem to influence participation in project work and communication in
important ways. As Hornstein (2014) recommended, the case in this chapter
suggests that project managers see the relationship between change initiatives and
project work as deeply related rather than parallel processes. In using an Activity
Theory analysis, we learned how participation in project work seemed to respond
to disruptions by inventing innovative solutions. The chapter also explained
that the reorg forwarded a contradiction that the team do more face-to-face
collaboration, but the division of labor and tools did not change. A participative
approach might have made space for the team to have those discussions, which
might have helped the reorg make steadier progress.
The next chapter assembles the results of all the cases into a theory of par-
ticipatory communication in project management that is based on agency and
what I call “a collective sense of kairos.” It also helps to create a broader picture
 Managing a Reorganization Project at DTI 161

of the results across all of the case studies, specifically highlighting how project
management relies on a participative approach to communicating. Finally, the
chapter ends looking forward to future opportunities for researchers, practi-
tioners, and instructors of project management and technical communication.

Notes
1 Please note, this model and design of the consolidated activity system originated from
the work of Spinuzzi (2013).

References
Beer, M., & Nohria, N. (2011). Cracking the code of change. On change management (pp.
137–153) [Kindle version]. Retrieved from Amazon.com.
Brafman, O. & Beckstrom, R. A. (2006). The starfish and the spider: The unstoppable power
of leaderless organizations. New York: Penguin Group.
Daniels, H., & Warmington, P. (2007). Analyzing third-generation activity systems:
Power, contradictions, and personal transformation. Journal of Workplace Learning,
19(6), 377–391.
Ehn, P. (2008). Participation in design things. In D. Hakken, J. Simonsen, & T. Robertson
(Eds.), Proceedings of the tenth anniversary conference on participatory design 2008
(pp. 92–101). Bloomington, IN: ACM Digital Library.
Engeström, Y. (1999). Activity Theory and individual and social transformation. In
Y. Engeström, R. Miettinen, and R. Punamäki-Gitai (Eds), Perspectives on Activity
Theory. Cambridge: Cambridge University Press.
Faber, B. D. (2002). Community action and organizational change: Image, narrative, identity.
Carbondale: Southern Illinois University Press.
Hart-Davidson, W. (2001). On writing, technical communication, and information tech-
nology: The core competencies of technical communication. Technical Communication,
48(2), 145–155.
Hart-Davidson, W. (2007). Researching the activity of writing: Time-use diaries, mobile
technologies, and video screen capture. Studying the mediated action of composing with
time-use diaries. In H. McKee, & D. DeVoss (Eds.), Digital Writing Research:
Technologies, Methodologies, and Ethical Issues (pp. 153–169). Cresskill, NJ: Hampton
Press.
Hart-Davidson, W., Bernhardt, G., McLeod, M., Rife, M., & Grabill, J. T. (2007). Coming
to content management: Inventing infrastructure for organizational knowledge work.
Technical Communication Quarterly, 17(1), 10–34.
Hornstein, H. A. (2014). The integration of project management and organizational change
management is now a necessity. International Journal of Project Management, 33(2), 291.
Miller, C. C., & Rampell, C. (2013). Yahoo orders home workers back to the office. New
York Times. Retrieved from www.nytimes.com/2013/02/26/technology/yahoo-orders-
home-workers-back-to-the-office.html.
Ong, W. J. (1982). Orality and literacy: The technologizing of the word. New York, NY:
Routledge.
Rainie, H., & Wellman, B. (2014). Networked: The new social operating system. Cambridge,
MA: MIT Press.
162 Communicating Project Management

Spinuzzi, C. (2013). Topsight: A guide to studying, diagnosing, and fixing information flow
in organizations [Kindle version]. Retrieved from Amazon.com.
Spinuzzi, C. (2015). All edge: Inside the new workplace network. Chicago, IL: University of
Chicago Press.
Suchan, J. (2006). Changing organizational communication practices and norms: A
framework. Journal of Business and Technical Communication, 20(1), 5–47.
6
CONCLUSION
A Participatory Rhetoric for
Development Teams

Poetry and philosophy are rare topics in managerial training, and business
schools seldom ask if spiritual development is central to their mission. It is no
wonder that managers are often viewed as chameleons who can adapt to any-
thing, guided only by expediency.
(Bolman & Deal, 2013, p. 433)

Throughout this book I’ve made the argument that participation is essential to
effectively communicate project management. It is an unapologetically humanist
view of communicating project work. This view is based on my claim that
project managers are writers who have an important influence on the social spaces
that surround development work. I’ve also argued that participatory communica-
tion leads to efficiency because it brings teams and stakeholders together in ways
that help to effectively coordinate information and collaborate on work using
intentionally participative communication strategies. Furthermore, participation
is important to practicing development methodologies, like Agile and Lean, that
project managers are often responsible for implementing in some form. Without
focusing on participation, methodologies become a template rather than what
they should be: a heuristic. So, the foundational concept that this book forwards
is that the role of participation—of writing communicative practices that make
space for stakeholders and individuals on teams—is an essential consideration
of successful project management.
As this book concludes, let’s take some time to review what has been covered
so far, highlighting some of the main points and arguments that surfaced across
the chapters.
164 Communicating Project Management

Reviewing the Chapters and Cases

Each chapter of the book has argued for the importance and relevance of
participation in project management. In Chapter 1 I take the position that
decentralization has changed how project management communication functions
as a practice. As well, I explain that widespread decentralization across organ-
izations that do development work requires people to participate in order to be
effective. Chapter 2 argues that given widespread decentralization of organizatio-
nal structures, the paradigm of project management has evolved because the
practices used by emerging methodologies require new ways of approaching work.
Project management as a practice cannot only think about efficiency and pro-
ductivity without accounting for the importance of people participating in
project work—in making space for teams to do so.
As the book moved into the case studies explained in Chapters 3, 4, and 5,
we saw a succession of ideas that built on one another, intended to offer different
looks at participation. In Chapter 3 we learned how project managers consider
a range of communication factors and strategies to make space for participation.
To assemble these factors and strategies, I wove together the results from
interviews with 14 people. In the end, the interviews produced seven overall fac-
tors: personality type, gender, cultural and linguistic diversity, building and
maintaining relationships, attending to psychological safety, development
methodology, and organizational and team culture. Each factor has a range of
strategies attached that would be useful for any project manager to carefully con-
sider, particularly as a way to understand how communication approaches are
experienced by individuals and teams.
Chapter 4 detailed two different experiences of making space for com-
munication as shaped by individual leadership values. The goal of the chapter
was to learn how project managers and leaders report on their experiences
communicating through samples of their interactions at work. An important
takeaway of the chapter is that how project managers and leaders approach
communication is contextual and situational. The chapter concluded that the
agency to make space for communication is awarded by an individual’s team,
and as a result, leadership is a kind of performance. The final case study points
out what happens when space is not made for participation: people make space
for themselves. The space people make for themselves is not always aligned with
an organization or a project, but it can also be highly creative and productive.
At the same time, this book has been careful not to overstate what a parti-
cipative communication paradigm offers project management. Sometimes
expedience is the most important aspect of a project. In Chapter 3, we learned
briefly about one project where a team was asked to launch a website ostensibly
overnight. In such instances, it seems quite plausible that a broad effort to extend
an invitation to participate may just mean time lost. Not all projects are shaped
or sized the same, so naturally the role of participation must be seen as flexible
 Participatory Rhetoric for Development Teams 165

too. I do not believe participatory communication is squashed in time-sensitive

circumstances, but it does seem to vary in its aims and purposes like all language
does. That is, the project manager may need people to participate with the
timeline—to be flexible with the approaches and reactive to the circumstances.
These are participatory moments of communicating as well, because the situation
dictates the response. The action instigates participation.
Another example of participation as constrained is demonstrated in how
The Gardener and The Chef in Chapter 4 communicated through the lens of
their own leadership values. Their communication work also showed how the
interactions swirling around project work can be constrained and complex. An
invitation to participate may be rebuffed or ignored. Both The Gardener and The
Chef faced circumstances where they invited participation and were surprised
by the response. The Gardener, for instance, popped up to participate in a
conversation and the group seemed disinterested in her contribution. The Chef
went to other project managers in the organization to ask for their participation
in designing a more useful system, but was shut down during those conversations.
These experiences were difficult for each of the participants to manage as
communicators. Eliciting participation is not always easy.
There are organizational systems that simply may not respond to a partici-
pative approach, so it must be contextually and situationally applied. Further,
as we saw in Chapter 5, the social space at work can be highly contested. While
the participants in this chapter made space for themselves, these spaces were
hidden, in some cases intentionally, from others on the team. So participative
approaches will not necessarily cure larger systemic communication issues at work,
but that fact also does not diminish the importance of a participative framework.
Rather, the need for communicators that know how to facilitate and make space
for people is even more important in complex organizations and institutions.
And it is a need that I think will grow as organizations continue to use automated
tools in place of project managers and development methodologies to substitute
for what Merholz (2015) called “critical thinking.”
To help visualize this broad overview, Figure 6.1 summarizes the main take-
aways from the cases in this book. Key to the figure is understanding that my
aim was to study participation from different angles, so I designed the case studies
to work together to provide different conceptualizations of communicating
project management. As Figure 6.1 shows, the studies moved from discussing
individual perceptions and built toward a team view of communicating project
management. The team view, in particular, shows how participation can be stable,
although somewhat nonlinear.
Particularly important in Figure 6.1 is nonlinear participation appears in team
situations. For the team at DTI, the nonlinear nature had to do both with the
disorienting nature of the reorg, but also with the emerging methods used to
perform project work. Some people on the team were resistant to new technologies
and it showed. While these folks still participated, they did so in less visible ways.
166 Communicating Project Management

FIGURE 6.1 Main Takeaways from Case Studies

Characteristics of Participative Communication

The end of Chapter 2 introduced what I called characteristics of participatory
communication. These three overlapping characteristics point out a framework
for thinking about a participative theory of project management that is based on
reflection. Figure 6.2 provides a visual representation of these characteristics. What
the characteristics show is three aims of communicating that project managers
engage in as they make space for people. Surrounding these aims is near constant
reflection over communicative activities, whether through drafting emails,
discussing challenges with others, or playing scenarios through their mind about
how someone might react to bad news. By drawing on these aims, project
managers would work through and strategize communication practices at work.
Visualizing the strategies in this way also shows how communication does not
always do all three things, but responds to the exigence of the situation by
considering a range of factors (like Chapter 3 showed). For example, in a moment
of emergency, the project manager’s emphasis might be on reacting to an issue
in a way that gets the project back on track, but then schedules a meeting in the
near future to discuss what went wrong. Each of these examples is making space
for participation in some way, but for varying degrees and purposes. Throughout,
the project manager may be asking questions like “Is this the best way forward?
Is there a better way? What will be the result if I make this choice over another?”
It is the productive overlap of the three characteristics that proves so useful to
project managers as they sort through all the unpredictable communication that
comes with project work.
Additionally, we saw examples of these characteristics in Chapter 4, where The
Chef, given his leadership values, seemed quite focused on the system being used
 Participatory Rhetoric for Development Teams 167

FIGURE 6.2 Participative Framework for Communicating Project Management

to manage the project. The Chef started with the system to work toward future
action and also to understand how to best react to project issues in the moment.
His communication work was not always that tidy, but his mental model
demonstrates that as his preferred approach. Nonetheless, there were examples
where The Chef focused on relationship-building activities because he was trying
to build a system for managing projects with the team. The Gardener, however,
tended to focus on future action. Her interests in the timing of work and
dependencies were very important for her contributions as a communicator. She
would introduce systems to manage that leadership value and communicate to
help her team build towards her goal to organize for the future.
In Chapter 5, the values of people on the team certainly clashed. As a result,
the participative approach varied across each participant. And, of course, the reorg
was directly influencing how people on the team chose to participate given the
ongoing change with the systems being used to manage projects. So, while parti-
cipants like Steve tended to be more reactive to information, Sheila was far more
systems-based in her communication approaches. Then again, Sheila was also
reactive in that she tended to comment on blog posts and customer-submitted
bugs. Don, meanwhile, seemed more invested in getting things done because of
dependencies for future projects, but also spent a great deal of time on the phone
working through project adjustments related to the reorg. In this way, his day
could easily be derailed as he helped others work through the reorg. Tammy
seemed to be more reactive and intentional in her approach, specifically as it
pertained to the reorg. It seemed to me she didn’t want to be viewed as non-
compliant, but that she also felt lost and would just respond to issues as they
168 Communicating Project Management

popped up. For me, Bob seemed most focused on future action in his approach
to communicating. He had a sense there was a vision for the future, and he was
working to make that vision a reality by developing design thinking workshops
and leading the team toward different ways of thinking about their work.
In breaking down each of the chapters to further illustrate the characteristics
in action, the cases seem to show how communicative actions are demonstrative
of values, but require a great deal of seemingly invisible reflection and strategizing
that is inherently done through interaction with people. For example, the
considerations and strategies in Chapter 3 were assembled through experience.
The values behind the communication approaches in Chapter 4 grew from train-
ing, identity, context, and situation. Even the use of email as a discussion tool
in Chapter 5 shows the importance of interaction behind the scenes of a project
before going on some sort of official record. These examples seem to suggest that
project managers often focus their communication on what Spinuzzi, Hart-
Davidson, and Zachry (2006) subjugated to “helper” genres. The authors contrast
“communicative genres,” or those “that are the focus of the individual’s actions,
that are created or modified” (p. 47) with “helper genres,” which are “nontrans-
actional” and help to “make the communicative genres work” (p. 47). For project
managers, the helper genre is actually more important because it is interactive
out of necessity. The project manager’s communication is not just transactional
because it is used to gain participation. Examples of helper genres in this case
might be information collected about how certain individuals respond to bad
news. Or, how some managers prefer visual charts to look. In other words, helper
genres are the informational tidbits project managers constantly use to learn how
to communicate in ways that make space for people. It is where they learn how
best to invite participation most effectively.

Project Management Communication as Designed Experience

A clear value forwarded by the approaches to communicating project manage-
ment in this book is positioning employees as participants in their work
experiences. If project managers communicate not just in transactional, but
participatory ways, then they view people on their team as central to the success
of project work. The project manager is positioned, in essence, as a user
experience researcher, working to understand how to adapt systems to people
rather than people to systems. Robert Johnson explains the logic behind the
approach:

User knowledge is always situated. By that I mean what users know about
technology and the experiences they have with it are always located in a
certain time and place that changes from minute to minute, day to day,
era to era. Hence, the complexity of understanding what users know grows
with each new experience or story that we tell or hear. At the same time,
 Participatory Rhetoric for Development Teams 169

however, there are connections and commonalities between these experi-

ences that help thread them into a visible, knowable tapestry.
(Johnson, 1998, p. 9)

As we saw throughout the book, project managers did seem to have strategies
they relied on that were quite well-defined in specific situations and contexts.
And, like any user researcher, they did not assume that their knowledge about
a team or situation was fixed. Further, their knowledge could constantly change
from project to project. It is no surprise that project managers use rhetoric to
strategize communication for people and teams because it helps make the situated
knowledge more visible.
In this way, project management benefits from thinking in terms of par-
ticipation for two discernible reasons. The first is that participation is stable.
It is going to happen across a spectrum of project-related activities and com-
munication events, even if in unexpected ways. At the same time, as Johnson
notes, participation can be nonlinear—and in development work it some-
times has to be. The nature of development work today is about learning and
discovery. On the outset of a project, it is difficult to predict what will be learned
as data is gathered and experiences designed. There can be checkpoints, or
check-ins, like we saw from the use of Scrum in Chapter 3, The Chef in Chapter
4, or with Steve or Don in Chapter 5, but what needs to be communicated is
situational. What a participative framework suggests over a transactional view is
that we write those involved directly in to the conversations—not just in the
moment, but in how we think about and structure the communication in that
moment.
While I also recognize that participation can be unpredictable, I see com-
municating in support of participation essential to how we move beyond the
development practices we’ve outlined over the past 20 years. In other words, this
book has not been about locating and describing another methodology or
framework on purpose. Rather, I freely have argued that tools and processes alone
won’t bring every voice that needs to be heard out into the open. Instead this
book points out the need for a better understanding of participation and what
seems to influence it. And it simply notes that agency in project work is at least
equally constrained due to social factors as methodological ones. Yet, project
management continues, in scholarship, practice, and teaching, to focus on tools
and processes rather than critically evaluating the design of its systems from a
communicative standpoint. That is, it’s time we recognize project managers as
writers.

Distributing Agency, Collectivizing Kairos

In today’s organizational networks, project managers are often hoping to
communicate in ways that seek to distribute agency across networks of people.
170 Communicating Project Management

We saw this happen in Chapter 3, when several of the interview participants spent
time soliciting feedback from people before, during, and after meetings. In
Chapter 4, The Chef and The Gardener both worked to find ways to support
others on the team, whether it was through developing a scheduling tool or
through scheduling meetings with upper management to clarify the goal of the
work. In Chapter 5 there were additional examples, particularly evident when
Don would take meetings to unblock people who were stuck in drama surround-
ing the reorg. In each case, the communication actions were meant to help
distribute agency across the team because it would lead to improved performance
outcomes in their view. That is, a participative framework for communicating
works to distribute agency across development teams for practical reasons as well.
Do not misunderstand, I am not suggesting project managers award agency.
Agency certainly exists independently of them. But, a project manager’s role is
often one where they coordinate the efforts of groups of people. One reason for
the distribution of agency is that project dependencies matter. That is, project
work is often kairotic—not just for individuals, but for teams. Teams must
collectively identify opportunity for seizing upon a specific finding as key to the
success of their project. In this way, coalescing agency and kairos are interrelated
aims of a participative approach.
When we talk about kairos, it is important to understand that it can be
understood in three ways. The first, as Carolyn Miller (1994) explained, is kairos
“combines both realist and constructivist understandings of situation” and how
these understandings relate to each other, particularly “the ways in which they
may be defined or constructed” (p. 83). In this way, kairos helps project managers
and teams understand the emergent urgencies of a project, and how these needs
define the project. For project management activities, kairos can help define the
work for a sprint. For example, when a sprint ends, development teams have
usually learned and/or delivered something (code, design, research) to the client.
After that moment, the team decides what they should focus on next. The end
of the sprint is therefore a kairotic moment because it helps teams to identify
what should the next sprint should focus on. In this way, kairos helps project
management activities be both reactive and intentional.
Second, Miller (1994, p. 83) suggested that kairos acts as a kind of marker
for moments of transformation, either as continuous or discontinuous. In this
designation, kairos helps project managers see to what extent there are patterns
in a given phenomenon or experience. Kairos can help both project managers
and teams find moments of transformation during a retrospective. As teams look
backward, they can identify key moments where opportunities were seized,
missed, or overlooked. We saw The Chef do this when he discussed the import-
ance of the team understanding the goal for their work. Without understanding
the goal, he felt the team would not seize opportunities for improving their
performance. These sorts of transformational moments can be identified as a way
for negotiating future action. If markers can be developed by a project manager
 Participatory Rhetoric for Development Teams 171

or a team to identify transformational moments, then kairos suggest they should

be prepared to seize those moments as or when they arrive.
Finally, Miller (1994) also explained that kairos has both a spatial and temporal
element. That is, “as an image of situation, it includes the potentialities of a given
time and place” (p. 83). Kairos’s spatial element can be understood as “a critical
opening” (p. 83), similar to the process of weaving or perhaps knitting, where
finding the correct opening is essential to finding or creating a certain desired
outcome. Miller called this opening, “a rhetorical void, a gap, a ‘problem-space,’
that a rhetor can occupy for advantage” (p. 84), and that these openings can be
“constructed as well as discovered” (p. 84). Problem-spaces exist as both oppor-
tunities for learning and planning or scoping project work for development teams.
For instance, teams recognize that researching the customer experience will
teach them where in their journey there is room for improvement. Those are
openings that help them improve experiences for people.
Yet, I believe the research in this book shows that identifying these key
moments as a collective clearly requires participation. Not everyone will parti-
cipate the same way in a Scrum. Not every check-in goes as planned. Email chains
can go awry. New technologies are ignored or used in ways people don’t expect.
A project manager can become a visible communicator in these instances, helping
teams discover “critical openings” for their own advantage. A good example of
this was identified by The Chef in Chapter 4, where he planned to implement
a fruit bowl strategy to ensure meetings would gain each individual’s undivided
attention. While readers may or may not agree with these strategies, it is clear
that The Chef was making space for participation—for identifying critical
openings and helping to distribute agency across the team. Indeed, the symbolic
act of closing laptops and handing over mobile devices is a direct action to help
create participative team experiences.

Toward a Theory for Communicating Project Management

The value of this book’s discussion of project managers as writers is that it helps
us arrive at a theory about the need for participatory communication in project
work built on better understanding the values and aims of helper genres. As
I concluded in the previous sections of this final chapter, participative approaches
are essential for today’s decentralized teams. They are already embedded in the
very work practices we’ve come across in this book.
No doubt, facilitating a participative communicative role at work is something
technical communication excels at, and is truly a place where our work as a field
adds value. In the context of development teams, I believe that project managers
must communicate to make space for people because an inclusive dialogue made
up of sometimes dissenting ideas and ways of working and thinking will lead to
efficiency and productivity. Furthermore, technologies and experiences that are
inclusive for different audiences must begin with creating more inclusive team
172 Communicating Project Management

environments. In other words, inclusivity has to be a 360-degree practice, and a

participative approach to communicating is one piece toward that effort.
I call this conceptualization or this theory a rhetoric of participation because
it is based on my view that developing valuable and effective experiences for people
cannot actually be achieved without inclusive team environments. As we learned
from the cases in each chapter, a lack of participation perpetuates stereotypes
and, worse, gives presence to certain exigencies while diminishing the impact of
others. That is, a version of project management that facilitates experiences for
certain people—for the loudest voices in the room—rather than in support of
everyone who offers insight to the team. Team experiences with communicating
cannot just be built around getting work done quickly without also discovering
how to learn together effectively. As writers, project managers have a role in
creating inclusive team systems that make space for others. Project communication
can be designed to be participative. In fact, I’d argue it has to be.

Final Takeaways
As the book concludes, I’d like to take time to offer some final considerations
for future research for researchers, project managers, and instructors.

For Researchers
The research in this book convinced me there are opportunities to do more
research on project communication around development methodologies. It
would also be useful to learn more about how methodologies are influencing
communication once they are extended online. How do individuals and teams
respond to always being on? How do people assemble resources to help them
learn and work in the ways they need to? These insights would prove valuable
as a next area of study.
I believe technical communication could also use more work on project teams
around psychological safety. Just like with the impact of development method-
ologies, like Agile and Lean, we aren’t keeping up with workplace practices in
these areas. Recent restructuring of Human Resources into employee experience
programs provides interesting insight into the future of the workplace. Work in
this area is focusing on creating enjoyable environments for working, but not
necessarily discussing hierarchies of influence and other important social factors.
These need to be discussed as workplace structures continue to evolve.

For Project Managers

Project managers are not “autonomous agents” to use Geisler’s (2004) language.
What that means is that the success of project managers often relies on the success
of the team. A participative approach to communicating fundamentally shifts
 Participatory Rhetoric for Development Teams 173

ways of working because it creates opportunities to be more reflective about

communication. If project managers are positioned as writers, as people who have
a truly visible impact on the social dynamics of work, then how they communicate
is a choice. The research in this book was not meant to be prescriptive, to tell
project managers how to communicate, but to start a conversation about how
participation manifests itself in the communication work that one must do as a
project manager. Considering the characteristics assembled from the case studies
in this book is a useful starting point, but in no way do these cases intend to
discuss every communication situation. So what happens when project managers
consider themselves writers? What can be gained? What new logics are presented?
What I am confident of is that communication is more effective when it is
participatory just as when products, services, and experiences are better when
they are developed with users.

For Instructors
While it is not my intention to review curriculum in project management in
this section, I do think there are some gains to be made from the research in this
book. That is, what would a course on project management look like if it focused
on teaching future project managers to be writers? What does that mean about
how we teach the genres around project work? Working to distribute agency is
a form of literacy essential to working as a collective to find moments of “critical
openings” in a project. Coursework in project management, just as certification,
does not often take on the social aspect of communicating. I invite instructors
to consider how to best teach students to be communicative in participative
ways. Teaching students to develop a clear leadership strategy and to understand
writing as a broad symbolic activity that includes writing project management
systems would be a useful starting point.
Approaching a course in project management with a focus on communica-
tion might critically reflect on some of the factors and strategies offered in
Chapter 3. Or, an instructor might ask students to decide if they are more of a
gardener or a chef as a leader (or maybe a bit of both?). And finally, the final
case would be useful as a case study about how change can be managed at the
project level. What could a project manager do to help make space for people
on the team? What sort of invitation to participate would prove to be both
instructive and productive for a project manager?

Conclusion
In the Introduction, when I asked “why another book on project management?”
my answer was, in part, to see what we could learn from positioning project
managers as writers. At the end of the book, I ask the second half of that question
that I’ve been thinking about all along. That question is, simply, “To what end?”
174 Communicating Project Management

My response to that question, just as the first, went unanswered for quite some
time as I wrote this book, shared drafts, received feedback, and revised the
ideas. Of course, there were a range of practical reasons for writing the book that
I’ve already covered, but when it came down to it, what exactly was I looking to
achieve? So, my answer is this: I wrote this book to start a conversation about
how to effectively communicate project management. I worked to introduce a
theory that emphasized a need for a participatory approach—a theory that could
be proven, disproven, complicated, and transformed. In other words, my goal
for writing the book was not to offer the final word, but to extend an invitation.

References
Bolman, L. G., & Deal, T. E. (2013). Reframing organizations: Artistry, choice, and leadership
(5th ed.). San Francisco, CA: Jossey-Bass.
Geisler, C. (2004). How ought we to understand the concept of rhetorical agency? Report
from the ARS. Rhetoric Society Quarterly, 34(3), 9–17.
Johnson, R. R. (1998). User-centered technology: A rhetorical theory for computers and other
mundane artifacts. Albany: State University of New York Press.
Merholz, P. (2015). Shaping organizations to deliver great user experiences. Presentation
at the Information Architecture Summit, Minneapolis, MN. Retrieved from www.
slideshare.net/peterme/designing-organizations-to-deliver-great-user-experiences.
Miller, C. R. (1994). Opportunity, opportunism, and progress: Kairos in the rhetoric of
technology. Argumentation, 8(1), 81–96.
Spinuzzi, C., Hart-Davidson, W., & Zachry, M. (2006). Chains and ecologies: Methodological
notes toward a communicative-mediational model of technologically mediated writing.
Paper presented at the SIGDOC, 43–50.
INDEX
Page numbers in bold refer to tables. Page numbers in italics refer to figures.
Page numbers with “n” refer to notes.
accountability 91, 155
active listening 87
Activity Theory 137–138
adhocracy 13
agency 45, 56, 65; distributing 169–171,
173; as invitation 100–101; in
participation 70–71; and positionality
110; postmodern critique of 70;
and reorganization 135, 138, 158
Agile 5, 10, 11, 28, 29–30, 31, 44, 50, 51,
94–95; coordination 33; decentralized
communication 34; estimation of
schedule 46; paradigm of 45; rhythm
of communication in 92
Agile Coaches 50
Aristotle 67
artifact collection 139
asynchronous communication,
disruptions during 147; email 154–156;
inconsistent adoption of project
management system 153–154; lack of
training in project management system
151–153
audience 55, 57, 120, 128; learning about
116; participation of 4, 12, 16
automated email 155
autonomy, and decentralization 25, 32
backchannel communication 80, 149, 154,
158, 159
behavior 23, 41, 51, 60; and leadership
109; modeling 114–115, 118
Brandeis, Louis 27
buy-in 6
centralization 21–22, 25–26; and scientific
management 27
change management 136; see also
reorganization
Chef, project manager as 122–123, 165,
166–167; assigning roles to individuals
and teams 124–125; clarification of
goals 125; empathy 126–127; keeping
people on task 123–124; leadership
values 123–127, 128–129, 129; mind
map of communication 127–128, 128;
responsibility to project 125–126
civic participation 12
coaching 9
code-and-fix mentality 29
collaboration 53, 57; methods, teaching
114–115, 120; vs. participation 5–6;
and reorganization 143, 144, 145–146,
148–150, 155; virtual 148–150
commodification of labor 44
common interests, and gender 78
communication managers 47, 110
communication plans 33, 41–42
communicative genres 167
consolidated activity system 156–158, 157
176 Index
content management 135
context, organizational 97–98
continuous critical perspective 53–54
control see decentralization
coordinate-and-cultivate approaches 25
coworking spaces 69
creative teams see development teams
critical openings 171
critical thinking 165
cross-functional teams see development
teams
cultural diversity 80; cross-cultural
disagreements 83; focusing
communication on project work
80–81; influence of national cultural
identity on meeting spaces 81;
intentional/reactive communication
103; interest in cultural difference 83;
patience and benefit of doubt 83;
unique relationship to culture 82–83;
see also linguistic diversity
Darwin Information Type Architecture
(DITA) 145
decentralization 11, 20–24, 40, 164; and
development methodologies 27–31;
of development teams 24–26; influence
on role of project manager 31–33;
of project communication 33–35
decision-making see decentralization
designed experience, project management
communication as 168–169
design thinking 67, 114, 145, 168
development methodologies 163;
adaptation of methodologies to
team/organization 94; adaptation of
methods to team/organization 94;
addressing methodological confusion
95; Agile see Agile; being strategically
agnostic 96; and decentralization
27–31; efficiency vs. impact 94;
and gender 52; as influence 94–95;
Lean see Lean; and paradigms 45–46;
Six Sigma 5, 31, 51, 55; and space for
participation 93–96; and systems-based
communication 104; uniqueness of
organizations, projects, and teams 96
development teams 11, 171–172;
decentralized 24–26, 32–33; diversity
in 66
diary studies 14, 111–112
digital management system 10
digital spaces 69–70
disruptions, reorganization-related 144,
159; during asynchronous
communication 151–156; during
synchronous communication 147–151
distributed cognition 9, 33
division of labor 33, 44, 142, 143–144,
145
DMAIC (Define, Measure, Analyze,
Improve, and Control) 31, 55
documentation 42, 142, 143, 145, 155
economic value, and organizational
change 136
efficiency 2, 4; in communicating project
management 41–43; criticisms of
43–44; and decentralization 26, 27;
and development methodologies
29–31; and ethics 52; vs. impact 94;
models/paradigm 10–11, 39, 40–47,
49, 52, 99–100; and participation
44–47, 49
80/20 rule 122, 132n4
email 86, 124, 150, 154–156, 158, 159
empathy: and leadership 119, 120,
126–127; and relationships 88
environment, working 8–9, 68–69
epistemology 48
ethics, and efficiency 52
Event-Contingent Reporting (ECR)
111
experience sampling 14, 111–112, 139,
154; data analysis methods 112; data
collection methods 111–112
extroverts 74
face-to-face communication 69, 86, 126;
and disruptions 159; and
reorganization 145–146, 149–150
Fayol, Henri 42, 43
feedback 103, 124; seizing moments for
92; sessions, inclusion in 117–118;
using organizational networks and
backchannels for 80, 85
feedback loops 31, 59; and safety 92;
using information communication
technologies to support 90
feminist theory, and participation 52–53
file sharing services 22, 36n1
flat organizational hierarchy 22–23, 23,
47
flexibility 29, 30; of information
communication technologies 76
follow-up after meetings 85

fruit bowl technique 125
future action, and communication 13,
58–59, 70, 167, 168; and building
relationships 103; and psychological
safety 103
Gantt charts 11
Gardener, project manager as 112–114,
165, 167; empathy 119; inclusion
116–117; leadership values 114–119,
128–129, 129; learning about team and
organizations 115–117; mind map of
communication 119–120, 121;
responsibility to team 118–119;
teaching effective collaboration
methods 114–115
gender 52–53, 78, 100, 101; adopting
gender neutral role 79; de-emphasizing
gender disparities 79; finding common
interests to build relationships 78;
identifying efforts to silence women 79;
intentional/reactive communication
102–103; using organizational
networks/backchannels to give and
receive feedback 80
Gilbreth, Lillian 27
globally distributed teams 24, 25, 35,
69–70
goals 126, 127; clarification of 125, 128
goodwill 58, 86
Google 26
grounded theory 71
helper genres 168, 171
heuristic, project management
methodologies as 53–55, 96
hierarchies of influence 98
hierarchy, organizational 22–24, 23,
116–117; protective qualities of 50
high-involvement management 12
ideas, circulation of 54
ideation 57, 67
identity: leadership 110, 129–131;
national cultural identity 81
inclusion 98, 171–172; and leadership
117–118, 120
industry standard practices 108, 109,
122
informal communication 84, 117–118
information, sharing/retrieving 150–151
information communication technologies
(ICTs) 13, 25, 47, 59, 86, 105n3;
Index 177
choosing 85–86; and decentralization
32, 33–34; and personality type 76;
and reorganization 147–148; and social
space 68–70; for supporting feedback
loops 90; as surveillance 91
Information-Development Life Cycle
42
infrastructure, and reorganization
147–148
innovation, and decentralization 22, 25,
26
intellectual background of team members
84–85
intentional communication 12, 56–58,
128, 167; and cultural/linguistic
diversity 103; and gender 102–103;
and personality type 102
internal processes, evaluation of 43
internet 22, 25; lag 148
interviews 14, 71, 139
intrapreneurs 26, 58
introverts 74, 76, 77, 100; and
information communication
technologies 76
jam sessions 8
jelling 8, 9, 112–113
kairos 169–171
Kaizen (Lean) 34, 43
Kanban Board 34, 34, 86, 114
kickoff meetings 93
labor: commodification of 44; division of
labor 33, 44, 142, 143–144, 145
language 137–138
leadership 10, 108–110, 164, 165,
166–167; behavior 109; Chef 122–128,
128, 129; experience sampling 111–112;
Gardener 112–120, 121, 128–129, 129;
identity, as rhetorical performance 110,
129–131; implementation of values
130; personality 91, 109, 130;
philosophy 14, 108, 129; and
positionality 110; shared 35
Lean 5, 10, 11, 28, 30–31, 51, 95;
communication plan 33; decentralized
communication 34
learning 29, 30, 33, 35; about audience
116; about people’s intellectual
background 84–85; about team and
organizations 115–117; mutual-
learning 51; to talk less 77
178 Index
linguistic diversity 80; focusing
communication on project work
80–81; giving time to prepare and
respond to requests 81; intentional/
reactive communication 103; patience
and benefit of doubt 83; translation
81–82; using plain language 82; see also
cultural diversity
loss avoidance 124
loyalty 118
management paradigms 41
management studies 40–41
market trends, and decentralization 26
Mayo, Elton 43
media lab 8–9
meetings 74, 103; agendas 2, 90;
availability of project managers after
89; checking in with people before and
after 86; checking people’s perception
of 85; influence of national cultural
identity on 81; kickoff meetings 93;
meeting and talking outside of 88;
open-meeting policy 88; retrospective
29, 31, 34, 43, 85; structure of 89–90
mental models, leadership 112
methodology see development
methodologies
mind map 119–120, 121
Minimal Viable Product (MVP) 30
miscommunication 83
mobile technology 25, 68
mobility, and information
communication technologies 34
moments of transformation, and kairos
170–171
mutual adjustment 13, 57, 60
mutual-learning 51
national cultural identity 81
networked individualism 13, 34–35, 58
nonlinear participation 158–159, 165, 169
norms, team 117, 118, 120
observations (data collection) 138
one-on-one activities 149–150
online communities 22, 36n1
ontology 48
open-meeting policy 88
organizational change 142–144; as activity
137–138; and project management
136–137; see also reorganization
organizational charts 22–24, 23
organizational culture 59, 96–97;
hierarchies of influence 98; inclusion
98; and leadership 116; organizational
context 97–98; removing silos 99; and
systems-based communication 104
organizational management 11
organizational networks 13, 32, 35, 47, 56,
110; for feedback 80; as sounding
board 85
organizations 13; structure of 21, 22
pace and space offense (basketball) 20–21
paradigm, definition of 41
participation 12, 43, 44, 47, 163; vs.
collaboration 5–6; and effective
communication 55–60; and efficiency
44–46, 46–47, 49; and feminist
thinking 52–53; and Participatory
Design 51; project management as
methodology 48–51; project
management methodologies as
heuristic 53–55; and reorganization
134, 135, 138, 145–150, 153, 156–160,
167; space for see space for
participation; stable/nonlinear
158–160, 169
Participatory Action Research 54, 55
participatory communication 12–13, 28,
55–60, 163, 164–165, 171;
characteristics of 56–60, 166–168, 167;
space for participation 101–104, 102
Participatory Design 12, 51, 138
patience, and cultural diversity 83
perception of project manager 70; and
leadership 120
personality, leadership 91, 109, 130
personality type, and space for
participation 74; communication styles
and approaches vary by person 74, 76;
effects, self-awareness of 77;
information communication
technologies 76; intentional/reactive
communication 102; learning to talk
less 77; and safety 91; using role-play to
disarm people 77
place 66–67; see also space
plain language 82
Podio 144
positionality, and leadership 110, 129, 130
power: and decentralization 24, 25, 36;
and digital spaces 69–70; and project
management methodologies 51, 53
prescriptive leadership 112, 130

problem-spaces 171
process improvement 31, 43, 95
project 9–10
projectification 32
project lifecycles 10, 42
project management activities 10, 24–25
Project Management Body of Knowledge,
The (PMBOK) 32, 42
project management system 157, 158;
inconsistent adoption of 153–154;
training in 151–153, 159
project manager 10
project roadmap 86
prompts 85
psychological safety 9, 89, 101; availability
of project managers after meetings 89;
changing meeting structure 90;
conclusions of team members 90;
creating dependable rhythm for
communication 92–93; developing
clear structure 89–90; experience,
understanding 90–91; feedback loops
92; and future action 103; and
information communication
technologies as surveillance 91; kickoff
meetings 93; leadership personality 91;
and reorganization 135, 138, 157;
seizing moments for feedback 92; trust
91; using information communication
technologies to support feedback loops
90
purist arguments 44, 95
radical possibility 131
reactive communication 12, 56–58, 70,
167; and cultural/linguistic diversity
103; and gender 102–103; and
personality type 102
recognition for hard work 87
relationships, building 84; active listening
87; checking people’s perception of
communication/meeting 85; choosing
information communication
technologies 85–86; embracing
unscripted moments 84; empathy 88;
face-to-face communication 86; and
future action 103; across gender 78;
learning about people’s intellectual
background 84–85; meeting and
talking outside of meetings 88;
monitoring workload 87; notifying
people affected by project changes
86–87; recognizing good work publicly
Index 179
87; time management 88–89; using
organizational networks as sounding
board 85
reorganization 134–136, 165, 167; activity
system, participation in 156–158, 157;
artifact collection 139; asynchronous
communication, disruptions during
151–156; and collaboration 143, 144,
145–146, 148–150, 155; data analysis
139; dialogue with workers 136, 137,
143, 157, 158; division of labor 142,
143–144, 145; experience sampling
139; interviews 139; observations 138;
organizational change as activity
137–138; participation and
communication 145–147; participation
as stable, nonlinear, and productive
158–160; and project management
136–137, 144–145; research methods
138–139; research participant profiles
139–141; roles 143; serendipitous
communication 149, 159–160;
synchronous communication,
disruptions during 147–151; technical
documentation 142; trust 143, 144;
uncertainty of employees about 143;
virtual interactions 144–145
resistance to organizational change 138
responsibility, and leadership: to project
125–126; to team 118–119, 120
retrospective meetings 29, 31, 34, 43, 85
rhythm of communication 92–93
Richards Group 22
role-play 77, 102
roles: assignment, and leadership
124–125; and reorganization 143
safe space 1, 89, 90–91, 101, 127
safety 1, 14; see also psychological safety
Scandinavian Design 12, 51
scientific management 4, 11, 27, 41
Scrum Masters 50
Scrums 29, 31, 34, 45, 90, 93, 94
self-awareness of personality type 77
self-organization 11, 22, 26
shared calendar 113–114
shared experience, and leadership 110
shared project management 30
SharePoint 153–154
silos 99
situated knowledge 168–169
Six Sigma 5, 31, 51, 55
social coordination 12, 46–47
180 Index
social networking 145
social space 68, 118, 163, 165; extensions
of 68–70
software development methodologies 28;
Agile 29–30; Lean 30–31
sounding board, organizational networks
as 85
space 14; decentralization see
decentralization; and development
methodologies 45, 46; and digital
technology 34; and kairos 171; and
place 66–67; social see social space
space for participation 47, 51, 65–66, 164;
agency 70–71, 100–101; attending to
psychological safety 89–93; building
and maintaining relationships 84–89;
communication factors and strategies
73–74, 75–76; cultural and linguistic
diversity 80–83; development
methodologies 93–96; evaluating 66;
extensions of social space 68–70; future
action 103; gender 78–80; implications
99–101; intentional and reactive
communication 102–103; and
leadership 117, 120, 128–129; making,
as business interest 100; organizational
and team culture 96–99; outcomes for
participatory communication 101–104,
102; paradigm in transition 99–100;
personality type 74, 76–77; and
reorganization 158, 160; study
description 71–73; study participants
72–73, 72; systems-based
communication 104; theorizing 66–68
sprints 29, 31, 33
stand-ups 29, 94
surveillance, information communication
technologies as 91
synchronous communication, disruptions
during: infrastructure and information
communication technologies 147–148;
sharing and retrieving information
150–151; virtual collaboration 148–150
system, definition of 59
systems approach 22
systems-based communication 13, 59–60,
70, 167; and development
methodologies 104; and organizational
and team culture 104
tacit knowledge 51
Taylor, Frederick 27, 43
Taylorism 44
team culture 96–97; hierarchies of
influence 98; history of team 97;
inclusion 98; removing silos 99; and
systems-based communication 104
technical communicators, project
managers as 4–5
technical documentation 142, 143,
145
technical rhetoricians 4, 16
temporary teams 32, 47, 58, 59
terministic screens 130
Theory E 136
Theory O 136
Third-Generation Activity Theory 137,
137
Third Teacher 68
ticketing systems 10, 31, 32, 142
touchpoints 126
traditional organizational hierarchy
22, 23
training in project management system
151–153, 159
translation, language 81–82, 83
trust 58, 59, 84, 88; and reorganization
143, 144, 157; and safety 91
“20% time” program (Google) 26
uncertainty of reorganization 143, 157
United States railroad industry 27
usability testing 149
US Air Force 27–28
user knowledge 168–169
video chat 144–145, 146, 148, 149
virtual collaboration 148–150
virtual desktops 148
virtual sticky notes 149
Waterfall 28, 95; rhythm of
communication in 92
Weber, Max 43
wikis 154
work–life balance 35
workload, monitoring 87
workplace change see reorganization
workplace design 29, 68
workplace networks 11, 80
writers, project managers as 2, 3, 49,
171
“Yes, and . . .” approach 57, 61n3