Coevolving Innovations

Coevolving Innovations

… in Business Organizations and Information Technologies

‘Requirements Gathering’ does more harm than good

January 30, 2006
8 Comments

I believe that we can do a much better job of doing two things. Firstly linking business goals to the projects and programmes that deliver them. Secondly, co-ordinating business change in delivery projects and programmes with IT change. Systematic treatment of these two things together capture the essence of what I think of as ‘Business Architecture’

In order to explore these two topics, and to make it more fun, I’m going to suggest that requirements gathering does more harm than good. I have some clear views about why I think it does, some of which differ from current widely held views. I also have some ideas about how we can do better.

I’m hoping that you will join in by providing your views about whether you think it does more harm than good, if so why, and what you think we can do about it.

8 Comments

  • daviding

    Well, now you’ve tweaked one of my sensitive spots!

    In my practice of consulting on information systems, I’ve more-or-less expunged the idea of “requirement” from my vocabulary. My averseness is so extreme that I completed a consulting engagement last year — initially framed as a “needs assessment” — so that I wrote a text document of 75 pages without using the word “requirement” in it.

    Business mostly follows “commercial syndrome”. In Jane Jacob’s descriptions in “Systems of Survival”, churches are archetypes of guardian syndrome, where there are “rights” and “wrongs”. Business is much more about “commercial syndrome”, where everything is negotiable.

    The problem that I see with most projects is that “requirements” is seen by the analyst as a checklist. The consultant/analyst creates a long list of wants and needs, and then works with a client team to “prioritize” requirements. When funding is tight, the feature list becomes “lowest common denominator”. When funding is more forthcoming, there’s potential for bloat and over-engineering.

    This problem is somewhat exacerbated by the trend towards selection and configuration of software packages. The expensive option of Brand X may include Feature A and Feature B, but the cheaper option of Brand Y has Feature A as an option, and would require some customization work for Feature B. Does “requirements gathering” lead to overspending on software selection?

    One metaphor that I’ve used successfully is buying a car. No one gets to choose about having a catalytic converter — it’s necessary by compliance; and practically every car now has power brakes as a standard feature. For the option of a sunroof, however, I’ve rarely met a person who doesn’t want one. The question is really how much a sunroof costs. If the dealer really wants a car off his lot, and offers a sunroof for $20, almost anyone would take it. If the sunroof were $5000, though, hardly anyone would want one.

    In saying the “requirements” should be negotiable, one approach to establishing “best practice” in organizations is to introduce architectural standards. While this may preclude clients from “doing damage to themselves”, architecture becomes a two-edged sword. Architecture can become “guardian”, with pass-fail criteria, and becomes just as bad as requirements engineering.

    Jane Jacob’s prescription is that either governance syndrome or commercial syndrome work, as independent systems. When the two are crossed, corruption ensues.

  • Scott Sehlhorst

    Martin – great question. I couldn’t find an email contact on your site, so I’ll leave this as a comment.

    We started a poll asking this same question back on the 26th. The article Take this poll or we’ll shoot this kitten also includes links to a debate in a comment thread on an earlier post that raised exactly this issue. I hope you’ll take a look, and consider sending your readers to participate in the poll.

    Scott

  • dougmcdavid

    I already know some of the reasons you make this point, Martin, so I won’t steal your thunder as you unveil the full brilliance of your thinking!

    I just wanted to mention that my perspective has been changing lately in a way that supports what your basic point. For various reasons I have been examinging the whole notion of services, and now have a perspective that we are leaving huge value and wealth creating opportunities on the table by not recognizing that people, and the relationships among people, constitute the true source of value in service industries and service economies.

    So, with that background, I would say we should stop focusing so much on “requirements,” and start focusing on “desires.”

  • Pingback: coevolving.com » Blog Archive » ‘Gathering’ is so passive

  • martingladwell

    I don’t know about ‘brilliance’ but I’ll be developing the argument over the coming weeks!I will certainly be addressing many of the points David makes. The notion of requirements in the context of the ubiquitous ‘package’ and hoping to draw Doug and others out on what requirements of the future or some complete repalcement of ‘requirements’ would make creating (not gathering) them worth doing. Scott I’ve pointed my Business Analysis community at your page, if you don’t get a few hits I’ll have a selection of them shot for you.

  • Mike Wittenstein

    Gathering requirements (the way its generally practiced) limits most participants to think about what can be done given current constraints, avoiding the deeper and more valuable/insightful thinking aroudn developing an overarching better approach or solution.

    By first creating focus and alignment on desired outcomes, then on using design (as a problem solving tool) to overcome unnecessary constraints, we can get beyond “making a better way to do an old thing” to “making a way to do things better” which is what everyone is usually after anyway.

  • dougmcdavid

    Nice to see you, Mike!

  • Sheila Thorne

    The Holy Grail of Requirements Gather – Don’t Gather Requirements

    Oh gee my worst fears – someone going in and asking the users to come up with a list of requirements. That’s like to asking a two year old to plan dinner menus for the month. It is far better to go in and ask “what is the biggest pain in the ass (pita) you face today?” This would seem to have nothing to do with so called requirements. Yet it enables you to grasp a business issue that needs to be solved while not asking the person with the problem to fix it. Which they can’t really do, otherwise your presence would not be required.

    So, for my example, an automotive customer wanted to consolidate websites of several divisions to control cost. At the beginning of our work session I asked each automotive group what the biggest pita was. For each one – it was creating, printing and distribution the benefits guide. Note – this has nothing to do with a website. Each group was doing their own guide – 5 guides with the same material. Within 5 minutes the group realized they could consolidate the benefits guide put it on-line. Hardcopy would be sent by request. In less than 5 minutes, there was the major cost savings and time savings while leveraging the web. However, this was not done with the typical let’s do an “as is” and “to be”.

    Here is my number one example in a series of many. What about the rest of you; any similar experiences?

Leave a Reply

Your email address will not be published. Required fields are marked *

« Older «
» Newer »

  • RSS qoto.org/@daviding (Mastodon)

    • daviding: “Instead of #SustainableDevelopmentGoals, #KaitlinKish #Steph…” March 12, 2023
      Instead of #SustainableDevelopmentGoals, #KaitlinKish #StephenQulley say #EcologicalLivelihoodGoals. "informal processes of exchange, familial care, place-bound community, mutual aid, and reciprocation –​which we designate as _Livelihood_"Open access book for March 13 https://wiki.st-on.org/2023-03-13 #SystemsThinking #EcologicalEconomics
    • daviding: “From the debate between Michael Quinn Patton and Michael C. …” March 10, 2023
      From the debate between Michael Quinn Patton and Michael C. Jackson OBE on "Systems Concepts in Evaluation" on 2023-02-27, I've digested into text the few minutes with the largest contention. https://ingbrief.wordpress.com/2023/03/10/concerns-with-the-way-systems-thinking-is-used-in-evaluation-michael-c-jackson-obe-2023-02-27/ #SystemsThinking #evaluation
    • daviding: “Peer-reviewed article on #SystemsChanges Learning 2019-2022 …” March 9, 2023
      Peer-reviewed article on #SystemsChanges Learning 2019-2022 published in special issue of J. #Systemics #Cybernetics & #Informatics, on "#Sustainable, Smart and #SystemicDesign #PostAnthropocene" edited by #MarieDavidova #SusuNousala #ThomasJMarlowe https://coevolving.com/blogs/index.php/archive/systems-changes-learning-recasting-reifying-jsci/ #SystemsThinking
    • daviding: “Truthiness was coined by Stephen Colbert in 2005, and became…” March 7, 2023
      Truthiness was coined by Stephen Colbert in 2005, and became legitimated as an entry in a dictionary by 2010. > ... _truth_ just wasn’t “dumb enough.” “I wanted a silly word that would feel wrong in your mouth,” he said. > What he was driving at wasn’t _truth_ anyway, but a mere approximation of it […]
    • daviding: “Generative AI, such as ChatGPT, may be better viewed as putt…” March 7, 2023
      Generative AI, such as ChatGPT, may be better viewed as putting together hypotheses, where testing either leads to corroboration or truthiness. > The glitch seems to be a linear consequence of the fact that so-called Large-Language Models are about predicting what _sounds right_, based on its huge data sets. As a commenter put it in […]

  • RSS on IngBrief

  • Powered by FeedBurner

     Feedburner

  • Recent Posts

  • Archives

  • RSS on daviding.com

  • RSS on Media Queue

  • Meta

    • Creative Commons License
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
    Theme modified from DevDmBootstrap4 by Danny Machal