Coevolving Innovations

… in Business Organizations and Information Technologies

‘Requirements Gathering’ does more harm than good

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

  • 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.

  • 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

  • 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.”

  • 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.

  • 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.

  • Nice to see you, Mike!

  • 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 *

  • RSS qoto.org/@daviding (Mastodon)

    • New status by daviding October 9, 2019
      Declarations of sapiosexuality may describe individuals seeking partners for intellectual intercourse.> A self-described “sapiosexual," someone who is primarily attracted to intelligence over physical appearance, Van Dusen says she now screens her dates for post-secondary education. [.....]> Many sapiosexuals acknowledge the term can come off elitist, but in the often superficial world of online dating, they […]
    • New status by daviding August 19, 2019
      In the Canadian press, this is attributed to inverted yield curve, resulting from the trade war. > Anyone buying that bond is willingly buying an investment that's guaranteed to lose money, but investors are more than happy to buy it up - because the fear is that alternative investments will fare even worse. [....]> Those […]
    • New status by daviding August 19, 2019
      There's something seriously wrong in the global financial markets, when banks are offering mortgages at zero or negative rates. > Jyske Bank, Denmark's third largest, has begun offering borrowers a 10-year deal at -0.5%, while another Danish bank, Nordea, says it will begin offering 20-year fixed-rate deals at 0% and a 30-year mortgage at 0.5%.> […]
    • New status by daviding August 18, 2019
      Web video of Systems Changes: Learning from the Christopher Alexander Legacy, extending #patternlanguage especially Eishin School and Multi-Service Centers methods-in-practice. For #SystemsThinking Ontario, up the learning curve on ongoing research. http://coevolving.com/blogs/index.php/archive/systems-changes-learning-from-the-christopher-alexander-legacy-st-on-2019-02-11/
    • New status by daviding August 16, 2019
      Web video of presentation of Evolving Pattern language towards an Affordance Language, 2018, on week visiting#RaphaelArar and #JimSpohrer at Almaden. Insider's history of science and prospects http://coevolving.com/blogs/index.php/archive/evolving-pattern-language-towards-an-affordance-language-almaden-2018-05-09/#systemsthinking #patternlanguage
  • RSS on IngBrief

  • Recent Posts

  • Archives

  • RSS on daviding.com

    • 2019/10 Moments October 2019
      Tightly scheduled weekdays at Ryerson Chang School, weekends in Gravenhurst clearing out family building as we're leaving the town permanently.
    • 2019/09 Moments September 2019
      Full month, winding down family business in Gravenhurst, starting Ryerson Chang certificate program in Big Data, with scheduled dinners with family and friends.
    • 2019/08 Moments August 2018
      Enjoyed summer with events in Toronto, followed by trips back my home town Gravenhurst, staying overnight for the first time in over 30 years.
    • 2019/07 Moments July 2019
      Busy month of living every day of the summer to the fullest, visiting family and friends, enjoying the local sights of the city.
    • 2019/06 Moments June 2019
      Summer arrived in Toronto, with the month ending in travel to BC and Oregon.
    • 2019/05 Moments May 2019
      Family time, empty nest, short trip to conference nearby, friends at home.
  • 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