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?

How can you make sure you do it right more often than not? Effective communication is one of the toughest skills to master, since our individual personalities vary so much. The key is to build a strong communication bridge with your manager so you can be mutually successful at sharing and managing the effects of important news.

7 Ways to Build a Communication Bridge with Your Manager

1. Set the groundwork: During a time where things are quiet and peaceful, discuss with your manager what types of news should be shared and how.  Ask them what they expect to receive from you, and how you should deliver it.  For instance, which things can wait for a regular check-in meeting and which things need to be shared immediately?

2. Never let your manager be surprised. Remember that your manager’s manager doesn’t want to be surprised either, so think strategically. Review possible scenarios and play them out.  For example, if there’s a major problem with a service, your manager might want to be informed the same day or within three hours or immediately. They might want to be texted, phoned, or called out of a meeting.

3. Give a bit of advance notice. Let your manager know you have something important to discuss and ask for a time to meet. Try to pick the time of day when your manager is at their best and not facing an imminent deadline.

4. Take the time you need. Allow enough time to frame the issue, discuss it, ask questions, and come up with a solution. Don’t let your anxiety stop you from getting the feedback and support you need. It helps to write down your main points and frame the discussion before you meet. Before you leave the meeting, be sure you know what the next steps are.

5. Don’t shy away from delivering bad news. Most of us are eager to share good news but more hesitant to share bad news, hoping we can resolve the problem quickly. If something is not going right, it’s better to share the bad news up front. Every manager would love to hear your news paired with a solution, but don’t be afraid to say you don’t have one and you need their assistance in crafting a solution.

6. Keep your tone calm and respectful. Your approach should be strategic and planned, not emotional and reactionary. Your demeanor will keep your manager calm as well.

7. If you are a manager: The most important thing you can do is to create a climate where your staff is comfortable communicating important news to you. Show them that you don’t “shoot the messenger” but instead welcome all news.

“The relationship with your boss is a partnership. It takes effort to built the relationship and nurture it. You have to communicate well, avoid confrontations and resolve differences in a positive way.” – Jane Boucher

Now, It’s Your Turn

1. Make an appointment with your manager and work together on #1 and #2 above.

2. Read our related post on 3 Ways to Be More Effective in Giving and Receiving Feedback.

3. Look at a few of these articles to get more tips:

Top 7 Tips on Delivering Bad News

Tips for giving your boss bad news

How to deliver bad news to your boss

eHow’s How to deliver bad news to your boss

Read more posts from Your Life@Work.

A day or two later, someone tweeted back, “I would be interested to hear from you on what you learn about technology adoption.”

Image courtesy of San Diego Historical Society

This is interesting to me in a couple of ways. First, I like (a lot) that it’s possible to have conversations across the network, even with people I haven’t met, about substantial topics. I can sometimes learn surprising things or make useful connections.

The other aspect I like is that the comment, coming a while after my quip, made me rethink what I’d said. It caused me to consider that, indeed, I might be on a path toward learning some new things, and not just facing a bunch of barriers.

This thinking about barriers has been in the context of working on a Next Generation Technical Services (NGTS) task force. I wrote about NGTS back in June when the Round Two groups were just getting started. These teams have been tasked with proposing transformational change, and they have just submitted their final reports.  For each of the recommendations, they were asked to consider and discuss benefits including cost savings and avoidances, barriers to adoption and or implementation, how current processes will change and how those changes will impact our users. As these discussions progressed, it became abundantly clear that not all the recommended changes would be technological. Many would be alterations to current workflows and/or business practices.

The teams doing these analyses understood their reports might encounter pushback. Indeed, as noted, they were expressly asked to identify barriers to adoption. In my view, the step of quantifying the cost savings and cost avoidances–actually putting a pricetag onto the recommended change is a very powerful tool in facing resistance.  With this information, everyone knows how much the pushback costs, what the cost is of not overcoming the barriers.

So, if we don’t learn about technology–or new business practice–adoption, as my tweeting partner is hoping I will do, but instead we learn about change resistance, we will know exactly what that is costing us. We will have our eyes wide open.

So why does it fail much of the time? And what can we do to make it work? To get some new perspective, I turned to the web for answers – and I’m happy to share what I learned, because it gave me a path forward as a project manager and member of a group. Much of it hinges on whether you are currently a work group or a team, and if you should become something else.

What’s the Definition of a Team?

This definition of a team comes from a heavily-quoted book on team-building, The Wisdom of Teams (Katzenbach and Smith, 1993): “A team is a small number of people with complementary skills who are committed to a common purpose, a set of performance goals, and a common approach for which they hold themselves mutually accountable.”

What does that really mean? Consultant Sharon Feltham breaks it down this way:

6 Success Factors that Define a Team

1. Small number of people: There are fewer than 12 members (sometimes much fewer)
2. Complementary skills: The team identifies and uses the different perspectives, knowledge, skills and strengths of each member.
3. Performance goals: The team has clearly defined objectives for which members are individually and collectively accountable.
4. Common approach: There is a sense of shared purpose, with a clear understanding of the team’s mission and vision.
5. Mutually accountable: The results come from a collective effort rather than just the sum of individual efforts. People are accountable not only for their own efforts but those of others.
6. Leadership: Instead of having a strong solo leader, the team rotates leadership.

What’s the Definition of a Work Group?

Consultant Marie J. Kane [PDF article] notes that in a work group, there is “no significant incremental performance need or opportunity that would require it to become a team.” So the members may come together to share ideas or help each other make decisions in their own areas of responsibility, but mutual accountability is lacking — there is no common objective.

Deborah Mackin, an author of several team-building books, points to a fundamental difference: “a small group of people with complementary skills and abilities who are committed to a leader’s goal and approach and are willing to be held accountable to the leader.” In other words, the group accepts the goals they are given, the members report to the leader, and individual performance is generally evaluated by that leader.

Should a Group Always Try to Become a Team?

Look around your organization. There are probably few genuine teams, and you can spot them immediately because their work is stellar. Everyone talks about them and admires their efforts. These teams perform well for two key reasons: the six success factors noted above are all present; and the members have put a tremendous amount of time, effort, and emotional capital into forming a high-performance team.

4 Questions to Determine if You Need a Team

1. Is there a genuine need for change?
2. Will there be a return on investment?
3. Is there support from senior management?
4. Is there enough potential for better performance from the individuals in the group?

What’s The Path Forward?

I said at the beginning of this post that I saw the way forward, so here it is: my group is genuinely a work group and should remain so. We are large. We don’t all do the same work — in fact some of us have never worked together on a project or service. But that’s not to say we’ve given up on the idea of teams.

Instead, we’ve started focusing on building small high-performance teams within our group –- even two people can constitute a high performance team. Being on a high performance team makes me feel like I’m really making a difference, and it gives me a chance to stretch my wings and improve my skills. In time we hope to see more small teams working together to create change.

And of course Lena and I hope our readers see us as a team — we have worked hard to fulfill all the criteria of a genuine team and it’s made our work together very satisfying.

What’s happening in your area? Should you be a team or a group? Maybe it’s time to make a conscious choice!

Coming together is a beginning.
Keeping together is progress.
Working together is success.
– Henry Ford

Now It’s Your Turn

1. Learn more about the differences between teams and work groups by reading the articles linked above.

2. Talk to your work group about whether change is needed and whether they can make a commitment to changing the way they work.

3. Before you move forward, be sure to read The Wisdom of Teams (Jon R. Katzenbach and Douglas K. Smith, 1993). It’s a wealth of information, advice, and practical steps that will help your team to achieve its goals.

Read more posts from Your Life@Work.

Do you ever wonder what would happen if you refused to deal with all those meetings, emails, and random interruptions? Do you ever dream that if you could just block off a few days to get organized, to really think without interruption, you could do something innovative? And do you also secretly wonder if, after years of running frantically, you even know how to innovate any longer?

My inspiration for this post is a video interview of Jason Fried titled “Why You Can’t Work at Work”. Fried is the co-founder of 37signals, a maker of software tools for project tracking, collaboration and information sharing. (Many of us have used their project tracking software, Basecamp.) Yet with all those great tools to foster communication and innovation, he still gets frustrated with interruptions, especially those created by meetings:

The modern workplace is structured completely wrong. It’s really optimized for interruptions — and interruptions are the enemy of work. They are the enemy of productivity, they are the enemy of creativity, they are the enemy of everything. But that’s what the modern workplace is all about, it’s interruptions. Everyone’s calling meetings all the time…you don’t work at work any more.

Easy to Say, Hard to Do

Jason Fried’s solutions are striking. While I admire them, I’m not sure how to introduce some of them to our organization and gain acceptance. But they are certainly better than all those tired remedies I read about all the time.

In contrast to Fried’s innovative solutions, those great-in-theory remedies don’t work for our organization:

• No, I can’t check my e-mail only twice a day, because we’re an e-mail culture and you’re expected to respond quickly.
• No, I can’t opt-out of meetings, because we are a culture that highly values consensus.
• And no, if I make myself unavailable by closing the door then I can’t provide one of the vital services of a project manager: serving as the “glue” that pulls together everyone’s news, ideas, and concerns. Besides, talking to people and learning new things — either one-on-one or in a group — is one of the great pleasures of the workplace.

But our team has made some changes about the way we hold meetings; the result is more opportunities for reflection and innovation during the day. These ideas might help you too.

6 Ways Our Team Reduced Meeting Madness

1. Eliminate redundant meetings. We had two weekly one-hour meetings with about 90% overlap in attendees (different projects, same players). We spent most of our time trying to remember who knew what (or getting bored because we’d repeated everything at least twice). We consolidated two meetings into one, saving countless hours and untangling our communications in the process.

2. Share information in a shorter time span. We took the newly consolidated meeting and made it a dual-purpose event. The first segment of the meeting is an operations review for our entire team of fifteen people. We each give a one-minute update on our projects and ask for help or advice as needed; we finish in thirty minutes or less.

That meeting we consolidated in #1 above — it now takes place in the remaining thirty-minute segment. People who aren’t part of those two particular projects are free to leave; the rest of us only need thirty minutes since we shared broadly in the first part of the meeting.

3. Stop taking elaborate meeting notes and sending them to everyone via email (or worse, as a document attachment to e-mail). Instead, use a collaborative space like a wiki or Google Docs to record agreements and commitments. It reduces e-mail traffic; saves space in each person’s email client; and eliminates storage of the document on the organization’s shared drive (a place where documents get stored in mysterious folders never to be found again). It puts information where everyone can easily access it, making it a snap for people who missed the meeting to learn what happened.

4. Hold meetings that really matter. Recognize when an email thread is spinning out of control; people don’t know what steps to take; or there is tension in the team that needs to be resolved face-to-face. That’s the right time to call a meeting. Specify a start and end time. Set an agenda showing desired outcomes. Designate one person as facilitator to help people reach those outcomes. Make sure each task has an owner, a due date, and a clearly defined work-product. (Get more tips in our post Envisioning Successful Outcomes.)

5. Delegate work to small, nimble teams. Last year we held extensive planning sessions to create three-year goals and objectives. Recently we were asked to propose five related goals for this fiscal year. Since we already had a shared understanding, we trusted a small team to draft the additional goals. We posted it on our wiki, collected feedback, and then gained consensus in a quick thirty-minute meeting.

6. Declare one day a week as a meeting-free zone. Even though we never talked about it formally, we don’t hold meetings on Fridays unless it’s absolutely necessary. It gives us a solid block of time to catch-up, think, and plan for the next week.

“How we spend our days is, of course, how we spend our lives.”  — Annie Dillard

Now It’s Your Turn

1. Listen to Jason Fried’s interview, “Why You Can’t Work at Work”. Share it with your work team and see if you can find better ways to work together. (Lena and I want to get bolder and adapt more of his ideas.)

2. With the time you’ll gain in productivity, try completing a small innovation project that gets you energized. Read our post on How to Embrace Innovation for some motivation.

Read more posts from Your Life@Work.

Innovation is about making changes — doing things differently, thinking differently. What’s helpful to know is the changes you make don’t have to be huge and dramatic. Incremental changes like putting one foot into the gym to launch a long-term exercise routine will eventually get you where you want to be.

As project managers, Leslie’s and my biggest challenge isn’t managing projects…it’s  managing change. Some people say the change process is similar to the grieving process. It involves many stages including anger, denial, and bargaining and it finally culminates in acceptance. When you lead a team through a project you can expect to encounter each of these reactions (and that’s a good thing because it means the team and stakeholders are taking the change seriously). Your best tool for managing change is preparation.

4 Tips on Managing Change

1. Break the change into stages for a smoother transition.

2. Anticipate the likely responses to change at each stage from your team, stakeholders, end-users, and anyone else involved. Be prepared to address their complaints, questions, and concerns. Keep in mind, you are looking for a reaction to indicate the change is being taken seriously. No reaction could mean the team is in denial or is simply not comprehending your message. Getting little or no reaction puts you at risk of being disrupted later in the process when the change finally does sink in.

3. Explain the proposed change in different ways so everyone understands. Use examples familiar to each audience.

4. Use visuals (charts, diagrams or even drawing on a white board) to illustrate what’s changing and the step-by-step process involved (useful for complex scenarios.)

Innovation is an opportunity to do something more effectively, efficiently, or elegantly. It’s about solving problems creatively.

Start with a Simple Innovation

A big complaint for project managers is that we are expected to run a meeting, take notes, send them out afterward, and then follow up to make sure people know what they are committed to doing. I’ve found a simple innovation that my teams really like.

I project our team wiki onto a large screen and type in brief meeting notes as we talk. Why is this good?

• It focuses everyone on the agenda item at hand.
• You get immediate validation (revisions and clarifications) from participants. Participants find this assuring.
• It saves time. (Avoids circulating drafts back and forth.)
• It engages remote participants. (Share your desktop via web conferencing.)

A bonus is that your notes are available immediately for access by other stakeholders or team members unable to attend the meeting. Most importantly, project team members liked this new technique and readily embraced it.

Move on to Bigger Innovation

What can we do as individual professionals? You might complain that your own organization doesn’t foster change, and there is nothing you can do to change it. Don’t give up! A large component of innovation is inspiration. Leslie and I check out these blogs regularly for inspiration and ideas.

Take a moment and look at our favorites:

Innovate on Purpose

The Heart of Innovation

BQF Innovation

Think for a Change

“Some people change their ways when they see the light; others when they feel the heat” — Caroline Schoeder

Now it’s Your Turn

1. Pick one blog and follow it. Read the comments and follow the links wherever they take you. Get inspired!
2. Pick something you want to change. Think about the core problem you’re solving. Can you envision an innovative solution? Something that saves time, makes it easier to do? Next, break it into steps. How will you get started? What’s your first step?

Read more posts from Your Life@Work.

Is this a bad dream? No, this is Attack of the Scope Creep!

This is certainly how it can feel on a bad day in Project Land, as though every time you turn around, you’re confronted with another demand. I read something a few years ago that turned this on its head for me:

“Scope creep is the pejorative name we give to the natural process by which clients discover what they really want.”

In other words, most people simply cannot imagine how a service will operate or what an interface will look like until they see it. This means that they will not be able to give meaningful feedback until they are working with the prototype (in the case of software) or the pilot (in the case of a human service). And this is only natural.

This has significant implications for project planning. First, we need to build into our plans adequate time for iterative prototyping and/or pilot phasing, and second, we need to adopt good processes for handling change requests. This last step includes good mechanisms for capturing information about the changes requested.

In a previous post about stakeholders, I claimed that setting up a rational decision-making path for change requests could save you time in the long run. This is what I had in mind. After all, the people asking for those extra features are going to be your stakeholders. They don’t actually mean to slow you down–in fact, they’d prefer you add all those extra features at twice the speed.

I’ve put together a short slide deck on taming scope creep, because I believe it can be done. Not the part about adding extra features at twice the speed, but the part about having a plan saving you time. I want to mention that the slides cover only the change process. It’s very important to couple this with the rapid prototyping I talked about earlier, because that’s how you will discover the new information in a format and on a schedule you can control. And that’s how you take the creep out of scope creep!

One of the first things I remember noticing was that project governance was distinctly different at CDL from what I had known. For example, I had always identified the project sponsor as the single individual who owned the budget for and made final decisions about the project. On an exceptional basis, the sponsor could be a sponsoring group rather than an individual.

At CDL and for the UC Libraries, I’ve learned that often the two functions–who pays for the project and who makes decisions about the project–may be entirely independent of one another. In a very real sense, there may be no single (or group) project sponsor. Within this kind of context, I believe it is especially important to think carefully about the project stakeholders.

Courtesy of Bancroft Library, University of California, Berkeley

And, typically, our projects have many stakeholders! As the project manager, our special challenge is juggling the complexity of relationships, while running the actual project.

I’ve put together a short slide deck with one technique for how to do this. The basic idea is this: make a distinction between those stakeholders from whom you would accept a (scope) change request and everyone else. The first group is the select core of primary stakeholders, and these are the people you have to treat in a special way. (I detail this in the slides.)

If the core is still rather large–more apple than core–then I recommend that spending some time up front planning a rational decision-making path for change requests. This may involve negotiating some level of organization for the stakeholder groups. In other words, if you will accept change requests from several groups and individuals, consider making an arrangement with the groups to use a single, empowered, representative for their project-related decision-making.

Any thinking you can do at the beginning of the project about how to handle change requests will be time well spent. I have never started a project that I have completed without having received a single request for change to the original scope. Have you?