Subject: Re: FW: Open Source Developer Exchange (Economics)
From: "Benjamin J. Tilly " <ben_tilly@operamail.com>
Date: Wed, 30 Apr 2003 00:31:33 +0500

"Julius Steyn" <julius@solutionstap.com> wrote:
[...]
> My VC partners and I are about to invest in a venture that follow the
> proposed Operating Model and the to be proposed Business Model which I
> intend to share with you in the next few days, hence soliciting your input
> on the subject matter. Therefore if you do have a few moments to spare I
> would appreciate your comments and feedback as I intend to include them in
> the final proposal - if they are not already included. You may respond to me
> directly although I would prefer via the FSB as it may initiate additional
> valuable comments from other members of the list.

My first impression is that you really need to have an editor review the grammar
before taking this much further.  For instance in
http://www.devcity.org/opsmodel/index.php?section=corporate I found "corproate"
for "corporate", "sited" for "cited", "wit" for "with", "corporate" where you
really need "corporate customer", "a NewCo" for "NewCo", "administration" for
"administrative" and "divers" for "diverse".  Most of these will pass spellchecking
because they are valid English words - they are just the wrong ones.  This is in
addition to less glaring problems like some awkward sentences.

The content is well laid-out, but these details are critical for making a good
impression.

As for content, I think that you are missing a critical piece.  As things stand
you will see vague proposals taken by people who have no idea what they really
can do, and the resulting failures will burn out everyone and leave a bad
impression all around.  Many of these failures will happen for very predictable
reasons, and the biggest piece which NewCo can bring to the table is knowledge of
how to avoid this.

Therefore I would say that NewCo should reserve a large role for itself in project
management on every project.  No exceptions.  The exact role will vary, but serves
the following purposes:

1. Make sure that all parties are clear on what has been agreed to.

2. Make sure that what has been agreed to is realistic.

3. Let the customer know NewCo's opinion on offered contracts, and be sure that
   NewCo has appropriate coverage.  This is a complex judgement call, and it is
   exactly your ability to make it which your success depends on.  Not all
   contractors are created equal, and NewCo must acknowledge this.  If the
   customer wants to accept someone who you think has poor odds of success, you
   don't want to accept much liability for failure, nor would you want the
   customer to judge NewCo judgement based on that incident.  Conversely
   contractors with whom you have a good history should be pointed out.  Similar
   comments can be made about customers.

4. Make sure that there is a record of important communications available in case
   there is a later communication breakdown.

5. Pro-actively head off possible conflicts, and if they do happen, offer dispute
   resolution.  This is expensive, yes.  But less expensive than project failure.

6. In the event of breakdown, make sure that NewCo has a clear position on what
   happened, and what to do about it.  Hopefully this will only happen a small
   amount of the time (and less than it would without your efforts above), but the
   cases where it does will be major line items.

Other feedback?  Get good legal advice on things like the viability of non-competes.
This will vary widely by jurisdiction, and you need to figure out how you want to
handle situations where a customer goes through the RFP process, says, "I don't want
your services after all - we will handle it internally" and then privately contacts
the contractors that they liked...

> Your opinions and input is valued and I sincerely look forward to receive
> any constructive input or opinions in this regard

Hopefully what I am sending is useful.

Cheers,
Ben