February 2008 - Posts
This week we had an interesting discussion about how much time and effort we should spend planning and hypothesizing about what might go wrong with the project you are working on. As with workplanning, there's a tradeoff between investing in upfront work versus moving into action mode. You can waste valuable time, and actually solidify commitment to a not-very-good plan, by investing in too much detailed preparation and fine-grained mapping of steps. And you could drive yourselves nuts with group sessions designed to ferret out every possible risk to your project. So, beware the paralysis of over-analysis!
Yet I'd argue that a bias for action may be a more likely challenge. When it comes to work planning, most students are pretty good at listing project tasks and timelines. Where I often see folks fall short is in figuring out how the team can keep tabs on how much it is accomplishing in terms of concrete progress towards its goals. Notice that I said
goals and not deliverables. Attention to goals enables you to identify the points at which, even if you make progress towards your deliverables, you are not achieving what you set out to accomplish.
The question of progress towards goals connects to another theme that's come up of late: what are the best indicators that will help you to monitor where you stand? Perhaps this is the most important discussion to be having at the early stages of a project, and it links to the questions of potential risks and predictable surprises, too. If you make sure you've listed at least a few of the likely problem areas or failure modes for your team project, then you'll be able to talk about what you think would be a good set of indicators that would allow you to assess whether this potential nightmare is, in fact, going to take place. So this is one set of progress indicators that are invaluable for your team to consider ahead of time. For instance, if your external partner's level of commitment to the project is a potential problem, then you may agree to keep tabs on their responsiveness to your communications, and to track their comments and questions during interactions. At team meetings, a quick check-in question could address partner responsiveness as well as their expressed concerns and questions. If you're seeing a pattern that may suggest worsening commitment, you'll need to try something new.
So use a conversation about predictable surprises to generate a list of potential indicators that things are going wrong. And then, of course, talk over with your team what you want to do about it, and at what point a response is warranted.
Every one of us, and every team, may have a natural tendancy to invest too much effort into one phase of your project at the cost of its other elements. If you know that you've been blindsided by predictable surprises in the past, then spend more time thinking about, discussing, and addressing the risks. If you tend to be slow to take action and instead make lots of plans and then contingency plans, perhaps now is the time to try taking more actions, setting aside time to revisit your plans once you've taken more steps.
When we looked at predictable surprises we found ourselves worrying that the list of things that could go wrong is infinitely long. But at the same time the workplace is full of people who can tell you on day one of a new project exactly how it will fail, and they will often be right.
The bottom line is that this tension between thinking and acting is here to stay. In many ways, as Minztberg and Gosling argue in a paper describing the orientations and skillsets fundamental to mangement, it is a fundamental tension in the life of any manager. They frame the tradeoff as one between reflection and action, but it really is the same thing we've been talking about:
Everything that every effective manager does is sandwiched between action on the ground and reflection in the abstract. Action without reflection is thoughtless; reflection without action is passive. Every manager has to find a way to combine these two mind-sets - to function at the point where reflective thinking meets practical doing.
Jonathan Gosling and Henry Mintzberg, “The Five Minds of a Manager,” Harvard Business Review Nov2003 p54-63.
NOTE THIS IS A DRAFT POST TO BE UPDATED
How do you make sure that your work is effective? First and
foremost, you need to get stuff done. Designing and using a good workplan is
key, of course. Last week’s post offers some ideas to get you started on workplanning.
For instance, you need to sort out what it is you want to have finished by the
end of the project (the awkwardly-named “deliverables”) as well as the time,
effort, data, and other resources needed to produce these things.
But working effectively also requires you to address some
big questions about the effect of your efforts.
For this post, I want to introduce some ideas that I think
could help you sort out two linked questions that get at effectiveness: What’s
our underlying model for how this project will actually work, and how
will we know if we’re right?
If your project is a real one—and a fun one!—your answers to
these questions will evolve. Our starting point for addressing the questions is
a set of structured approaches called theory of change or logic models or,
sometimes, evaluation models
Theory of Change evaluations make the team’s theories of
change explicit so that the work can best address the causal model that
undergirds the project’s plans and goals. A good theory of change includes
working versions of:
- situation
and stakeholder analyses
- actions
taken
- anticipated
outcomes
The reason to make it all explicit is to set up the team to
seek evidence as to whether the theory is matched by reality.
Example: boys and girls club http://www.evaluationtools.org/plan_theory.asp
introductory instructions:
http://www.uwex.edu/ces/pdande/evaluation/pdf/LMinstructions.pdf
source:
http://www.uwex.edu/ces/pdande/evaluation/evallogicmodelworksheets.html
for more please go to
http://www.uwex.edu/ces/pdande/evaluation/evallogicmodel.html
tutorial:
http://www.uwex.edu/ces/lmcourse/#
Other benefits of a theory-of-change approach, or why you
should address these questions (now and again!):
Where outcomes are expected only in the long term – perhaps
after the evaluation is complete - they give early indication as to whether
predicted changes are happening and therefore whether the intended outcomes are
likely to emerge in due course.
They are able to trace complex links between action and
outcome, so that the problem of attribution is diminished.
The process of explicating leaders’ theories of change can
be helpful in planning the initiative with greater clarity.
They also provide leaders with early feedback as to the
effects of their actions, making it possible for those actions to be modified
at an early stage and linking the evaluation process closely with the
development of the initiative.
Qualitative data (generated from interviews with a wide
range of stakeholders) and quantitative data are both useful for the evaluation
process.
The expectation is that, by the end of the evaluation
process, it should be possible not only to articulate the theory (and any ways
in which, by then, it has changed or has been contested by other stakeholders)
but also to present convincing evidence of the sorts of changes that are being
brought about by the project and to predict the sorts of long-term outcomes
which are likely to emerge.
More ideas?
Interesting to link this to your first cut at the rationale
for your project—recall our discussion of your projects via three simple
questions from Week 2:
- What’s
the problem?
- What’s
your solution?
- How
does it work?
If you go through the processes outlined in the resources
linked to here, you will have a theory of change. What next?
answer #1: talk this over with your team
AND (answer #2):
How are you testing this theory as you go? Do your
experiences and the totality of your emerging set of data fit with it? Do you
need to revisit your theory of change?
links:
http://www.wkkf.org/Pubs/Tools/Evaluation/Pub3669.pdf
http://ctb.ku.edu/tools/en/section_1877.htm
http://www.innonet.org/client_docs/File/logic_model_workbook.pdf
http://www.theoryofchange.org/index.html
http://www.aecf.org/upload/PublicationFiles/CC2977K440.pdf
http://www.uwex.edu/ces/pdande/evaluation/evallogicbiblio.html
for a bibliography, including research
IN RECENT CONVERSATIONS WITH MY STUDENTS, we talked about the value of the
simple exercise of boiling down your project plan into a very short explanation
(we aimed for 9 words!). But just explaining what the project sets out to do is not enough: we also need to be able to explain how the project will get there. To that end, I've been asking if you can tell us your story in three sentences:
- a statement of the problem, opportunity, or need that you are
addressing, from the client/host/target’s point of view, together with
- a pithy description of what you will do and
- how that will address the situation.
I want to underscore the importance of writing it down and then inviting
comments and discussion. There’s no substitute for that work. It can really
help you to figure out the key points on which your entire project hinges, and
in turn those are the open questions that are most urgent for you to tackle.
The underlying philosophy.
Such an approach is very much akin to treating your project plan as a
working hypothesis, which your actions will then test. This is an idea that, of
course, borrows from the scientific method. It’s also a cornerstone of many
consulting firms’approaches (see, for instance, this blog
post by a consultant; an explanation of the
McKinsey model (note the nice feedback loop at the top!); here's another
post outlining the McKinsey approach presented in the 1998 book).
The practical implications. Once you’ve talked through
your-three part project overview, use it as a screen for looking at your action
steps. In other words, your first cut (v1.0) of the project description should
serve as the basis for your project planning. For each action you’ve listed,
make sure you talk through with your team how it will help you shed light on
the key issues related to your project descroption v1.0. Note that this
description may--actually, it really should--evolve, but that you’ll
want to be thoughtful about when you allow such changes to enter, because they
will necessarily entail revisiting your project plan. So set aside such “big-picture”
discussions for only certain windows, not for every week!
What’s the next key step?
The second topic is related, and that is the question
of what’s the most important next step. The previous work allows some focus to
emerge. Use that insight to figure out the next critical step in your project.
Don’t forget, you do have time at the outset of the project to think things
through so that you design your work to be as effective as possible. I urge
students to use the resources of their class--and stakeholders, who we’re
discussing in class right now--to sort out a feasible project, set up realistic
plans, and build the team you need to get things done. At each step of the way,
ask yourself this question: what’s the next action? (shades of David Allen’s
GTD, for those of you into that sort of thing--more on that later). It’s often
pretty obvious what the one most important next step is. But surprisingly
often, people don’t actually do the
most important next step! The task for you and your team is to set up a
personal or team discipline for, first, figuring out the next step;
secondly, doing it, and third, figuring out what it
means for your next subsequent step. That’s, of course, the model
embedded in our course (prepare-act-reflect), and it’s one that I encourage you
to use every single week. So, this week's question: what's your next
step?
We talked in class about the inescapable tradeoffs in any
team planning effort—for instance, too much detail can be as bad as too little
detail in your workplan. And as you go, your team faces tradeoffs in managing
stakeholder engagement (who gets to have a say in the specifics of what you
plan to do, and how to they participate? If stakeholder participation is
necessary for buy-in, how do you ensure your plan is manageable and under your
own control?). There are some unique challenges to projects for learning: after
all, your professor and TA are also stakeholders, and need to be managed too. They
are, of course, also a resource, but like other stakeholders, if they are not
kept informed, they may not be as useful as they could be. What’s your plan for
managing stakeholders?
Another key issue to consider: how flexible is your
workplan? Have you built in the opportunities for your team to revisit the
entiree project plan at a couple of crucial points? When are these points, and
have you planned your work so that you will have the data you need to make the
needed revisions at that point?
Web resources for project management, workplanning, and
action planning abound. Many of you have used structured techniques and
software tools (e.g. software like Microsoft Project; online, I have used 37
signals’ basecamp and backpack for larger and smaller
projects, respectively). Some of the traditional tools for project management
include the Gantt chart, which maps dependencies (example),
and the more complex network-based PERT chart (which draws on an approach
called the critical path method), but these of course need to be embedded in a
process that makes sense.
To help you think about your project workplanning process, I
thought I’d share a couple of resources that I found online. Note that these
each come from a specific domain, and that you will need to adapt the approach
to one that works for your team.
My first resource is a set of basic
guidelines for planning that appear on a site called Free Management
Library. I can’t vouch that this is a definitive and fully referenced site, but
I think it’s likely to be a useful place to explore and to start learning more
about planning from a management point of view.
Every year I direct students to the work of Scott Berkun.
This chapter, How
to Figure Out What to Do, excerpted from one of his book, may be
overkill for some, and will require translation from his domain to yours, but
may be useful for many of you. I think it’s a good read. Here’s a
shorter blog post on critical thinking that has a very similar flavor
to some of our discussions in class. He may be approaching problem definition
from a design standpoint, but the ideas apply to projects for change, too.
More resources come from public-sector organizations that
support others’ projects (later on, we shall look at how grant-makers are also
doing this when we consider the theory of change framework). Without making an
evaluation of the organizations behind these resrouces, I thought I’d share a
couple. Civicus, an organization
dedicated to infusing participation into projects, offers a useful action planning
toolkit. And New Hampshire state’s Endowment for Health shares an online slide deck
that walks potential grant applicants through a useful list of issues to
consider as they devise a workplan.
For a more explicitly instructional view of projects, here’s
the
introductory chapter of a text on workplanning, Getting Started in
Project Management (by Karen Tate, PMP and Paula K. Martin, 2001, Wiley).
Finally, I’m asking for your feedback to be posted as a
comment. What approaches have you used that work well? What tools are useful?
If you’d rather weigh in on a related discussion about the role of proejcts in management
education, take a look at this blog post, Do
we need a project project? and add a comment about that here instead.
I was in a sold-out crowd of Atul Gawande groupies at his book reading in Brookline on Superbowl Sunday. He thoughtfully discussed his ideas about the moral dimensions of practicing medicine. The focus of his new book,
Better, is performance and how to improve it. As I reread the introduction, I couldn't help but think that the same imperatives apply to management. See what you think--this is straight from that section of the book, with a couple of my own additions (I'm hoping he doesn't mind my use of his work here):
This is a book about performance in medicine [management]. As a doctor [MBA],
you go into this work thinking it is all a matter of canny diagnosis, technical
prowess, and some ability to empathize with people. But it is not, you soon
find out. In medicine, as in any profession, we must grapple with systems,
resources, circumstances, people—and our own shortcomings, as well. We face
obstacles of seemingly unending variety. Yet somehow we must advance, we must
refine, we must improve. How we have and how we do is my subject here.
The sections of this book examine three core requirements
for success in medicine—or in any endeavor that involves risk and
responsibility. The first is diligence, the necessity of giving sufficient
attention to detail to avoid error and prevail against obstacles. Diligence
seems and easy and minor virtue. (You just pay attention, right?) But it is
neither. Diligence is both central to performance and fiendishly hard, as I
show through three stories [....]
The second challenge is to do right. Medicine is a
fundamentally human profession. It is therefore forever troubled by human
failings, failings like avarice, arrogance, insecurity, misunderstanding. In
this section I consider some of our most uncomfortable questions—such as how
much doctors should be paid, and what we owe patients when we make mistakes. [...]
The third requirement for success is ingenuity—thinking
anew. Ingenuity is often misunderstood. It is not a matter of superior
intelligence but of character. It demands more than anything a willingness to
recognize failure, to not paper over the cracks, and to change. It arises from
deliberate, even obsessive, reflection on failure and a constant searching for
new solutions. These are difficult traits to foster—but they are far from
impossible ones. Here I tell the stories of people in everyday medicine who
have, through ingenuity, transformed medical care—for example, the way babies
are delivered and the way an incurable disease like cystic fibrosis is
fought—and I examine how more of us can do the same.
Betterment is a perpetual labor. The world is chaotic,
disorganized, and vexing, and medicine is nowhere spared that reality. To
complicate matters, we in medicine are also only humans ourselves. We are
distractible, weak, and given to our own concerns. Yet still, to live as a
doctor is to live so that one’s life is bound up in others’ and in science and
in the messy, complicated connection between the two. It is to live a life of
responsibility. The question, then, is not whether one accepts the
responsibility. Just by doing this work, one has. The question is, having
accepted the responsibility, how one does such work well.
So, what do you think? Must management professionals sign up for these same three goals--diligence, doing it right, and ingenuity? What can we learn from Gawande? Take a look at
his site.
"Writing is rewriting." This is something anyone who's written pretty much anything has had to learn. Writing well is not so much about punching out a perfect piece the first time around as it is about rewriting, editing, refining, and then doing it again. And almost always, getting someone else's input is also essential. Distance can also help: taking a break from the work at hand while you do something different that might allow you to approach the work again with a fresh perspective.
The same holds for learning how to become more effective as a manager, change agent, consultant, or other kind of professional. It's all in the iteration. And I think the iteration is central for learning but also for performing. You might as well embrace it--refining, adjusting, updating, rescoping are part of getting things done in every setting. This holds not only for the presentation you give to clients or the pitch you give to funders, but also for the model you build, test, calibrate and refine as a tool for making policy decisions. Process improvement rests on iteration. And of course iteration is essential to the process of developing a new product, piece of software, or business plan.
I've been thinking about the implications for teaching and learning. Making room for iteration may mean
trading in ambitiousness of your project or assignment in favor of higher goals for learning and performing. The task itself may have te be
shorter or
smaller in scale to allow the repetition to work its magic. I've learned that often for MIT students this means scaling back on plans, and taking what might seem like a rather trivial step, like a routine meeting, and treating it seriously. For instance, beforehand you might set aside the time to ask yourselves what you want--and expect--to happen in that meeting; what you'll look for to indicate how the meeting is going or if your expectations are being met. It means taking notes and being a careful observer during the meeting, and checking these observations with others. It also means taking the effort to reflect on the experience and the indicators afterwards to generate some insight and ideas for things you will want to do in your next meeting.
Our spring class met for the first time this week. I talked about the expectations for the class being high: we expect students do something every week. But I do not expect each of these things to be big things--I do not want people to do massively ambitious projects. I am much more interested in figuring out what it takes to be effective and in sqeezing the most learning that is possible out of every step. This usually means a more well-scoped project that is more modest than students initially want. That narrowing-in process is our goal in the first weeks of class, and it's inherently iterative. So, I am used to us starting out with big plans and then scaling back as goals become more defined.
We learned from recent experience we can extract a lot of insight from the routine as well as the momentous events in one's work. For instance, even writing a single email is a prefectly fine and appropriate action for the week. Writing a letter is another; and setting up a meeting is a third. All three of these are actual examples from last semester--they were extremely useful steps that we explored in depth in class discussions and that we referred to several times over the semester.
So, iterating to learn means two things for our class: recognizing that smaller and more modest plans are needed for learning, and embracing the discipline of not only getting something done every week but also figuring out what you are learning from it all as you go. For me, gathering my thoughts in a blog is one way to do this. How's that for practicing what you preach!