autotelic, autistic, assonance-hole©.

On managing “ever-changing” requirements

I caught this question over on Quora and answered it there; I’m placing that answer here because it is very likely the best overall view on the matter I have managed to set forth in my career.

If you’d like to read more about my thoughts on analysis in general, feel free to ask me via the “contact” here.

Q: What are some keys to successfully conquering ever-changing business requirements?

A: I would say the key to effectively managing “ever changing” requirements is understanding that they are not “ever changing”, they are “poorly defined”, “incompletely analyzed”, or “greatly (and incorrectly) assumed by one or more stakeholders”.

A quick analogy to demonstrate the point:

“I want you to make a sandwich”


“I want you to make me a tuna and Swiss sandwich on rye bread with one teaspoon of mayonnaise, 1/2 teaspoon of mustard, and 1/4 teaspoon of pepper mixed into the mayonnaise before it is spread upon the bread.”

If the requester wants the sandwich defined in the second example, how likely to receive that result will they be if the requirement that is accepted, approved, and pushed forth is the first example?

The challenge for most projects is that business and technology operate from different perspectives and with great variance in perspective and language; the role of the analyst is (among the finer points of methods or tools used in the practice) to translate between the two groups as well as to (a) recognize, (b) address, and (c) validate the thoroughness of requirements prior to them entering the production work stream.

The trouble is, very few companies (or people for that matter) seem to truly accept or acknowledge the severe impact that vague or incomplete requirements have upon project success (despite the reams of reports that clearly indicate it).

Agile pushes iterative development and eschews solid understanding of requirements, relying upon iterations to “suss things out”. Agile works great when dealing with easily compartmentalized functionality, but fails quickly and readily for most other types of projects.

Waterfall pushes sequential development and eschews permitting work until everyone has approved the requirements, relying upon the (often faulty) assumption that everyone (a) reads it all, (b) understands it all, and (c) will speak up if/when (a) or (b) are untrue. Waterfall works great when everyone is operating from the same foundation of knowledge, focus, and investment in the project, but fails quickly and readily when this is not the case.

But the question is not “which of the above two are more effective” (and this is something that frequently sidetracks this discussion in particular). Nor is it “which tools have the magical fairy dust to make this work”. The question(s) are:

(1) Why, after nearly 30 years of evidence, are companies (and people!) still denying that thoroughness in requirement analysis is THE fundamental key to project success?

(2) Why, after so many reports and books and case studies and conferences clearly evidencing that the cost of correction rises exponentially when defects and requirement vagueness or incompleteness are not caught/addressed in the requirements analysis effort, do companies (and people!) insist upon the (literally) delusional belief that is it possible to consistently find project success without well-defined, thoroughly analyzed, and validated requirements?

(3) Why is requirements analysis and planning still among the trio of “red-headed step-children” that are the first to be ignored, the fastest to see time/funding stricken, and most likely to be glossed over? (Aside – the other two members of this poor trio are “testing” and “documentation”.)

(4) Why do companies (and people!) insist upon setting budgets, timelines, and resource commitments for “I want you to make a sandwich” when even rudimentary logic clearly demonstrates that cost, time, and resource requirements are far more likely to exceed order of magnitude than not?

“Ever-changing” requirements are THE classic evidence of either a misunderstanding or a lack of commitment/investment to ensuring foundational, requisite information that any project needs to succeed as expected, within budget, timeline, and resource commitments.

The solution is not “finding a way to manage how they are ever-changing” but finding the way to help companies and people understand that the issue isn’t “ever-changing requirements” at all, it’s failure to develop and validate them as necessary to ensure they do not change.

Points of clarity:

(1) A change in market or business need is not a failure of requirements; it is a shift in one or the other that invalidates the requirement set and either resets the project or returns it to feasibility and scope validation.

(2) A change in management’s preferred outcomes or interests is not a failure of requirements; it is a shift in executive or stakeholder vision and direction that invalidates the requirement set and either resets the project or removes it from the calendar until it can be updated/realigned/redirected.

Treating the above two instances as if they are or should be absorb-able by ANY project is essentially evidence of overall process and project management immaturity; an issue much bigger and troublesome than any requirements method or tool can hope to resolve.

The key to successfully conquering “ever-changing” requirements is to have stakeholders and executives willing to accept, admit, acknowledge, and act in accord with the reality that there is no such thing.