I.T., Leadership and Creativity

...is rearing its ugly head in my world, as I work on a sales pursuit in the Pacific North-West. The prospective client has a (self-admitted) poor track record in defining and managing requirements. Ever since I started work in I.T. 30 years (!) ago, requirements have been a consistent theme in my work life. I started out as a maintenance programmer, and rapidly discovered the phenomenon of the dissatisfied customer. Conversation goes something like this:
Customer: This does not meet my requirement
I.T: We coded it according to the specification
Customer: Yes, but what you delivered is not what I wanted
I.T: How can this be?
(both parties stare at each other in bafflement and puzzlement)

9 times out of 10, such conversations occur because of ambiguities or omissions in the requirements. Which brings us to the great underlying challenge of requirements; instead of being written in a language that is suitable for specifying software, requirements are (mostly) written in natural languages, which are highly suitable for conveying nuance and ambiguity...which makes them a poor natural fit for any communication process that requires as little ambiguity as possible. This blog posting neatly explains the underlying issue, using a well-known nursery rhyme as an example...