MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] FW: [legalxml-intjustice] GJXDM subset schema exa mple and documen tation
Thanks. Analyst at work. One more example before I
go... please, this is not in reference to anyone here
or the work of this group. It is just Tales of Nasrudin...
There is another category of RFP that is harder to work
with. A consultant, typically a retired industry professional
goes to school and gets a masters degree while reading a lot
of magazines and other works from which he/she abstracts a
computer architecture for a futuristic system, in their opinion.
One can spot these because they will
contain a mix of terminology that is long in the tooth
with some that is probably ten years into the future.
Because the consultant come from the industry, they do understand
perfectly the document types and processes, but the text
they contribute to the RFP is for an architecture that can't
be built today cost-effectively if at all. The RFP
is issued by a forward looking agency without vetting
it in the industry.
These are disasters unless the forward facing vendor
reps can get in there and adjust expectations, or the
vendor reworks the response to match the language of
the RFP but with all contractual details bound to an
implementable product. The trick is to specify
what can be delivered within the cycle. A typical
RFP is bid about 18 months ahead of implementation,
so any technology it includes must be road worthy
within that cycle. Because systems are built today
over frameworks from other vendors such as Microsoft,
Sun, etc., the system vendor is behind their curve
and until the platform framework vendor is ready,
the system vendor can't implement completely. So any reasonably
large procurement will be for a system that is somewhere
between four and five years behind the leading edge,
or will be a one-off that may be a cul de sac or may
be the prototype for the next generation.
The procurement official bets their badge on that.
len
-----Original Message-----
From: R. Allen Wyke [mailto:emergency-tc@earthlink.net]
Sent: Friday, March 26, 2004 9:46 AM
To: Bullard, Claude L (Len)
Cc: Art Botterell; Emergency TC; 'Rex Brooks'
Subject: Re: [emergency] FW: [legalxml-intjustice] GJXDM subset schema
exa mple and documen tation
<roundofapplause method="standing">clap, clap, clap</roundofapplause>
You are, as you have done so many times, hitting on the essence of both
the market, the opportunity, and the challenge. I can appreciate what
you are saying on many different levels (standards guy, author, CTO,
technology, business strategy, etc.). Putting on my Blue292 hat for
just 1 second, what you just described is what we call some of the
characteristics of the "nut". The nut we are trying to crack. It is
very easy to get absorbed into the trees and never see the forest.
Sometimes you do have to think different.
Allen
On Mar 23, 2004, at 5:20 PM, Bullard, Claude L (Len) wrote:
> A typical adoption will be something like, this early:
>
> o Must use XML for all external interfaces
>
> which is a very weak requirement. Then later:
>
> o Must implement CAP (version) for alerting to (cite receivers)
>
> or something like that, which is specific and a strong
> requirement. Ideally, by the time that strong requirement
> appears, a studious sharp vendor has done their homework
> and is within a year of fielding the features to support
> a requirement. Keep in mind, a single requirement can
> spawn multiple tasks and implementations in a single product.
>
> If you read RFPs, after awhile you discover that they are seldom
> written by the procurement organization, but by a consulting firm
> such as Gartner. There are some points of interest:
>
> 1. Some consulting firms analyse the organization's data and
> business rules and produce a tight specification based on the
> current organization. These are actually bad RFPs. They create
> many exceptions and a one-off custom product.
>
> 2. Some consulting firms have a boilerplate RFP consisting of
> the most common requirements they have discerned over some
> number of procurements. These are better because like a
> standard, they represent accumulated knowledge over a domain.
>
> The problem either of these have is that they may not follow
> the price domains, sometimes called 'market tiers'. These means
> the procurement is specifying a system which a given customer
> cannot afford to buy and the vendor cannot afford to build at
> that price point. If the evaluation group is doing a naive
> evaluation, say just counting nos and yeses, they may reject a
> bid that is actually closest to their price point and buy a
> system that cannot be delivered. The typical result is they
> lose the money invested and have to do it all again.
>
> As is easy to observe, this process affects commodization and
> thus, standardization. Over time, tiers tend to collapse downward
> and thus, smaller vendors with the right products at the right
> time can gain in market share by taking it from established
> vendors.
>
> Listening is everything. Timing is everything else.
>
> len
>
>
> From: Rex Brooks [mailto:rexb@starbourne.com
>
>
> To be honest, I doubt we could settle this notion of adoption uptake
> in RFPs here.
>
>
--
R. Allen Wyke
Chair, OASIS Emergency Management TC
emergency-tc@earthlink.net
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]