Heidi Hess von Ludewig
In a scene from Game of Thrones (the third episode of the seventh season, to be precise), Tyrion Lannister is talking to the King of the North, Jon Snow, about the army of zombies approaching from the North, beyond the Wall. Tyrion's evil sister is sitting as Queen of the Seven Kingdoms and John is wondering why people don't listen to his warnings.
"People's minds aren't made for problems that large," Tyrion says.
"White walkers, the Night King, army of the dead—it's almost a relief to confront a comfortable, familiar monster like my sister." Sometimes, the best way to succeed is not to confront the entirety of the issue.[^leadership-game-thrones] The same is true about creating change in an organization. Because change is difficult, it can feel insurmountable in any organization (especially a mature or large one). Both problems and solutions can feel too big or broad for us to address. We don't often know which steps to take for a number of reasons, and we might feel a lack of support, fear of failure, or uncertainty about where to start.
But change doesn't have to be big. And if we're trying to change without the context of an urgent situation, then I would assert that change shouldn't be big: Change just needs to be effective, because we can build on every effective change, one at a time. Rather than try to tackle change at an intimidating scale, we must learn to spark change at a level much smaller, more modest, and more manageable—like with individual projects.
This chapter describes ways that we can create cultural change one project at a time—rather than "boiling the ocean" to warm our organizations for culture change. When we use our projects to spark change and start to succeed, others can emulate us and transform how they work too. In fact, that is how grassroots movements start: through showcasing the ability to change and demonstrating how change works at the small scale. There's no difference between grassroots movements inside and outside the workplace; the mechanisms are the same, as I will explain.
The first thing to do is differentiate between the "how" of change and "what" of change. Business systems have similar definitions of "what" needs do be done—manage work, make profit, sell products or services, pay people, provide benefits, etc. "How" those things are done is the difference between open and conventional organizations.
Open organization values showcase how organizations operate—the principles that influence how they run to increase participation, help information flow easier, and generate innovations. Transparency, for example, describes how open organizations communicate (if they aim for authenticity). Inclusivity describes how open organizations promote participation among members. The values and beliefs are part of the foundation that makes a culture—yet they are not, themselves, culture.
Culture is a set of values and beliefs enacted through behaviors and actions. We "know" what a particular culture values because of how people living in the culture do things. For example, how do people discuss things (or how don't they discuss things)? What is salient or available as a topic of conversation? How do they celebrate traditions, with whom, and how frequently? In the case of workplace cultures, these questions transform into ones like "How are meetings run?" and "Who's included?" and "What happens when someone expresses a dissenting opinion?"
Our answers to those questions help us infer the values and principles that motivate observable behaviors, because the enactment of beliefs and values in the form of behaviors is how cultural values get instantiated. If we want to better understand a culture, we can assess social behaviors and infer values from them in order to more fully understand a culture's beliefs. We can in other words, reverse-engineer our understanding, starting from behavior and ending at values. However, if we want to change a culture, then we need to use forward-engineering to figure out ways to change those behaviors and actions in order to change beliefs (yes, I said that correctly; you change behaviors first). That means we need to look for simple but concrete ways to enact open organization values in our everyday work, and one way to do that is by focusing on specific projects.
Project management is a "what"—what to do to organize and perform the work—and, if done well, it has the ability to connect the "what" of behaviors with the "how" of beliefs and values that form open organization culture. As a sanctioned methodology, project management is likely already something that an organization and its actors value as a way to work, so it provides a ready framework for adopting the "how" of desirable cultural values.
The choice of project management methodologies certainly matters; each has its drawbacks and benefits. But what matters most is how activity gets accomplished. The Open Organization Definition (see Appendix) describes the principles (*how *something might be done) that can inform all kinds of work at different levels of an organization, regardless of whatever particular techniques or behaviors an organization enacts (what they choose to do).
For example, Agile is often aligned with open organizational thinking because these schools of thought share similar principles. We might consider them corresponding "cultural artifacts." Agile (just like its dramatic foil, Waterfall) is a project management method—a set of concrete behaviors and techniques. Those behaviors and techniques both reflect and perpetuate a set of values that underpins them (see Figure 1), which, by and large, are open values. In many organizations, a variety of methodologies co-exist, because over time different teams have adopted different styles of working; intra-organizational groups have differing abilities to adapt to particular methods (not every team can iterate or use project management tools), and each methodology has drawbacks (e.g., the "technical" debt of Agile).
Although Agile naturally supports open values, multiple project management methods can and often co-exist and are beneficial when the same set of values defines and drives them.
{insert Figure 1} Figure 1: Relationships between open organization values and Agile principles
Each stage of a project management method encomapsses activities that leaders can use to promote the "how" of open organizational culture.
There are generic stages (meaning you'll find them in just about any methodology) but their specific enactment will depend on the methodology you've chosen (e.g., Agile's short cycles will manifest differently than Waterfall's longer cycles).
Those general stages are:
- Initiation
- Planning
- Executing and Controlling
- Closing
Let's examine each one.
In the initiation stage of any project, people seek to outline information about the launch of a project. This is the phase in which people address questions about the benefit of the project. It usually includes activities like stakeholder analysis, benefits analysis, deliverable identification, and risk identification. This is typically a more "internal" part of the project methodology, meaning that project sponsors and key leaders are engaged in this work.
The initiation phase of a project is a stage in which leaders can increase transparency, inclusivity, and collaboration by communicating early about project details and team membership, and by sharing prior knowledge and information to cultivate an early project community. For instance, leaders sometimes wait until projects are clearly defined before talking about them, delaying presentations in order to provide answers to any questions that associates might have—but that can mean that no one really knows about the project and that the project is defined to a point at which it's not inclusive of feedback. So sharing project details often and early during the initiation stage means leaders might take some questions for which they don't have answers, but they benefit both from having ideas and feedback circulate, and from building associates' commitment by including them early.
In the planning stage, project details become more defined and clear.
It's a great moment to forward-engineer an open culture, because decisions about what and how most often occur during planning. Using the planning stage as a platform for change increases buy-in, because it helps provide early context for team members, effectively "bringing them along" on your vision (rather than having to explain it and convince them later).
This stage focuses on determining: project requirements, constraints, and assumptions; project schedule, scope, and resources; roles and responsibilities among and between the various teams and members; communications plan; quality management plan; and change management plan. It also includes review and signoff of plans and documents and a project team kickoff.
The exciting part of this stage is the ability to discuss and compromise that it affords. Leaders shouldn't be afraid to let team discussions take them to new places. This is where "the road gets paved." How you enact the process (the values that will guide what you do) get sedimented here. Be inclusive and collaborative by supporting fluid role definitions. Make communication plans broad and transparent. Focus on (and encourage) interlock and the development of a broader sense of community between organizational teams is a focus and encouraged.
The Open Decision Framework is a resource you can use to help define how open values will manifest in the ways a project team will make decisions.1 It's not a prescriptive mechanism that teams must aggressively follow; it's something project managers and teams can adapt to their own situations and different types of decisions (i.e., teams might manage short-term technical decisions differently than strategic technical decisions, or might have different guidelines about decisions that involve change or risk mitigation).
Plans laid in the prior stage get performed, evaluated, and continuously improved in this stage. Task execution, plan enactment, performance measurement, implementation of changes and corrective actions, risk monitoring, quality measurement, and relationship maintenance (between team, stakeholder, sponsor) are key.
Changes and corrective actions can provide opportunities for promoting adaptability. Increasing transparency in reporting and communication can increase community-building and engagement between project groups. And including external groups in a consultatory way during change management and decision making can lead to greater inclusivity and knowledge sharing, ultimately aiding problem solving and solution building.
Closing can apply to an entire project, a phase, or an iteration. It includes performance measurement, project review, and transition planning. Providing archives in a public way helps to make the success and learning outcomes of the project more transparent. Feedback techniques such as retrospectives could include all project groups including customers and sponsors. And, by all means, when closing a project record yourself as the leader so associates can connect with you with questions they have about the work you did.
Projects are a unique opportunity to begin transforming to an open organization culture one step—one activity—at a time. Project management methodologies describe the activities that a team performs in order to organize and manage complex cross-team and cross-organizational work. By defining "how" those activities are performed, we can begin to infuse our work with open values, no matter the kind of organization we find ourselves in.
Defining "how" is not the only task, of course: Accountability for enacting the values that a project team has defined is the responsibility of everyone on the project, and needs to be a focus in every moment that the team performs its work. Without the team engaged in working toward an open organization, culture change won't be possible.
Starting small, aligning how with what, is a manageable way to start making those changes.