OASIS Emergency Management TC

 View Only
Back to discussions
Expand all | Collapse all

RE: [emergency] FW: [legalxml-intjustice] GJXDM subset schema exa mple and documen tation

  • 1.  RE: [emergency] FW: [legalxml-intjustice] GJXDM subset schema exa mple and documen tation

    Posted 03-28-2004 17:25 
     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


Related Content