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.
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
Posted by: socks | November 05, 2007 at 09:52 PM
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? :)
Posted by: Pamela Slim | November 05, 2007 at 09:22 PM
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!
Posted by: linda m lopeke | November 05, 2007 at 07:27 AM
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.
Posted by: dblwyo | November 04, 2007 at 05:05 AM
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.
Posted by: Max Christian Hansen | November 03, 2007 at 08:22 PM