Month: February 2021

It’s not what you think.  It’s a framework for understanding the relationship between who you communicate with, the role they have, and the aspects of a project.  The RACI name comes from the roles that someone can have: responsible, accountable, consulted, or informed.  It’s typically a grid, with the columns as the people and the aspects of the projects as the rows.  The intersection contains a single letter that represents the role (or roles) the person has.

People

The columns of a RACI chart are the people that you’re interacting with.  Sometimes, this may be a specific person’s name, but in most of the cases, it’s likely that the columns will be labeled with a small group of people.  For instance, you might have a column named “engineers” and another named “marketing.”

Aspects

Projects of any scope and scale are not one single thing to be done.  There are always steps in the process or parts of the deliverable that must be done.  The aspects that form the rows of a RACI chart are a meaningful way to break the overall project into smaller parts.  While in many cases, the way that you break down the RACI chart will match the work breakdown structure of the project, it may be that the way you need to think about responsibility, accountability, consultation, and informing does not directly match the work breakdown structure.

The Intersection

What’s powerful about the RACI chart is the capacity to communicate the role of the person or group for an aspect of the project.  Let me briefly summarize each of the roles – slightly out of order from the acronym to make it more understandable.  They are:

• Accountable – This is the person who will ultimately be held accountable for whether the aspect of the project is successful or not. Said differently, if this goes spectacularly wrong, who is at risk of being fired or demoted?  Generally, this role can only be used once for a row, and it’s always assigned to a person and not a group.
• Responsible – The responsible person or group are the ones doing the work. They may or may not be held accountable, but someone must do the work, so they’re identified as responsible.  There are generally very few responsible parties for a given aspect.  As with accountability, a single responsible party is ideal.
• Consulted – The consulted group are neither accountable nor responsible but are important to the decision-making process. Their input is needed even if they don’t have the final say.  It’s common to have several people consulted on an aspect.
• Informed – Those who are informed are being made aware of progress on an aspect of the project, but they are not being given the opportunity to directly provide input on the item. Even more people are typically informed but not consulted.
• None – If the intersection between person and aspect is left blank, then there is no communication about the item to the person or group for that aspect of the project. Many of the intersections between people will remain blank.

The Clarity

RACI charts represent the understanding of the project team about everyone’s role.  It helps those who are being informed to realize that they’re not going to be consulted for input on an aspect.  This can help reduce misunderstandings that would typically occur later in the project and create hurt feelings.

While it may be frustrating to address the concerns about who should be accountable, responsible, consulted, and informed up front, the down-stream savings are well worth the effort.

The Evolution

RACI documents tend to be evolving documents in any project – including change projects.  They start with what is known, and additional detail is added as new stakeholders are added to the people columns and new aspects are added to the rows.

A fundamental question about the way to approach change in an organization is to decide whether you’re going to change the person themselves or whether you’re going to change the environment the person finds themselves in.  While people tend to take up arms and defend their position, it may turn out that the answer lies in the murky ground between these two extremes.

Changing Other People

In self-help and recovery circles, trying to change or “fix” other people is a huge red flag.  The idea is that if you can’t cope with life with others being who they are, then it’s probably you, rather than them, who must be wrong.  However, this obscures a very accurate message that the only person you can change is yourself.  There are jokes about changing others such as, “How many counselors does it take to change a lightbulb?”  The answer is “One, but the lightbulb really has to want to change.”

People come to counselors, therapists, and psychologists because they want to change – or at least they want to feign desire to change to support someone else’s hopes, whether that be a family, a friend, a fiancé, or a judge.  However, the rate of personal change, even with professional assistance, is astonishingly low.  (See The Heart and Soul of Change, Science and Pseudoscience in Clinical Psychology, and Change or Die for background and stories.)  The truth is personal change is difficult and trying to change others is harder.

However, the kinds of fundamental changes that people are trying to make, with help and on their own, aren’t exactly the kinds of behavior changes we’re looking for in an organization.  Rarely are their deep-seated childhood issues about whether to use a fax machine or email.  So, while changing other people can be very difficult, some changes are easier.

In the middle are the kinds of changes that most organizational change efforts are targeting.  Abstract concepts like concern for the organization and engagement are the sorts of things that change efforts typically seek, but because these are amorphous concepts that have no real specific behaviors, they’re often difficult to accomplish directly.

While it’s true that an organization can only change by individuals changing their behaviors, it’s also true that often we’re not sure what behaviors we’d want people to change to accomplish the organizational change.

Changing the System

Changing the system is difficult but for different reasons.  The rise of agile methodologies has elevated the awareness that you can’t plan for everything.  (See Agile Change Management for more on agile.)  Eisenhower said that “no plan survives contact with the enemy.”  Plans can never be good enough.  Despite that, we still approach changing the results by changing the system.

There are reasons to consider the system impacts of change, including the kinds of results you see as the system iterates.  (See Model: Systems Thinking for more.)  However, it’s equally frightening to recognize that organizational changes are often wicked problems.  (See Model: Wicked Problems for more.) Systemic changes often cause unintended consequences that can’t be foreseen.  (See Diffusion of Innovations for more.)

However, we’ve learned that sometimes changing the system can powerfully change the individual.  (See The Behavior Function.)  We can change the expectations and metrics of the system, and this can change the way that people behave and therefore the results the organization sees.  (See The Tyranny of Metrics for more on the impacts of metrics.)

Not Either but Both

The best chances for change success are neither to focus exclusively on the person nor exclusively on the system.  By investing in improving the functioning of individuals, you create more organizational resilience.  (See Emotional Intelligence, Resilient, and Grit for the impact of personal growth on organizational resilience.)  However, because individuals are so notoriously difficult to change, it’s necessary to leverage systemic levers to encourage – rather than discourage – the right behaviors.

The world of change management owes a lot to Kurt Lewin.  He’s responsible for the idea of change as three steps: unfreezing, change and transition, and refreezing.  More importantly, his research into the motivation of individuals left us with topological maps and force fields that led to an elementary understanding of human behavior.

Topological Maps and Force Fields

Lewin was particularly invested in the application of mathematical and “hard science” techniques to the emerging field of psychology.  He recognized that some forces increased with closer proximity and that resistance may not be a lack of motivation towards the goal but a set of countervailing forces pushing back against the goal.  In organizational change, we see this all the time as the organization resists the change and attempts to resume the status quo.

In the exploration of how people are motivated, Lewin arrived at a simple – despite being opaque – function to describe human behavior.

Behavior = f(Person, Environment)

The simple formula relates that behavior is a function of both the person and the environment (including the situation) they’re in.  While fundamental attribution error causes us to believe that everything should be assigned to the character of a person, Lewin invites us to look at the environment.  (See Thinking, Fast and Slow for more about fundamental attribution error.)  We know from subsequent research that strikingly little is hardwired into our genetics.  (See No Two Alike for more.)

While there’s no elaboration on how these two variables interact, the simple awareness of the fundamental truth that behavior can be shaped by the environment and simultaneously resisted by a strong will creates the opportunity to see that you can encourage behaviors, thereby making them more prevalent.

Nudges

We think that we’re the masters of our world and that we make our choices free of influence.  From the results of movie theatres that used subliminal messaging to encourage popcorn sales to the marketers in supermarkets getting us to buy the higher-margin items and the employers who encourage healthier eating patterns by changing the kinds of snacks they provide, we’re silently being shaped into behaviors that others want us to make.  (See Influence and Nudge for examples of how others are shaping our behavior.)

It’s as if they’re speaking directly to something below our consciousness.

Elephant, Rider, and Path

Jonathan Haidt came up with a basic model of how our reason and rationale is like the rider sitting on top of an emotional elephant.  If the rider is paying attention and the elephant isn’t particularly motivated, all is well.  However, when the rider loses focus or the elephant becomes particularly triggered, the elephant is clearly in control.  If neither the rider nor the elephant is focusing, then they’ll lumber along the familiar path.  (See The Happiness Hypothesis and Switch for more on the model.)

Daniel Kahneman expresses it slightly differently in Thinking, Fast and Slow as System 1 – the automatic responses – and System 2 – or rational thought.  He says that System 1 can lie to (or mislead) System 2 and thereby skew the results.  So, while your rational rider thinks it’s making reasonable decisions, it could be that System 1 is deceiving your rationale to get to the decision that it wants.

Together

The behavior of an individual is therefore sometimes a result of their conscious control – the person part of the equation.  Behavior is sometimes, therefore, person-led.  Conversely, there are many times when behavior is the result of the easiest path put before the elephant and rider, and therefore the environment is the primary driver of behavior.

Ultimately, behavior doesn’t have one cause but two – and they relate to one another in unknown ways.

Like any movement that becomes popular, agile has become more buzzword and less meaning than was originally intended.  When 17 software developers met in Utah, they didn’t set out to change the world of software development or change how projects are managed.  They came together to share a common passion for making software development more successful, because the industry had a dismal record of failures – much like change management today.  (See Why the 70% Failure Rate of Change Projects Is Probably Right.)  The heart of a desire for successful projects can be applied to any project – including change projects.

More This, Less That

The Agile Manifesto lays out what the group believed in a set of four principles in the form of conflicts:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

They’re careful to indicate that both are valuable, but the things on the left are more valuable.  Change managers will recognize that all but the second are general statements that apply to change projects as well as software development projects.

Boiling down the statements to an even more basic level, there are two keys to take away.  First, people are important, and they can’t be removed from the process.  Second, we can’t plan for every contingency; we must react to change.

Heuristic, Chaotic, and Wicked

We now live in a world where we’re not following the single formula that leads to the right result.  Instead, we’re working with a set of heuristic processes that lead us to the right location.  Richard Florida called for The Rise of the Creative Class back in 2001 when he recognized the work that was being done was not following a single process.  Before that, in 1970, Alvin Toffler wrote the book, Future Shock, where he coined the term “future shock” to mean a degree of change that people couldn’t cope with.  About the same time, Horst Riddle and his colleagues started speaking and writing about wicked problems and the nature of unsolvable problems.  (See Wicked Problems for more.)

By all accounts, we’ve entered a world where we simply cannot expect that we can plan for all the situations we find ourselves in.  Instead of rigid planning, we find the need to have more agility and resilience in our planning progress, and that means continuously readjusting the course of our projects.

Iterative

While the original “waterfall” software development lifecycle was designed to be iterative, few people did it that way.  They instead tried to plan everything and get the whole software developed in one project cycle.  Agile turned this on its head by removing the big, upfront planning cycle and instead replacing it with a vision of the end target and enough planning to take the initial steps towards that goal.  After each cycle, a review is preformed to capture learning and readjust the trajectory so that the end target stays in focus.

In an iterative model, the goal is to deliver as much to the organization as quickly as possible.  It has developers working on the things that add the most value to the organization first, so even if the project is cancelled early, there’s a working solution that delivers value.

Applying Agile Methods to Change

Agile can be directly applied to change projects by simply mapping out the end target and then only enough of how to get there that can be accomplished in a few weeks.  At the end of that time, the process comes together to evaluate what was learned and what the next steps might be.

Criticisms

Agile isn’t without critics.  They claim that the process is more wasteful than a waterfall project, citing the countless missteps that happen in the process.  These criticisms are true – but they’re weighed against the additional planning work that may or may not have identified the problem and all the downstream effects.  The net-net for most organizations is that agile approaches to software development – or change – mitigate their risk and don’t cost substantially more than a traditional project management approach.  Most organizations decide that the additional risk reduction is worth the cost.