Requirements Are Dead, Long Live the Solution

Requirements gathering is one phrase I have learned not to use with stakeholders as I deliver projects.

It appears to have struck fear, cynicism and/or anxiety in many of the user groups I have to engage at the most important stage of the solution – the beginning.

Related Article: Your Job is Not to Elicit and Document Requirements

Many user groups have pre-conceived ideas about what this exercise really is, ranging from
‘Oh great, we get to tell them what we want for the new, super-duper system’ or
‘Just great, we give you all our knowledge about the processes and you go away to work out that’s too expensive and we can only have half of what we need.’

The secret is in the last few words of the previous sentence ‘… what we need.”

The focus must be directed towards the needs of the business so that the benefit of a solution can be seen to be realizable. By using the right words like need, a different reaction is seen. Scope is already being defined; the user groups become SMEs, and a level of respect is gained with a focus on the business value even before the workshop has started.

Elicitation and other animals

The industry then moved on with the terminology, to use the term “elicitation.” To add complexity, there were separate definitions of functional requirements, being different to business requirements, then getting technical and coming up with system requirements.

All of the types of requirements have clouded the understanding by stakeholders, and then time is lost in the defining the terminology before any discussions have begun. A plethora of white papers and authored articles can describe the differences and it’s absolutely clear in some of those esoteric minds.

Stephen Covey’s #2 Habit – Start With the End in Mind

From the book “Seven Habits of Highly Effective People,” this second habit is a fairly simple approach to delivering solutions. Knowing the direction and end-game keeps you focused as you go. It also facilitates a more direct approach to delivering without the time-consuming documentation of a build-up of phases that doesn’t always deliver tangibility or measurable benefits.

This skipping of phases with little value-add has now been conceptualized by the consulting industry into ‘Design Thinking’ whereby initial engagements with user groups will have the design of the solution at the forefront, ensuring that it will always meet the business needs.

Cheese’s of Gatherers

Some time ago, the DSDM (Dynamic Systems Development Method) consortium developed the methodology known as the cheese and three pizzas, whereby the cheese represented the business study under a feasibility study. Quite simply, for appropriate projects, conduct a study to make sure of the feasibility, then develop it to make sure it fits the needs of the business opportunity or problem.

A business fitted, feasibility that demonstrates meeting the needs, to those with access to purse strings appears a far greater representation of commitment to deliver a solution.

Today’s project needs are for solutions measured in time-to-market, risk reduction, take-up rates, or better still, what you defined as measurable at the beginning.

Do projects exist anymore that require full blown requirements gathering exercise, if they still do would you call it that?