How do you learn from failing?

Brad,

That's a great question. I usually reflect on the context and on the moments when things went wrong. Because I think in terms of people it usually comes to me as a communication, expectation setting, or process/decision ownership problem.

I used to believe that I could move a client to the solution I thought was best for them. Design changes and tweaks required to allow the client a sense of participation were fine with me. In fact necessary, sometimes, if it meant obtaining their buy-in on a bigger goal (sometimes that was a phase two project).

But nowadays I feel that more of the work involves communicating a new way of doing things, and that's trickier. If it's social media and I'm interfacing with marketing, then the challenge emerges around loss of control > new techniques of control. The old ones that need to go away can do so only if replaced by new ones. The new ones might mean ROI and analytics (client perceives they have some level of control around results). But if I don't manage that process of learning right, it's too threatening a change, and things can stall.

So it's important to know if the client really wanted social media, if the org wants it, if a boss wants it, etc, because then internal resistance or communication can be the problem, and as a vendor/contractor one may need to involve new people in order to make sure the solution you're offering is sold properly internally.

My approach is to allow the client to lead — I find if I lead the client too brashly then resistance may come later. This can make for a slower process, and it's important then to listen for hesistation and make quick changes to sustain enthusiasm and buy in. Today's budgets are not always secure, and can be poached for something safer (eg sales) if you're not attentive.

my 2 cents.

cheers,
adrian

Hey Brad,

I think in order to learn from mistakes, you need to start by being open to others ideas. We all fail; which in and of itself has been given such a negative connotation that we end up losing out on a wonderful opportunity to make wiser decisions in the future.

When a project “falls off the rails”, I take time to look back at where the communication broke down. Fundamentally, from my experience, when we fail at accomplishing a specific task we do so because we (note I'm not saying the client or myself), but the collective team fails to communicate / illustrate the end state clearly; and subsequently the steps along the way.

Did we question for clarity? Did we use the terms and vocabulary that everyone understood? Did we gather all the necessary decision makers who needed buy-in from the start? Did we clearly illustrate the goals of the project before we started working?

If we start to look at the opportunity that failure provides, we can all become better designers and more importantly, improve our capacity to both educate and learn from our clients and the projects themselves.

Brad,
I've personally tried to feel more comfortable failing. Let me say, it's quite a challenge. Failing is a really tough proposition because we're so culturally and emotionally tied to finding success on the first big effort. When, in fact, we're more likely to be successful after many, many small efforts and incremental improvements.

Your article makes me reflect upon a few things:
- In his TV commercial, James Dyson said that they failed more than 5000 times before they got the vacuum cleaner right. http://www.dyson.com/about/
- On the web, Honda talks about how failure helps them win http://dreams.honda.com/

In both of these aforementioned companies, the leadership embrace a culture of learning from failure. My bet is that their designers are really good at operationally defining what failure means to them personally and how the next iteration will help them achieve their design goals.

In situations where the relationship w/the client is ongoing, I've called for project post-mortem meetings to sit with all of the key stakeholders and talk about what went right and wrong, and how we might proceed in the future. It's a tricky business, but when successful does a world of good towards solidifying the relationship towards the next partnership.

A couple of tips I give myself beforehand:

– Have a cool-down period post-launch.
– Run around and talk to each stakeholder individually before the meeting to feel him/her out about their thoughts, and to assess their comfort level w/the prospect of the meeting.
– Gather some preliminary performance numbers to discuss, as well, or press reactions/reviews, etc. If there are successes there, it does a world of good to know this. Circulate these to the team so everyone sees them and isn’t surprised by them.
– If the resources are there, do it offsite or in a neutral location. Even better, find an impartial facilitator to direct the meeting so it's not seen as your personal bitch session.
– If you can get folks to agree to it, set aside at least an hour and a half. Having an irregular amount of time sets aside breaks down people’s defenses. If you need more time, you can always schedule more. And there is no rule that you have to stay in a room once the conversation is done.
– Really think about what went *right*. No, Joan, shut down your habitual perfectionist whining and get a little perspective. What's better than it was before? How did the project position itself for opportunities later?
– At the meeting, reiterate the project goals, and this meeting’s goal: to learn from what happened and to figure out how to go forward. Then give everyone a finite amount of time to say two things that went right and two that went wrong. Move them all right along.
– Capture these and then discuss, focusing on how to do better in the future. Do not play the blame game. Do not. It helps nothing.

Yup, kind of a powder keg, but well worth the doing if you’re up for the challenge. I think the trick is to be clear about yourself, first; then focus on the project as a system, identify the breakdowns in that system and the opportunities to do better in the future. I believe the things that contribute to project breakdowns are problems in communication, integration, and technical expertise. All of those can be fixed.

Is this helpful, Brad? I’d love to hear other’s thoughts on this, as well; I’m sure I’ve missed stuff.