This morning @MrAlanCooper was on a roll with an anti-requirements theme of tweets. I replied that almost a decade ago I had given a conference presentation “Requirements Don’t Work”, which included many references from his books. Recognizing that I randomly perpetuate this conversation all over the place, I’ve gathered parts of it here, starting with one from today:

Requirements are a response to a design — they’re not the procuring cause of a design.

Let’s look at this realistically. If the current methods, which include requirements, worked then why is there a 68% failure rate in IT projects? Michael Krigsman (@mkrigsman) postulated:

The solution lies in recognizing that requirements definition is critical.

Been there. Thought that too. But it’s been debunked (sadly, pre-internet, reference to the study is gone). I replied to Michael’s post:

Back in 1990 or so I found a one-page ‘editorial’ that reshaped my career focus. It effectively reported a study to ‘debunk’ the “we didn’t get the requirements right” theory.

So they audited the process. Were all the requirements captured as intended? Check. Were all the requirements met by the solution? Check. Result: Fail!

And this is where my life changed…they brought anthropologists into the environment in which the system was being used — an emergency room. They added more requirements based on their observations…the system was a success.

Now let’s talk about having the wrong skills…

Attempts to share this same story with a group of Business Analysts, was met with opposition. There I commented:

In reality, requirements (especially the way in which they’re gathered and managed in most cases) serve only one purpose — facilitating testing. They are typically useless for ensuring the success of a solution….

Another valuable analogy to consider is the model employed by commercial building. In that model, assume that Requirements and ensuing Development are not part of the activities of the General Contractor, but are one of the responding trades. That means that a larger architectural/design effort has gone on prior to the ‘response’. In that prior effort, blueprints are already drawn up and specifications (not requirements) have been delivered. The ‘requirements’ are the responses by the individual trades as to how they plan to fulfill the specifications.

The fact that we have a huge phase missing in the discipline of the SDLC and that it starts with some ‘poof’ ["...and then a miracle happens"] of requirements has been a fallacy for decades.

The author of this blog post was unnerved by the dissonance that ensued in the path to common understanding (a deplorable practice often seen in requirements gathering sessions) and closed the comments. Shutting down the conversation is a symptom of the problem: behaviors indicative of and reinforced in cultures of command and control — the antithesis of a 2.0 era. Design inherently insists on embracing creative dissonance.

Clearly there are those who understand the difference — Alan Cooper’s comments today were retweeted by many. Some have traveled similar paths of discovery, such as @suredoc’s (Keith Anderson) “Prototyping Insights From a Guy Who Writes Requirements“, where he also takes direct aim at the classic Systems Development Lifecycle (SDLC).

The SDLC mindset is based on the fact requirements drive everything. By “requirements” I mean a document of some sort that can either be well-written or, as I’ve seen of late, an Excel spreadsheet wishlist.

I remember a custom 9 volume SDLC manual set. I was fascinated by the ‘whole’ of it all. Imagine, 9 volumes of detail as to how the floor of hundreds of developers were to do their jobs (manuals for which I was the most frequent user…to insert page corrections — the cost of which I shudder to consider). In ALL of those hundreds of pages there was a reference to “start with the requirements” and not a stitch of information on what they were or how you got them — in the SDLC, requirements just somehow magically appear.

To better inform myself, I sought out leaders in the requirements process and attended training. Aside from helping us look for ‘nouns’ (clearly a data-focused paradigm), the instructor attempted to give us tracking and auditing skills — again, circling back to the feloneous assumption that requirements are somehow ‘lost’ and that’s the cause of failure. There was nothing discussed about eliciting requirements or the issues to do so — including the also infamous lament from developers “but they keep changing their minds” — as if the changing landscape of business wasn’t a design reality that needed to be embraced.

Similar to my inspiration from the commercial building industry, in “The Obsolete Idea of Requirements” @smalltalk80 (Niklas Björnerstedt) was inspired by the advertising agency model:

In advertising, a customer typically does not write a contract for a single project. The contract is instead the foundation of an extended relation. The advertiser works with the customer, looking at what the customer does and what the customer wants to achieve in the future.  The advertiser then formulates ideas that are elaborated on together with the customer. Some of these ideas result in “projects”, others are more open ended. Over time the customer uses a number of (imperfect) measures to assess how well the advertiser is helping it achieve its goals. Most of the goals a customer cares about are not related to a particular project, they are formulated in terms of the business itself.

Three things to add to great observations. First, Niklas is seeing the influences of design practices in the customer relationship. Second, advertising has a significant difference: creating need where none exists. Third, where he notes “They would describe what they were doing today and what their goals were for the future.” — this will lead to incremental improvements and often radically incremental improvements, but rarely innovative results (often also part of the “requirements”). But innovation isn’t always or even mostly desirable. There are many ’starving workers in the business landscape’ who would trade their paychecks for ‘good enough’. Many truly innovative solutions can be found in the amazing work-arounds that employees have created on their own, just to get their work done in spite of the euphemistic machine they’re forced to operate in.

The realm of Enterprise 2.0 insists on a more open, interative, collaborative and continuous means of making stuff happen than the methods of classic requirements can afford. In design, requirements are the collection of constraints that must be honored, or thoughtfully traversed. Requirements do not specify the results. But as my first quote embraced the classic definition of requirements — the things used to test results against — if everyone still needs to call those “requirements”, let it so remain.

Footnote: In re-reading a prior piece I’d written on Pixar, I was reminded of earlier ranting I’d done on requirements.