Ed Brenegar writes:
> If you are negotiating a contract for a project either internally or
> externally, how to design that contract to make learning a core value of
> the contract? If we are serious about learning, how to we structure it
> into our proposals for projects?
I'll take a stab:
One of the emerging themes in software development is risk management;
this arises in part because you don't know at the beginning of a project
what problems may arise, what misunderstandings and conflicts exist, how
the stated requirements might change, etc. Unless the contract is between
parties that know each other well and have experience working together,
it's wise to structure the contract and the project to allow for the kind
of learning that recognizes and reduces risk. There are emerging methods
and structures for doing this; see e.g., Barry Boehm's work on the Win-Win
Spiral Model at http://sunset.usc.edu/. Among other things, his approach
helps the parties learn more about their core "win conditions" for the
project.
Another kind of learning that could be built in would be an agreed-on
process for a project post-mortem that would elicit lessons learned, such
as what went well vs. not so well. Of course, this kind of thing can be
very sensitive, and would need to be handled delicately.
Of course, this assumes that the parties are open to learning at the time
of drawing up the contract. All to often, the client takes the attitude
"I know exactly what I need; I don't want you telling me different" and
the vendor the approach "I know exactly how to deliver whatever you want".
This leaves little room for learning of any kind.
--Don Dwiggins Proposed definitions: SEI Information Technology "Training: to be prepared against surprise d.l.dwiggins@computer.org Learning: to be prepared for surprise" Martine Devos
Learning-org -- Hosted by Rick Karash <rkarash@karash.com> Public Dialog on Learning Organizations -- <http://www.learning-org.com>