Re: A "co-developer" | <– Date –> <– Thread –> |
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.