Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
12<br />
nia, finished in September 1975. In July <strong>of</strong> the<br />
next year, Sweet led a team that completed an<br />
innovative design for a project in eastern Zaire<br />
(today’s Democratic Republic <strong>of</strong> the Congo,<br />
or DRC). Mickelwait and others, meanwhile,<br />
helped USAID design projects in Afghanistan,<br />
Asia, and Latin America. Of these, it was the<br />
Zaire project, in the remote province <strong>of</strong> North<br />
Shaba, that proved to be a game-changer for<br />
<strong>DAI</strong>.<br />
Turn to Implementation<br />
In the 1970s, for many development pr<strong>of</strong>essionals<br />
with high-level academic training, producing<br />
evaluations, sector studies, and project designs<br />
was challenging and fulfilling work. The assignments<br />
drew on their specialized training,<br />
the scopes <strong>of</strong> work were intellectually rigorous,<br />
and the resulting publications were a way to<br />
earn status and respect in the field. In the era <strong>of</strong><br />
“blueprint” planning, the actual work <strong>of</strong> implementing<br />
projects wasn’t considered terribly<br />
interesting or challenging. But by 1977, one <strong>of</strong><br />
the things being debated over <strong>DAI</strong>’s lunch table<br />
was whether the company should try to get into<br />
implementation. Elliott Morss, who always kept<br />
one foot in academia, insisted the company<br />
should stick with its highly regarded studies.<br />
It might be a “niche” business, Morss conceded,<br />
but it would maintain intellectual rigor<br />
and avoid entanglement in the messy details <strong>of</strong><br />
supporting teams at remote overseas locations<br />
with all <strong>of</strong> the attendant logistical and financial<br />
responsibilities.<br />
But there were powerful arguments in favor<br />
<strong>of</strong> pursuing implementation contracts. One<br />
was self-evident. Winning them would provide<br />
greater stability and higher revenue that could<br />
enable <strong>DAI</strong> to at last become a pr<strong>of</strong>itable enterprise.<br />
There was also a compelling substantive<br />
reason. In the blueprint days, splitting up design<br />
and implementation might have been reasonable,<br />
but if one accepted the premise <strong>of</strong> the<br />
process approach, it followed that implementation<br />
was no longer an afterthought—indeed, the<br />
constant monitoring, evaluation, and readjustment<br />
that the process approach called for was<br />
the essence <strong>of</strong> good implementation. If <strong>DAI</strong> was<br />
going to be true to its own principles, it would<br />
have to see how its concepts panned out in<br />
practice, and sustain its learning process over<br />
the full project cycle.<br />
There were different models for managing the<br />
new generation <strong>of</strong> rural development projects.<br />
Whenever possible, it was preferable to work<br />
through existing institutions in the host country.<br />
That way, local norms and culture would be<br />
respected, stakeholders’ commitment would<br />
presumably be higher, and there was much<br />
more likelihood that the project would be selfsustaining.<br />
But that was not always possible.<br />
Local institutions, where they existed at all,<br />
might be failing, weak, or corrupt, requiring the<br />
donor and its implementing partner to field a<br />
project management team, its size and relationship<br />
with local structures determined case by<br />
case, project by project. That field-level engagement<br />
meant a huge expenditure <strong>of</strong> time, exper-