Karen,
I would argue that in the cases you described below, one is not simply
Buying. You are Buying+Building. Unfortunately sometimes decision
makers may not recognize this, or don't take it into account. I think
that is something that Jeremy hints at when he says Open Source can be
a buy. My take away in this regard is that there should be some
recognition in this document that most things will be a combination of
at least 2 of the 3 Bs.
Edward
On Fri, May 7, 2010 at 9:48 AM, Karen Coyle <[log in to unmask]> wrote:
> Quoting "Frumkin, Jeremy" <[log in to unmask]>:
>
>>
>
>>
>> In general, a Buy approach is easiest to determine TCO, while a Build
>> approach is the most difficult. Generally, there are more unknowns with a
>> Build than there are with a Buy. The more unknowns, the greater risk of
>> inaccurate cost estimates.
>>
>
> I know this is the common wisdom, but I've had experiences where Buy turned
> out to be much more expensive than expected. If the product is mature and
> stable and you expect to do almost no customizing, yes, then Buy is
> predictable. But if you're on the cutting edge, it's a new vendor offering,
> you expect to customize, then Buy can have all kinds of hidden costs. In the
> end, Buy can be more expensive than Build because you have to struggle with
> a product over which you have no control.
>
> When pitting Buy v. Borrow v. Build, functionality has to be taken into
> account. What do you want the software to do? How big is the market for your
> functionality? (that is, are vendors likely to step up to this plate?) Are
> vendors already offering this?
>
> kc
>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
|