Something I do a lot of at work is Bids. Most people are presumably unaware of the machinations that go on when a large company, government or military organisation buys itself a monster IT system, but they're complex, all right. And hard.
Here in Europe, it starts when the organisation publishes an ad in the European Journal, laying out the thing they want - a callcentre, a document management system, a system to help the police solve crimes etc. (Non-Europeans can substitute their own objects and establishments.) Next, interested supplier companies who think they can do the job write in, 'expressing an interest'. The Client then sends the suppliers a Pre-Qualification Questionnaire (PQQ), which usually asks basic question about the Supplier's finances, ability to tackle the job, previous work references and so on.
If the Client thinks you have what it takes, they will then send the Supplier an Invitation to Tender (ITT), and this is where the going gets tough and expensive. An ITT is usually a thumping great document that the Client has built up over months - even years - and which details exactly what they (think they) need. The nasty bit is the client Statement of Requirements (SoR), which will specify everything from the number of system users to the response time for data accesses. Essentially, they put down every damn thing they can think of. Somewhere in the document, they'll usually break those SoR requirements out into a spreadsheet-style matrix, with each requirement numbered, supplementary information if any, and some sort of flag to say whether the requirement is Mandatory or just Desirable.
The Supplier then has to submit an actual Tender - another even bigger document (usually about the size of a large novel) that describes in even more detail exactly what they plan to do in order to satisfy the SoR. You have to satisfy all of the Mandatories, and unless the competition is pretty weak, you'd better satisfy all the Desirables too.
Consider the size of this task: you have to design a complete, large, complex IT system. It has to satisfy many tens, and sometimes hundreds, of tightly-framed user requirements, including performance times. You have to build the system out of existing commercial software packages as far as possible. Custom code is expensive: it costs a lot to develop; it breaks and costs even more to fix; operating system upgrades break it; upgrades to the other packages in the system break it; no-one else in the world is using it, and your company is the place where any future buck will stop.
The commercial packages in the system have problems of their own: they, too, break. Operating system upgrades do strange things to them. Their long-term interoperability with other packages can't be guaranteed forever. Sometimes a new version of a package will have some characteristic that makes it useless as part of the system. Sometimes the company that developed the package will take years to respond to an OS upgrade, holding the rest of the system back.
So you have to be careful, and that's even harder than it sounds. Chances are that at least some of the features in some of the packages you'll need to use are things you don't know well. Sometimes the whole damn component will be new to you. Under those circumstances you're pretty much forced to take the word of the package supplier on trust, and those guys are very keen to sell product.
You're following a Client specification that probably took them from six months to a couple of years to write. You, on the other hand, usually have less than a month from receiving the ITT to the day you hand the Tender in.
The ITT is written by people intimately involved with the context of what's missing from their lives - they know all about problem. Trouble is, they don't really know all that much about the solution, or they wouldn't be asking someone else to do it for them.
Note that the fact that you're designing this thing on paper, and don't actually have to build it on the spot, doesn't really give you much room for guesswork. If your creation is accepted, your company really will have to build it - at the cost you specified. We're talking millions of quid here. If you get it wrong, and the actual solution needed is bigger and more expensive, you can be sure that the extra money will be extracted from your gluteus with pliers. And then they'll fire you.
Not only do you have to design this system from scratch in a few weeks, your solution has to be cheap, too - at least cheaper than the competition's, and, of course, you don't know what they're going to be charging. The ITTs always have some burble about how they don't undertake to accept the cheapest quote, and that it's 'value for money' that they're after. The fact is, though, that any Supplier who is not the lowest bidder better have a damn good story to tell, because the Client's bean-counters will usually have the final say, and technical excellence and other considerations tend to be secondary.
(So serious a factor is this, that dark rumours abound of companies who virtually give their solution away at cost, and then squeeze money out of the client using every possible trick: £100 to make a phone call; £2000 for an on-site meeting and so on. Anything not written into the bid is charged for, at vampiric rates)
The result of this cost-cutting is not, as one might have hoped, a massive saving to the taxpayer. Instead, it means that over time the IT infrastructure of government, police and military is powered by systems that were probably at the end of their tethers from the day they were installed, and from which every conceivable unstipulated spare capacity has been shaved. The next time you hear about some gigantic, newly installed tax computer or hospital resource management system falling over a week after installation, reflect that some bloody accountant probably insisted they go for that one, even though the engineers knew that a much better system was on offer for a little more wonga.
Bids - horrible, stressful things, requiring blood, sweat, lousy hotels, grim food and late nights. I have to do them all the time.