This is an opinion. The writer has years (it's not polite to ask age from a programmer) of experience in IT service industry, and has been among only failed sales efforts. And is afraid that they don't actually differ much from succeeding ones.

 

What is a requirement? Or a feature request? Or a service request? What is a badly started blog-post?    

 

They're all an attempt to communicate something to someone. For starters I'd like to restrict the environment and domain to a very special one: IT service companies and their endeavors. I'd make a bold statement that most of such attempts will fail blatantly. 

a Contract

A Contract is a rather tender piece of communication. A something you usually would not like to be misunderstood by either party, not if you're hiring a hit-man, or when you're contracting a medical equipment manufacturer. Contract, when negotiated, is usually deemed to be 'important'. It's something that 'must not fail' yet we feel no worry for letting supplier strut their stuff in black box. We might even feel odd should they propose some kind of continuous communication scenarios.

It's rather funny that even in big service companies the developers and educated project personnel have largely adopted the attitude that initial attempt to communicate on contract level will fail. In other words: negotiating and promising the large scope upfront will manifest itself to a hell-hound that bites your ass for the next three quarters.

Funnily enough, some of us want to correct the possible major fuck up with... more communication. But there's a catch: the continuous flow of communication (maybe iterative, maybe flow) gives us the possibility to learn the domain at hand with the provider and with the client.

Hunam

But who the fuck would initially confess that he/she is bad at communication? Not the persons buying, and especially not the person selling. Given the fact that there's usually a significant amount of money involved, personal money, in deal closings maybe in both sides, it would be disastrous to admit uncertainty.

Or at least, well, who cares, the errors will be corrected  at some point later . It's more fun to sign 1M to 1Q, than 250K to Q1 and possibly 300K to 2Q, given that delivery doesn't fuck up. No matter the reputation lost after few years when the project will be publicly announced as failed.

Makes sense, no?

It does, because in service business, the value is not in deliverables (in most cases, I'd dare to say). It is in the work to be done. I'd say that this is the main reason some people doubt that "small companies could do government projects" for example. 

A thought that is based on completely wrong value, given that it's the actual deliverable and its quality that matters shit to the buyer.

If I could draw, I'd draw an inflatable mountain here, imagine that.

The pact is perfected, if delivery on suppliers side is separate from the entity that did the sales. Everyone has a safety mechanism: customer who thinks he knows what he wants, seller who sold something he's not entirely sure but it got bought, and delivery who's wondering why they're required to manufacture a square to fit a round hole, but well, they were asked to.

It will soon become a three-some where everyone is feeling rather awkward, but is too afraid to say it because A) it would look stupid, B) There's no communication mechanics agreed with delivery and client (this may even be forbidden).

F-word

The one unit that does the act of communication better than any, is a gang of friends. Friendships are rarely formed in seconds, and one could argue that maintaining a friendship takes some effort. One "gain" of friendship is some kind of caring of one another, and this causes few things: we care about wellbeing of our friends and we become skillful in communicating with our friends

We rarely need any mechanics for communication among friends in effort to make ourselves understood, but it's a bit different when dealing in enterprise environment, where the exploitation of different systems starts from incentives, and well, it ends to incentives too. 

These mechanics might be something called "business analysis", and in some project and development techniques they're mapped to certain roles, but I'd argue that it's not a single spot, nor a role that implements the mechanics that could actually work. Lately I was listening a speech by Chris Matts about feature injection and "exampling" and that certainly is one mechanic, not tied to a role of business analyst mind you.

It's equally important to have the communication tools and mechanics in place for the whole project. With my fresh experience from a project where something like such was agreed to be done, I'd say it's equally important to follow that the mechanics are honored.

Common to these mechanics is the fact, that they tend to admit that understanding something right the first time is rather an exception than a rule. In contract phase that is a tough spot to admit, thus these mechanics are easily left out just because we either cheat ourself, are afraid to look stupid or have a two way incentive deal. Two of the three things are human traits, one is the cancer in our industry.

Analyst and communication mechanics (throughout the project from customer to delivery to customer again) are there so that we can safely admit the inevitable, and have the freedom to learn together in order to become good communicators.

 

It ain't no friendship, but at least all three of us can sleep in one bed cuddly together.