Specifications: Do We Know What We Want?
August 13, 2013
It is tough to make sales. It is tough to fill time at work when the company wakes up each morning asking, “What buzzword will we try to sell today?” Remember to distant days of mythical cities like Smallville. Stores sold shoes, fruit, and dry goods. Not today, companies pitch “services” like cloud data, analytics, enterprise search, and content marketing.
Little surprise: Computerworld ran a story with the Google-ized title “A Software Project with 6,000 Pages of Specs Ends Badly.” The application was a tax collection system. Not search obviously, but the key passage in the story could have been applied to a number of search, content processing, and analytics systems with which I am familiar; to wit:
In 2007, Orange County hired Tata America International Corp., a subsidiary of the largest offshore outsourcing firm in the world — Mumbai, India-based TCS — to develop custom software to handle most of the county’s tax functions. The county collects some $4.5 billion in taxes a year. Before hiring Tata, the county had used another contractor to develop the business documentation for the projects.That documentation ran more than 6,000 pages and outlined every aspect of the project, from legal requirements to operating systems.
Observations? As Groucho Marx said, “You bet your life.”
First, notice the prominent role contractors played into this alleged misfire. Contractors wrote the specifications. Contractors built the system. Who was responsible for the alleged floparoo? Contractors. In my view, perhaps the cause of the problem rests with the governmental organization and its employees. Without knowledge about the specific problem to be solved, the specifications embrace everything and anything those contributing to the specification heard at conferences, read in blog posts, and picked up from marketers’ sales presentations. Converting gibberish into a specification is similar to running a document from one language through a translation system a couple of times. Mix and match the languages and interest outputs result. Are the outputs usable? Nope. Amusing? Yep.
Second, notice that the matter is in the hands of attorneys. The progression strikes me as:
- No clear idea of the problem to be solved
- No inputs anchored in facts
- Contractors who converted inputs into a draft specification
- Rewrites fattened up the specification
- The specification was converted into a request for proposal or similar document
- Consultants responded to the proposal
- Individuals with “qualifications” to decide which vendor had the oars in the water reviewed the specifications
- The bidders revised the proposals
- Individuals with “qualifications” narrowed the field to a couple of bidders
- Presentations ensued
- Individuals with”qualifications” picked the winning bidder
- The bidder implemented the specification
- The “system” did not match the needs which were encapsulated in 6,000 pages of word brambles
- Enter the lawyers
- Read story in Computerworld
My question, “When will those buying software do the pre-award work necessary to get the best from a contractor?” Better yet, “Why not hire professionals who can do their job in a manner that produces software that solves a problem?”
The story reminded me of the messages I hear when I am boarding an airplane. Meaningless actions from meaningless thinking.
Stephen E Arnold, August 13, 2013
Sponsored by Xenky
Comments
-
- Subscribe to Beyond Search
Feature archive
News archive
-
