Surviving Design Projects

Pattern: Show your work

brown — Sat, 23 Jun 2012 07:36:01 -0400

Expose other members of the team to the design process. While designers and other creative people are generally tempted to show only the result of their labor, pulling back the curtain early in the process can be helpful. Besides involving people in the creative process, showing work can help explain the challenges and justify the decisions made.

Showing work might entail revealing early sketches or concepts, describing the thought process, or including people in brainstorming, critiques, and other conversations along the way.

Use when:

Confronting difficult design problems to show how you’ve incorporated and addresses many different inputs or constraints.
Working with a team that doesn’t understand the creative process to demonstrate the complexity of the challenge.

Pattern: Assert your process

brown — Sat, 23 Jun 2012 07:35:23 -0400

Set the tone, rhythm, and sequence for your process. When embarking on a project, the team may discount the importance of the creative process in problem solving. Other factors — stakeholder schedule and expectations, business milestones, or technical deployment schedules — may influence the approach more than the creative process. Be clear about what the team needs to solve the problem.

Use when:

Milestones driven by other factors threaten the success of the design project.
Team members unwittingly undermine the design process by asserting a cadence or sequence that doesn’t align with your approach to solving the problem.

Pattern: Sneak peek

brown — Sat, 23 Jun 2012 07:33:36 -0400

Offer a sneak peek of your work to a lynchpin stakeholder or team member. By holding an informal, one-on-one conversation you can cultivate an ally for subsequent discussions. Incorporating the feedback of a trusted stakeholder creates a sense of ownership, which can help with facilitating large-group discussions.

Use when:

You’re building toward a potentially controversial or surprising outcome, an inside “ally” can help soften the surprise.
Your tasks have taken you out of frequent collaboration with key stakeholders. Use the sneak peek to apprise of progress and keep them involved.

Pattern: Call the bluff (or Logical conclusions)

brown — Sat, 23 Jun 2012 07:17:27 -0400

Take a challenge to its inevitable conclusion. For example, when a project manager asks for faster delivery cycles, you can ask whether the stakeholders will be able to assemble their feedback in reasonable time. In these situations, the person making the request does not usually anticipate subsequent impacts of their request.

Use when:

Faced with a situation which puts unnecessary pressure (usually in quantity of delivery) on the project team.

Situation: Uncoordinated collaboration

brown — Sat, 23 Jun 2012 07:15:35 -0400

“So, which one of us is doing this?”

Some projects have no plan, no overall direction of where it’s going long-term and the activities required take to get there. Other projects may understand the objectives, have a general sense of the activities and outputs, but have no structure for how people will work together: how often are we meeting? how are we using those meeting times? when can the team expect to see outputs? will we review the outputs prior to getting together? what’s the best way to communicate feedback?

The effect: When people don’t know how they’re working together, they don’t know whether they should be making decisions individually or as a group. They don’t know whether they need to focus on building consensus or getting buy-in. In short, they

The challenge: This situation may stem less from poor planning and more from an anti-collaboration culture or mindset. Deep-rooted reluctance to collaborate, either in the corporate culture or in the individuals, will be difficult to change.

Situation: Efforts ignored

brown — Sat, 23 Jun 2012 07:09:00 -0400

“This stuff doesn’t really matter because we’re working on a separate track.”

Members of the team choose to ignore outputs, recommendations, and solutions provided by team members assigned those activities. The quintessential example here is a disenfranchised design team — where some team members discount the value of their contributions.

The effect: Without alignment on activities and outputs, the team will fragment, wasting time and money. Business stakeholders will also waste time trying to reconcile disconnected efforts.

The challenge: Disenfranchised teams may have no control over their disconnectedness. It may be driven by politics up the ladder, a defensive colleague, or irrelevant interpersonal conflicts.

Situation: Lack of context

brown — Mon, 14 May 2012 14:14:18 -0400

“There’s a lot going on behind the scenes here…”

Teams do not have insight into the organizational, business, or operational context surrounding a project. Context is crucial to the success of a design project because it allows designers to gauge what approach, process, and solution will be the best fit. Context establishes constraints, not only for the project, but for the design itself.

The effect: The project team runs into unanticipated roadblocks in the design project.

The challenge: Stakeholders may see “insulating” the design team as their responsibility, and be reluctant to relinquish that role.

Situation: Excluded from planning

brown — Mon, 14 May 2012 12:27:59 -0400

“It’s a shame she’s not in the meeting. All these action items are for her.”

The people responsible for delivering and executing are not included in the planning process.

The effect: Project teams spend more time reconciling plans (or easing the anxiety of the producers) than necessary.

The challenge: Collaborative environments tend to favor the path of least resistance, which in this case entails making decisions on someone’s behalf when they’re not there. One flavor of this scenario involves actively excluding key producers because they are seen as not essential to the planning process.

Situation: Poorly planned presentation or discussion

brown — Mon, 14 May 2012 12:20:18 -0400

“I hate to put you on the spot, but…”

Project stakeholders do not understand the design work because the design team hasn’t assembled a meaningful narrative. Designers may have been asked to present concepts without sufficient notice, or the design team neglected to anticipate questions from the stakeholders.

The effect: Progress on the design work may be held back until stakeholders buy into the design concept. High quality work may be undermined by a poor presentation.

The challenge: Design processes balance spontaneity with deliberation. Presenting a design at a moment’s notice is not necessarily unreasonable, but the project team must understand the potential risks to the project.

Situation: No Time to Design

brown — Mon, 14 May 2012 11:55:28 -0400

“Just get some rough ideas down by tomorrow, OK?”

Forces outside the design team establish an unreasonable schedule for producing design ideas.

The effect: Designers confronted with this situation will resent the project team if forced to prepare outputs without sufficient time. If they comply with the unreasonable request, they may find themselves committed to a design concept that doesn’t effectively solve the problem.

The challenge: The design team may be eager to dive into the problem or to prove their value, ignoring the risks that come with short-changing their process.

See also: Mike Monteiro’s Design is a Job, Chapter 6, Sticking to Your Process.

Situation: False Consensus

brown — Fri, 11 May 2012 07:37:53 -0400

“I think we all agree here.”

The team comes to some agreement (on direction or approach, for example) but doesn’t really understand the underlying assumptions or the downstream implications. If they understood those, they might not agree.

The effect: A false consensus may move the project forward, leading to more challenging conflicts later when the underlying assumptions come to light.

The challenge: Since everyone agrees, it may be difficult to detect that this is a problem.

Pattern: Small Victory

brown — Fri, 11 May 2012 07:26:20 -0400

Do a small project (a pilot or proof of concept) to help other teams or organizations understand the value or the purpose of a larger program. Like the “Make it Real” pattern, by doing a pilot project, the team has an opportunity to experience the execution of a particular strategy or direction. By implementing at a small scale, the team can extract lessons learned to set them up for a larger endeavor. This small victory serves as a model for subsequent projects.

Use when:

You’ve identified a strategy or direction, but need to get further buy-in.

Surviving Design Projects - The Game

brown — Tue, 21 Feb 2012 09:48:26 -0500

The little game I made based on Surviving Design Projects is now for sale. You can buy it at print-on-demand vendor TheGameCrafter.com.

I’m very pleased with the quality of materials from TheGameCrafter. While the box is a little flimsy, the cards are very high quality, comparable with any commercial board game. (I play a LOT of board games.)

So, go and get a deck now!

Pattern: Change the metaphor

brown — Tue, 03 Jan 2012 15:20:10 -0500

Employ a different metaphor for exploring the situation. People typically use war as a metaphor for talking about conflict. Through this metaphor, we come to expect winners and losers, offense and defense, and strategies of shock and awe. The anticipation of conflict, when positioned akin to war, makes it inevitably unproductive.

Resolving Conflicts at Work offers two other metaphors:

Conflict as opportunity: Position the conflict as a problem that needs solving collaboratively.
Conflict as journey: Position the conflict as an ongoing process, allowing you to “transcend the idea that you are trapped in your conflict”. “Journeys create expectations and anticipations of growth, self-improvement, awareness, and forgiveness.”

Use when:

The language used to describe the conflict is limited to winners/losers and us/them.

Pattern: Microscope/Macroscope

brown — Wed, 21 Dec 2011 16:47:00 -0500

Force yourself to look at a situation from both a macro and micro view. It can be hard to consider a situation from multiple perspectives. Through these lenses, however, nuances of the situation reveal themselves. New and different perspective on a situation gives you an opportunity to re-evaluate the conflict, and determine whether the conflict is truly stalling a project.

Use when:

You’re having trouble seeing the situation from any perspective besides your own.

Self-Awareness: Faith

brown — Fri, 09 Dec 2011 12:44:38 -0500

Realize how much your trust of someone (or something) is driven by faith, not by experience. We are wired to believe things we want to be true, and aren’t always “rescued” by our rational side. That is, the bullsh*t detector doesn’t always ring loud enough to overwhelm our desire to believe in our colleagues. Decisions driven by faith can lead to conflict when performance or quality doesn’t meet our expectations.

Pattern: Pick one thing

brown — Mon, 05 Dec 2011 16:24:25 -0500

Unpack a conflict by picking one aspect and focusing only on that. Sometimes, conflict is caused because the situation consists of many overlapping aspects. Layered agendas, objectives, problems, and requirements can lead to conflict when team members don’t have clear priorities. By picking one thing to focus on, you can eliminate some of the noise, and use that to drive other problems.

Use when:

Performance suffers due to lack of focus.

Pattern: List assumptions

brown — Mon, 05 Dec 2011 16:06:43 -0500

Create a list of assumptions behind the situation. Sometimes, different people are making different assumptions about responsibilities, parameters, constraints, objectives, or anything driving creative work. Writing a list of assumptions brings them into focus, and encourages team members to ask questions, validate the assumptions.

Use when:

Team members are not performing as expected, delivering work that doesn’t address the problem.

Pattern: Draw pictures

brown — Mon, 05 Dec 2011 16:03:47 -0500

Use pictures to communicate situations and solutions. Countless books describe the power of communicating visually, so there’s no need to validate it yet again here. You can use that power to bridge the gap between people who aren’t communicating effectively.

Use when you need to:

Define the problem
Validate constraints or parameters
Highlight specific issues
Establish a design direction
Define a plan or approach
Assign responsibilities

Pattern: Offer alternatives

brown — Mon, 05 Dec 2011 15:51:12 -0500

Prepare several options for moving forward with an easy way to compare and contrast. It’s easier for people to select from a small number of options than it is for them to zero-in on an approach without a starting point.

You might want to compare approaches for:

Design directions
Models for explaining users or site structures
Next steps on a project
Project plans

The important part of offering options is presenting them in parallel for easy comparison. Select key criteria for comparison: you’ll need to anticipate the ways your team wants to choose one and incorporate them prominently in the comparison. Alignment with goals? Cost? Level of effort? Timing? Emphasis on different requirements? Emphasis on user groups? There are any number of ways your options can vary, so make sure they’re easy to compare.

Use when:

Conflict is caused by ambiguous direction and participants are at a loss for determining appropriate approach.