How a d. School Course is Different

I  recently wrote a post aimed at Stanford students that announced the courses that we are going to be teaching next term. One of the classes that I am teaching next term -- with Debra Dunn and Kris Woyzbun - - is called Business Practice Innovation, where the focus is on treating organizational practices as prototypes. This is part of a series of classes that a group of us are developing where we try to bring design thinking to business problems. I got a note from a Stanford MBA about the class, and I thought it would be interesting to share both the question and the (lightly edited) answer. These d School classes are so different than most other university classes (at least that I know of), that I am constantly giving long explanations that sound something like what you see below. This one is a bit more detailed than usual, so I thought it might be interesting to anyone who is interested in how we are teaching innovation. Plus it will give me something to show to other Stanford students that ask similar questions.

The question was:

Dear Professor Sutton,

Would it be possible to receive additional information regarding this course? Specifically, I would like to better understand what you mean by "changing business practices?" Is this coming up with a change to the business model / company strategy / new businesses or products? Additionally, who is going to implement the changes: the student teams / the company employees with the student teams? I guess what I am asking is: is this a management consulting type project? What are the aspects of design in the course?

I answered:

Thanks for writing. I wouldn'€™t exactly call it a management consulting class. I guess some of what we will do in class is sort of like consulting, but the hallmark of this class --  and others in the design and business initiative -- €“ is using design thinking to tackle business problems (not just to advise others, to get in there and do it). This means developing a point of view about the problem, observing people in context, developing some potential solutions, picking one or two prototype solutions that seem most promising, implementing them, and in the basis of what happens, keeping the solutions, revising them, or discarding them, and iterating on and on.

Clearly, in a 10 week class, we can't do something like, say, a merger or change an organization'€™s manufacturing strategy. Instead, in this class, you would work in a small team (two or three students) directly with people in companies to develop and then implement prototype solutions. So, let's take one project we might do (listen to the might, these are not clean and pretty and organized classes like most business classes. We have real companies and things come up. Sometimes we are set to go, and then it falls through. But we have firm commitments from two organizations, and are "€œin talks" with two others). So, let's consider one rapidly growing high tech company. The process of getting new employees on board is kind of a mess (in fact, the word "mess"€ isn'€™t meant to be negative here; they believe that their messiness is one of the keys to their success).  But let's say we applied the design process to improving the first 24 hours that a new employee is on the job --€“ that is the design problem. Teams in the class would go through stages that look something like this (all in 2 weeks, 3 weeks tops):

1. Develop a point of view on the first 24 hours of the new employee experience. For example, one point of view might be: "What can the employee do him or herself that first day to make the experience better, without any additional resources, management, or peer action." This is just one possible point of view: peers and bosses could be involved too, but those would be different points of view.

2. Your team would observe --  take notes, pictures, shadow, do interviews, and so on -- two or three new employees during their first day on the job.

3. Your team would then brainstorm ways that a new employee could better survive the first day. You would pick a few of the best ideas -- prototype solutions -- and develop ways to implement them and communicate them to new employees.

4. Your team would then work with the company to test your prototype solutions, say, on one to three new employees. You would implement it very quickly and (even on the fly) and keep refining and improving it as much as you can given the severe time constraints that you will work under.

5. You would then do a presentation to the class that describes your method, what you did, and what you learned.  The presentation would not only be to the class and teaching team, it would be to members of the company where you did your work. People from the company would not only would give you comments, they would also evaluate (yes, grade) your solution.

This class is a prototype itself, and we as the teaching team will no doubt ask you to do something slightly different than above, and change things on the fly too. But I think that my fantasy above communicates how these classes are different than my image of a "management consulting€ class." I think of consulting as mostly offering advice; although I guess that is part of what we do, our emphasis is on trying to change things. There is less talking about what the company ought to be doing, and more emphasis on finding (often small) ways to get them to do it RIGHT NOW. And  getting our hands dirty in the messy  initial  stages of implementation.

I hope this helps some; it is about as clear as I can be, as our process is fuzzy and messy. Thanks again for asking, and feel free to send this to other students.

Bob

P.S. The napkin above is the original "d.school manifesto," produced a couple years ago (after going through a process much like that described above) by George Kembel and Diego Rodriguez. I think it still pretty much describes what we are trying to accomplish.

Comments

[socks]

Enjoyed your post very much.

I am writing an article on the potential uses of persona in OD area. This can be "human prototyping".

Could you point me resouces that I can study more on this "practice prototyping" ideas?

Thank you.

Socks, from Tokyo Japan

[Pamela Slim]

Boy, this outline sure sounds great, and makes me long for my student days! In my next incarnation, once the kids are grown, I will come back and take the class. Will you be open to teaching Elderhostel at that point in your career? :)

[linda m lopeke]

Hi Bob,

Love the d-school approach (and your explanation). The napkin manifesto gets my support too! (So many great start out in life as notes on napkins don't they?

Cheers!

Linda M. Lopeke
http://www.smartstartcoach.com
SMARTSTART: Success-to-go for people working @ the speed of life!

[dblwyo]

An excellent answer and one that gives an overview of the course and it's process. Having had the good fortune to be involved in "standing-up" new things for most of my career it certainly rings bells. A couple of small suggestions that my be implicit already or may not fit your timeframes. As a rule of thumb it's always easier to edit than do greenfield.
The Re-engineering Revolution failed miserably for that reason - the inexperienced tried to start with a clean sheet and DID NOT understand the functional characteristics of the things they were looking at. Plus of course everyone missed the resistance and political dimensions. That said:
1. Early on you should review existing materials and outside sources on on-boarding processes.
2. And then ask two related questions:
- what would an ideal process look like (not all too often but every time from apps development to changing policy to new depts I see people LIMIT themselves to what exists and clean-up and smooth-out history)
- what's the value ? And the metrics and measures to determine things. Take an outside in look.

In this case who's the customer ? The company, the HR dept. ? NO - or not solely. It's the new employee - what minimal information do they need to get to be effective and how should they best acquire it ? And how can you lay the foundations for later learnings instead of overwhelming them ? Especially with one boring lecture delivered by one jaded and dis-interested staffer after another.
Now this may all be implicit in the way you've described things but in my mind it adds the notion of accelerating thru tapping into possible blueprints of processes. And self-organizes around the central question.
FWIW.

[Max Christian Hansen]

This sounds wonderful. However, it doesn't sound much different from the "Planning & Managing Change" course that Ed Schein taught at MIT Sloan (business school) when I was there 10 years ago.

Even so, that course, excellent as it was, would have benefited from the addition of design concepts.

Nowadays, when I see a dysfunctional business process, the word "design" pops into my head frequently as I analyze it.

Schein taught systems thinking, and that's much of where I learned to analyze the way I do. But what I didn't really figure out until after school was to always ask "if the whole biz had been designed from scratch to make this process perfect, what would be different in every part of the system?"

The result is the most idealistic (and naive) vision you can create. But asking it that way seems (for me) to make the naivete clear. I can see how far the present system is from the ideal. From there I can think clearly about how to approximate the ideal within the constraints of time, resources, and the need to preserve well-functioning processes unharmed by any changes I implement.