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