Re: A "co-developer"
From: David L. Mandel (75407.2361CompuServe.COM)
Date: Tue, 14 May 1996 01:07:48 -0500
(PLEASE SEE ADDRESS CHANGE NOTE AT THE END OF THIS POSTING)

Rich Lodbill asks about the advisability of hiring what he calls a
"co-developer," mostly to increase the chances of the project actually being
built. He then lists a bunch of "advantages" that imply an extensive list of
roles this person or company would have.

A few comments from the benefit of (my perception of) our experience at
Southside Park, which I'm sure is very different from others' experiences ...
and which segues nicely right into my main point: That the answer is a lot more
complex than a simple yes or no and that the circumstances and needs of each
project should dictate whom to hire for what roles.

To amplify a bit: You are defining roles for your "co-developer" that presumably
reflect the holes you perceive in your group's ability to do the entire job
itself. That is actually a good thing, because if you need outside help, an
important first step is to identify the roles you need filled. But your holes
encompass a lot of roles that don't necessarily work best when concentrated in
one person. For instance: a red light flashes "conflict of interest" when you
envision having the same entity assume significant financial risk and also
oversee the construction process. I see too much potential for an interest in
cutting corners to save costs, especially if the prices you'll pay for the
finished product have already been set and the outside investor will profit from
savings. 

At Southside Park, we essentially undertook the financial risk ourselves, so in
theory, the builder had no incentive to cut corners; when choices had to be made
that might involve additional costs, we had to bear the primary consequences
(higher house prices, which were set only near the very end of the construction
process). This led to some other problems, however, in that our builder had no
incentive to keep costs down when that could have been done without adversely
affecting the product. We had to work that part on trust and by exercising
maximum supervision, together with our architect, who also had no financial
stake in the cost. (It's not completely true to say that the builder and
architect had no risk, because if the whole thing had fallen apart they would
not have been paid much, if any; but that's still different from having them
actually invest capital in the project, with a reward for coming in under
budget.)

The bigger problem we had was hiring the same firm as architect and project
manager. There was too much gray area between the dual areas of responsibility
and we ended up paying far more than originally contracted. Also, architectural
changes were made without our knowledge and contrary to our instructions. A more
vigilant construction committee on our part would have helped, but a more
independent project manager would likely have called our attention to these
changes, some of which we managed to reverse, but at our expense.

One conclusion I would note here with the benefit of hindsight is that unless
you find a saint who will do everything with the buyers' interest paramount,
it's better to hire separate professionals to undertake distinct roles, trying
to structure their interfaces in a way that puts checks and balances into play.
The possible downsides to this, of course, are a higher total cost due to
multiple contracts and the potential for conflict among the various
professionals; but if you pick mature ones and define their roles carefully in
advance, perhaps these can be avoided. I'd love to hear from projects that
successfully employed this method.

The other strong recommendation I'd make is to do your utmost to have effective
oversight by members of the group themselves. The very best might be if one or
more members have sufficient expertise to be hired by the group for the project
management role (and a lot of the tasks you list in your "advantages," Rich, are
in this category). At very least, put detailed requirements for information and
consultation with the group in your contracts with the architect, project
manager and builder. And follow through to make sure they are fulfilled.

Your advocacy for a "developer" made me start wondering about the definition of
that term. I don't know that there is a standard, agreed-upon meaning. The more
I watch development of cohousing, the more I think it can mean very different
things in different situations. Conventionally, I guess it's a person or company
that's in the business of getting things built, but even there, developers seem
to play very different roles at different times and places. 

Any cohousing group is by definition its own developer, I would say; and the
more roles it can fill effectively on its own the better off it likely is. The
trick is to be able to recognize what holes need to be filled by outside
professionals and to allocate those roles in the most advantageous way, building
in checks and balances while avoiding too much concentration of power and
duplication.

I think there is no one formula for determining the right mix. It depends on a
multitude of factors that must be determined for each project -- hopefully with
the benefit of others' experiences. Good luck.

David Mandel
Southside Park Cohousing


Please note: This is being sent from my old e-mail address because I haven't yet
succeeded in getting cohousing-l to change my address and I'm afraid it won't
accept my post from the new one. But please consider this defunct and use my new
address -- dlmandel [at] rcip.com -- for any future correspondence.

  • (no other messages in thread)

Results generated by Tiger Technologies Web hosting using MHonArc.