 |
 |
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 >