[Sigia-l] Extranet software

[Christopher Fahey [askrom]]

> 3. Build-from-scratch is inherently wasteful because it a) 
> reinvents the wheel and b) takes a great deal of time/money.

I have to agree that this statement is way too general. 

With respect to (a) (the risk of reinventing): In my experience it is
rare to find a "pre-packaged" (and I know this is a general term)
solution for which you cannot avoid paying for a large number of
unneeded features, or for features which are implemented slightly
differently than what you would prefer. Building from scratch is often
preferable because (1) you only pay for what you need and (2) you get
exactly the features you want implemented exactly as you want them.

With respect to (b) (the cost): Pre-packaged solutions tend to be pretty
expensive, too. Ever shop for a CMS? Whew! Pre-packaged solutions are
deliberately priced so as to be very close, but not more, than what a
potential customer *thinks* it would cost to build-from-scratch. If your
staff is already very busy on other projects or if their skill set is
narrowly specialized, then getting a pre-packaged solution may likely be
cheaper than assembling a team to design and build something in-house.
But if you have a clever and nimble staff, or if you are
organizationally flexible and able to ramp up with freelancers, or if
there is no time-to-market pressure, you may find that the
build-from-scratch price point falls well below that of the pre-packaged
solution and delivers a more suitable product. 

One of the key potential functions of a good information architect is to
assist in the "buy or build" decision making process. Too often the
decision is made before the IA has thoroughly documented the feature
requirements. The decision to "buy" is sometimes driven by the reality
that the organization is not at all sure what the requirements are and
are simply betting that a pre-packaged solution is likely to satisfy
those requirements - if it's bloated with features, chances are it'll do
what you need it to do once you figure out what that is. By having
detailed functional requirements early on, the "buy or build" (or "which
one to buy") decision is much more likely to be correct.

-Cf

[christopher eli fahey]
art: http://www.graphpaper.com
sci: http://www.askrom.com
biz: http://www.behaviordesign.com