To me this is a provocative phrase, “reduce the cost of change.” Highsmith and Cockburn are thinking about the technological costs, which are the kinds of things that Agile is explicitly designed to address. I believe this idea can reach much farther. When the new software is delivered, or the new process is introduced, or the new plan for expansion is announced or, let’s admit, when the new cutbacks are detailed, there are human costs that play out over weeks or months. It follows then, that whatever we can do to reduce those costs will increase our organizational agility.

In the case of software development projects, the Agile practice of including business stakeholders in the development process can certainly mitigate these impacts. But even with that care-taking, there will still be some communication planning required between the participants in the projects (the innies) and those who just keep doing their ordinary jobs (the outies).

Plenty of us have trouble with change. And so, if we find ourselves in organizations that are undergoing a change of direction or any kind of disruption, might it not be an appropriate question to ask, what can I do to reduce the human cost of change?

This reminds me of the topic of resilience I touched on back in March. Then, I quoted from a Harvard Business Review article on “bouncing back from adversity.” What I didn’t include in March, but I’ll add here, are some of the focusing questions that the authors, Joshua D. Margolis and Paul G. Stolz, give to point teams forward in trying times.

• Who on my team can help me, and what’s the best way to engage that person or those people?

• How can I mobilize the efforts of those who are hanging back?

• What strengths and resources will my team and I develop by addressing this event?

• What can each of us do on our own, and what can we do collectively, to contain the damage and transform the situation into an opportunity?

Do you think these are helpful questions?

NGTS Teams working on "Whole Brain" exercise

To prepare the teams for the work ahead and to give them an orientation to transformational thinking, the senior executives overseeing the NGTS initiative asked Katharine Mitchell, an Internal Organization Development Consultant, from the Center for Organizational and Workforce Effectiveness (COrWE) at UC Berkeley, to facilitate the primary discussions.

Mitchell led everyone through a series of exercises using the “Whole Brain Model,” suggesting that what the team members would learn about each would “lay the groundwork for effective work as virtual teams.”

Turning to the transformational change topic, Mitchell had given as preparatory reading the very interesting “Awake at the Wheel: Moving Beyond Change Management to Conscious Change Leadership.” This article argues that, when environmental forces have changed dramatically, you have to abandon mere change management and move to transformational thinking, a “fundamental shift in mindset, organizing principles, behavior, and/or culture, as well as organizational changes, all designed to support new business directions.” Mitchell led a conversation about what is and isn’t transformational change, as opposed to merely developmental or transitional change. One person remarked “Maybe transformational change can’t be managed.”

After lunch, it was my turn to provide these teams with a quick overview of project management.  I said, when you are heading into the unknown, you may not be able to manage every aspect, but you can provide some markers for yourself. You can keep a record of what you have done, and you can communicate with your sponsor in order to ask for help when needed.

I have been under the gun more times than once, and I had thought about what the minimal requirements for tracking status, avoiding pitfalls, and staying in touch would be. They have to hit the ground running, as their progress reports are due by the end of July. So, I recommended 4 simple steps. (I should note that each team was launched with an official Charge document that could hold the place of a scope/charter.)

1. Create task list, with target dates (establish rhythm, identify obstacles, divide up work)
2. Identify obstacles (What has medium to high likelihood of delaying your ability to succeed? What can you do in response, if it comes to pass?)
3. Establish rhythm (communication, document sharing, issue & action item tracking)
4. Put it into action! (At each meeting, have a brief check-in on your task list. Where are we?)

I gave them an example (high level) task list and a suggested approach to reporting for their interim and progress reports.

My hope was to hit that sweet spot: enough structure to hold their work and help them forward but not too much bulk that it weighs them down and holds them back from the nimble, exciting, scary, inventive, unruly, transformational work they need to do.

I’m not sure that I hit the spot, but a very short amount of time will tell. What would you have told them? What is your list of essential steps?

I’d like to suggest a different metaphor, project ecology. After all, when we work on a project, we are connected to one another in a variety of ways. For example, if we are building a web interface together, imagine that you give me a spreadsheet with an analysis of the components I’ll need to understand a key requirement. Several of our colleagues gave you the information you needed in order to assemble the spreadsheet. And, once I’ve digested what you’ve given me, I will write up a specification and then give it to another colleague who will add this information to the design for the prototype.

Image courtesy of Eastman's Originals Collection, Group 62, University of California, Davis.

We are connected by the information exchanges, by the tangible inputs and outputs (the deliverables) we pass along, and by our personal relationships. What if we who work on projects together viewed all these interdependencies as an “ecology” of sorts? How might this change the way we relate to one another and to the project?

If you follow this way of thinking, the person who is building the prototype, who is waiting for my specification, is, in effect “down river” from me. If I am able to perform my work “cleanly,” that is to say, in a timely fashion and leaving few unanswered questions or–at least–undocumented issues, then the momentum of the project moves through my part of the “ecosystem” unencumbered. My downriver colleague gets a fresh start on her tasks, and the project is not building up an inappropriate backlog.

Of course, new and unforeseen problems do arise during projects, just like dangerous rocks are often just below the surface of a river. If the problem occurs on my watch, it’s up to me to make the first response to it, one way or another. In other words, if I am going to pass along a problem, I want to be able to present a problem statement, explain my analysis and offer my understanding of the best next steps.

It’s a simple idea, that boils down to this: no dumping. What do you think?