Reaching a binding decision

Thrashing: tweaking, updating, revising, sometimes even major surgery; essential, but when to do it? Amateur: all at the end. Pro: early.
Seth Godin
in his book, “Linchpin.”

One of the biggest challenges facing a new OSS project is gaining a workable and binding set of requirements on which to build a solution.

There are all sorts of challenges in achieving this, including:

  • Identifying all of the impacted stakeholder groups
  • Getting up-front input from those groups
  • Achieving consensus across all of those groups (eg which requirements are important, how the functionality should appear or not, what are the highest priorities, who will contribute resources, etc)
  • Lock-down of a binding set of requirements

Seth Godin recommends an approach that he refers to thrashing, which I discussed in this earlier article. He dictates a period of input (thrashing) during the early stages of a project and then filtering out any subsequent changes once the project is in-flight.

I like the concept of this model, but it can be quite challenging in the context of an OSS project where there are so many individuals that may need a say into the requirement gathering process. If hundreds of people want a say during an open forum, the thrashing meetings can get out of control.

Whilst doing some alternate research, I stumbled across a concept that could be useful in controlling this thrashing approach (to some extent). My interpretation of the concept goes something like the following:

  1. The various groups have the opportunity to submit a list of requirements / user-stories to a drop-box
  2. The requirements are gathered into a list that is then distributed to all stakeholders prior to the trashing meetings
  3. A moderator poses each requirement/story and each stakeholder has the opportunity to raise cards to indicate their acceptance
    1. Green card = accept
    2. Red card = don’t accept
    3. Orange card = needs more info or would like to contribute to a tweak to the requirement/story)
    4. No card displayed = not applicable to this stakeholder
  4. A large proportion (eg 90%) of red or green cards gets the requirement accepted or canned, whilst targetted follow-up sessions are scheduled for requirements that have a significantly orange response or a  balanced mix of red and green
  5. The moderator may also be tasked with generating fire-starter questions that are aimed at shaking up the status quo or seeking to create a perspective of innovation, especially on topics that have proved to be difficult to gain consensus on historically. Questions are to be posed so that they can also be answered with red/orange/green cards

The main advantage of this approach is it gives a large audience an opportunity to voice their sentiments, without getting bogged down in large amounts of dialogue (which requirement gathering sessions often do!!)

I haven’t had a chance to trial the concept yet, so I would love to hear from anyone that wishes to try it. I’d also love to hear your perspective on whether this would work in thrashing sessions at your organisation.

 

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.