Done and done. Thanks!
I don’t think the car analogy is the best, since cars are off-the-shelf products and we’re talking custom-built software with some hardware.
I’m a project scheduler by trade; I’m one of those sick freaks who is good with Gannt charts and other ghastly stuff like that. 
Salesmen can’t do technical requirements any more than turtles can play tubas, IMHO. It is a management failure to have them handling anything but the most general requirements.
The requirements phase of a project is the most crucial, because the contractor will already know how to design, code, test and deploy. They don’t already know exactly what to design, code, test and deploy.
They may not like it, but Bozo the Client must provide exacting, robust requirements in order for this process to actually work. If they expect contractors to be mindreaders or to build more than is requested, they’re idiots.
And that’s fine if you want an off-the-shelf car that will do most of what you need and some of what you want and you can work around the rest. Say a station wagon that will carry all the kids & critters, and has a spiffy backseat DVD player for long trips - but won’t haul your trailer, so you decide that’s OK 95% of the time and you’ll rent a truck for camping. Part of the reason this works is because you have a pretty darn good idea from previous experience of what you need in a car, what you want in a car, and what you can or can’t live without in a car.
My company uses a number of off-the-shelf software packages that we’ve purchased because it’s easier and cheaper than building our own. And I can guarantee you, because I’ve been involved in both developing design specs for an in-house build and translating those same design specs to use for reviewing vendor software, that customers often don’t know those things when it comes to software. In one case, where I was sole developer working part time on a huge project that kept growing, (and one where my manager had changed all of my estimated timelines, because “that will be too long”), I wrote up a specs requirements package and we looked at subcontracting the design. When all the bids came back in the $70K range, they did stop bitching at me for not getting it all done in my spare time between other jobs, and decided to go with an off-the-shelf solution, so I translated the specs for that. When they actually started looking at the available software, suddenly all kinds of things that had been ABSOLUTELY IMPERATIVE and things that they COULD NOT POSSIBLY LIVE WITHOUT, but couldn’t get in the packages they were willing to spring for, became surprising flexible and “oh well, we don’t really need that anyway”.
IME, #1 is usually the case. Even when I try really, really hard to work with the customer to figure out what they want and need. On the other hand, both as a developer who has had managers make promises and as a purchaser when doing software comparisons and recommendations for our business, I will tell you this: SOFTWARE SALESMEN LIE. THEY DO IT ALL THE TIME. JUST LIKE CAR SALESMEN. Please note that this is a broad generalization and should not be construed as an individual attack. I know that there are actually some salesmen who don’t lie, but a hell of a lot of them do.
And if my customers would only do that, my life would be a dream. Really. But that’s exactly what doesn’t happen. Even when you ask them over and over, and sit down and discuss their business processes, and everything else you can think of. They still come up with something later, whether it’s something they forgot or something that they saw really cool on a webpage somewhere.
I agree the car analogy isn’t perfect, but I think it could be a good place to start with non-tech people, to get them out of the “but you just need to put a button there and it will magically work” mindset.
Coming from the other side, the ones ordering the programs, it’s the evil corporations and their fucking turfs which are at fault. The people who understand the least about what is needed are the ones in charge of ordering the system. You get the accounting / finance department in charge, and they only know numbers which come up on their screens. They have no idea what the company actually does or how to implement the system.
At my last company, I was in the import division when General Affairs decided they wanted to expand their database to include functions which the import division (which I was a manager in). We had a inventory database, but it didn’t take have ordering or purchasing (which was the territory of the Import Division, and a host of other information.
GA had completely fucked up the description, what was needed, etc. etc. In Sage Rat’s analogy, GA was asking for sedans, when the company really needed pick up trucks. In fact, GA was having meetings with the contractors asking about the paint color, when no one knew what the hell the vehicle was supposed to be doing. Put non-techinical people with only a shaky grasp of the business flow in charge of a project, and that’s what you’re going to get.
Fortunately, things had gotten so bad that their programer was complaining.
The director of GA wanted me to come in an say two or three things in a meeting, just enough to get him out of trouble, which is the first time I was aware of how screwed up the project was. I had the president’s ear, so I got him to put me in charge.
(A little background here. I’m originally an EE, so I’ve had my share of programing classes.) I had put together a system with Excel and Access which automated thing to the point we were able to eliminate three people.
I met with the inital contractor, determinded that they were incompetent at best or, more likely, dishonest. I fired them and threaten to sue if they asked for money. Before we hired the next contractor, I spend three months tracking every single shipment into our company, and asked each person who was involved what they had to do, and what information they needed. Among other things, I discoved that the total value of each shipments was being recorded 19 times by 7 different people in the organization.
I had meeting after meeting after meeting, until we hammered out what was required, why people did what they did and how could shared information help.
The orignal bid was $300,000, the programing was supposed to take six months and training (and reprograming) for three months after that. A total of nine months.
I spent three months determining the specs, one month qualifying vendors, three weeks of meeting and then they required only three weeks to write the programs. Training was done in one week, and there were only a few rewrites (mostly become this one bitch lied to me about her job, but that would have been a pit, had I been a doper then.)
The chief programer of company which did the job told me he’s never seen anything as clear as my specs. He took me out to this great sushi place to thank him for making his job fun.
Oh, and the cost? Less than $75k. And as a bonus, the system actually worked.
Totally agree. Hit Mr Businessman in his stomach:
Yo, Mr Suit-and-Tie, over here in hairnet, excessive lipstick, and nicotine stains is Tammi Lunchtray, fresh (sort of) from her stint in the Middleschool cafeteria where she does, authentically and demonstrably, professionally prepare food. To my right, meanwhile, is Chef Delouise Macandule, alumnus of Culinary Institute of America and now managing a fourth spectacularly-popular upscale four-star restaurant. Where ya wanna eat? Ms. Lunchtray is cheaper and it’s all food, hey?
… umm, am I about to be majorly disemboweled by cafeteria employee board members any moment now?
::starts assembling defense::