Pp 4(b)

• Start wisely. Your initial step is important, for the design process is
somewhat “path dependent.” That is, you may see, or not see,
relationships and possibilities differently depending on when and how
in the trial-and-error process you come upon them. For better or
worse, there are several different ways to choose a first step. Hunch
and experience are probably more important in making this choice
than any strictly logical or analytic guidance. Consider the following
possibilities:

• • Start with the least flexible design element. In our mass transit
example, you might assume that budget constraints on the purchase
of new rolling stock foreclose a large number of design options.

• • Start with the most “powerful” design element.
• By powerful, we mean that the element, once chosen and its likely
value assumed, strongly suggests the next most important element to
consider. Once those two elements are chosen, the rest more or less
“naturally” fall into place. To do this, you need a realistic theory of
cause-and-effect that, to some extent, links the various elements.
Although a perfect theory is probably lacking, some rough guesses
can usually suffice.

• In the mass transit case, I would guess that supplying disincentives to
single-occupancy auto use, in the form of tolls or congestion fees,
would probably be the best place to begin, the theory being that mass
transit use depends on making private autos a comparatively less
desirable mode of transportation. That theory could also suggest
making mass transit more attractive, perhaps by decreasing fares. But
my own hunch is to start with disincentives to auto use, which I
suspect would be more powerful than making mass transit marginally
more attractive.

• • Start with the most robust element.
• Since there is always a possibility that the complete, and ideal, system
will never come into being—politics and budgets being volatile and
uncertain—it might be a good idea to put something in place that
would be socially valuable all by itself. This might, for instance, be
some sort of limited set of elements (a subsystem, one might say)
involving discounted bus passes for employees of large traffic
generators.

• • Start with the most transitory, and least costly, element.
• I am thinking here of grant-in-aid windfalls that typically come from a
higher level of government and that might, by design or by accident,
disappear in a year or two.

• Check your assumptions as you proceed.
• The trial-and-error process requires, first, creative imagination and,
second, rigorous evaluation of what creative imagination comes up
with. The most commonly applied evaluative procedure is to generate
what are known as “logic models.” This involves spelling out in some
detail, and often with the help of graphic aids, how the emerging
system is supposed to work.

• Presently, a leading source of ideas about how to do this is the W.W.
Kellogg Foundation “Logic Model Development Guide,” (available
online at www.wkkf.org). The Kellogg Foundation’s approach is to
divide the planned program or, in my language, system into six parts:
resources/inputs, activities, outputs, outcomes, and impact. The
modeler is supposed to fill in the details in each category and to
specify the assumed relationships.

• In general, this approach assumes a production model, in which
services of some kind are being delivered to a recipient population by
a governmental or nonprofit organization. The model can be applied
to nonproduction systems too, for example, regulatory systems,
provided one is creative enough with filling in the “activities” section,
which works as a catch-all for the complexity of relationships among
system elements.

• Another, very similar, approach, designed explicitly for service
systems, is “service blueprinting.” It goes somewhat beyond logic
models in that it also asks the modeler to specify assumptions about
“offstage” and back-office support functions.

• Design problems usually have two stages. These stages are (1) design
the system as it is projected to run in its steady state, and
• (2) plan the strategy of change that would take us from here to there.
The first stage is predominantly technical; the second, predominantly
political and bureaucratic.

• Designing a case processing system.
• Design problems are generally of two types. One involves the
management of “cases,” by which I mean individuals or other entities
(such as firms or communities or lower levels of government) that
receive some kind of “treatment.” The treatment may involve delivery
of a subsidy, regulatory imposition of obligations, or application of
some sort of person-changing regime (such as educating children or
getting offenders to “go straight”).

• The second principal type of design problem involves operating on a
collectivity of some kind rather than on individual cases—for example,
improving traffic flow, eliminating corruption in the police
department, preserving habitat, or launching a community clean-up
campaign.

• The second type is too varied to discuss here, but a program that
manages cases fits a rough template. That is, we can lay out a general
procedure and list questions that should be asked.
• I use the term program deliberately, to refer to an organized
ensemble of routines. For instance, a program to distribute subsidies
has routines for determining eligibility, calculating the amount to be
paid, and detecting and deterring fraud and abuse. A regulatory
program has routines for enforcing compliance with its rules,
including inspection procedures and formulas for applying sanctions

• It may also have routines for adopting rules, giving technical
assistance to regulated parties, and offering forbearance in exchange
for more efforts to cooperate. In a person-changing program, the
routines typically bring the subjects into a setting where change is to
be rewarded, facilitated, induced, or demanded, and where
professionals apply a whole kit of tools to the change process. Think
of schoolchildren, classrooms, and teachers; or of patients, hospitals,
and doctors; or of welfare recipients, training programs.

• The logic model and service blueprint approaches can work for these
types of programs, but each approach needs to be amplified to take
account of two design levels, the individual and the population.
Presumably, the analysis has to be done for each of these two levels
separately. For instance, in a weatherization program, design issues at
the individual case level might involve rules covering eligibility, what
sort of weatherization measures to use in a particular type of dwelling
unit, copayments (if any) that the agency charges the customer, and
what sort of guarantees (if any) to provide the customer regarding
performance.

• At the population level, another set of design issues intrudes, such as
which type of customers to target, how to allocate weatherization-
counselor time among target groups, whether to manage counselors
by geographical districts or by types of functional expertise, how to
handle customer complaints, and the like.

• In confronting the inevitable design trade-offs at the individual level,
it helps to look at any set of routines from two perspectives: that of
the case manager in the agency and that of the citizen whose case is
being “treated.” It often happens that routines designed to make life
easier for program staff only make life harder for citizens. (“Sorry, we
don’t give advice about that; send in the application and we’ll
respond . . . .”)

• It also helps to remember occasionally to go back to basics, to
reiterate to yourself and others the main objective of the program.
What social problem is supposed to be ameliorated? Or what existing
program is to be redesigned to accomplish what objective better?
Doing so presents an opportunity to think also about an often-
neglected but very important design issue of a more instrumental
kind: what evidence will you systematically collect in the course of
normal program operations that can let program managers know
whether they are succeeding? That is, what tracking and evaluation
routines can be designed and put in place?

• Another common set of design issues revolves around making
adjustments—sometimes large, sometimes small—in an existing
organization or inter-organizational network, so as to improve
performance.

• A little help from your friends—and enemies, too.
• In some cases, the policy analyst works on the design problem more
or less alone, like some brooding master architect. More likely, she
does her work in loose or tight conjunction with other policy
professionals who bring to the table different sorts of expertise (e.g.,
legal, engineering, fiscal) and who bring different viewpoints and
priorities, as well. In any case, sooner or later, the design work will be
held out for much more public view. Interested stakeholders, and
perhaps more diverse audiences, who have previously been unaware
of the design work going on seemingly behind the scenes, will see
what you’re up to. And they will offer their reactions.

• You will want to use such reactions for two purposes: to improve your
design according to criteria that you and your client—and very likely
your audiences—think are important, including the criterion of
political feasibility; and to respond in such a way as to increase the
political support (and decrease the opposition) that may come your
way, now or later, on process grounds alone.

• Not surprisingly, a middle ground is best.
• A very rough and admittedly tentative design may leave out
important points, creating a sort of vacuum that outside interests will
rush to fill on their own terms. You will then be forced onto the
defensive, as you try to forestall the solution they have been first to
suggest. Moreover, a very rough design may signal that the design
work is at such a preliminary stage that it is not worth the trouble (or
the risk of early-mover vulnerability) for any of the stakeholders to
react at all.

• On the other hand, an overly polished and seemingly definitive design
may signal to stakeholders that you are not interested in consulting
them. In that case, they may feel that they have no choice but to
oppose your design more vehemently than they otherwise might
have done—unless, of course, they conclude that they have no choice
but to get on board and negotiate for the best terms they can
manage.

• Assuming that you have put out a rough-but-not-too-rough design
and elicited a range of fairly thoughtful opinions as a result, you will
need ways to keep in touch with the variety of actors who now
expect—and whom you may wish—to be part of an ongoing, if rather
diffuse, design process. Keeping in touch will require a
communications infrastructure (telephone, fax machine, e-mail, chat
room), of course. It will also require efforts on your part to develop
the sort of network relationships that permit rapid and reasonably
trustworthy interpersonal communications.

• At a more analytic level—because any design must be anchored in
working assumptions about its objectives, available resources, and
constraints—you should choose your assumptions with an eye to
their reasonableness as “a basis for further discussion.” You may feel
some discomfort at putting forward such assumptions because they
are hypothetical or speculative, and because critics might therefore
challenge them as “lacking in rigor.” Policy analysis is not just an
exercise in truth-telling, however. It is a pragmatic and responsible
effort to facilitate reasonable discourse about a policy future that is
inherently uncertain.

Pp 4(b)

More Related Content

What's hot (15)

Similar to Pp 4(b) (20)

More from Zeeshan Murtaza Ali (18)

Recently uploaded (20)

Pp 4(b)