Want and ability

Background information on requirements analysis

Who really knows what they want before they have it? Who knows what they're capable of before they do it? Two old adages that also apply to modern development projects. How do we find out what the customer wants, and whether we can fulfill those wishes?

„We’re happy if we know the 50% requirements at the start of a project,“ a developer said in a confidential conversation. „The team that has to implement these specifications doesn’t actually know what the customer wants because the customer doesn’t know themselves. […] There’s no time to go through several rounds of discussions with the customer to resolve the gaps and contradictions in the specifications. […] So, based on our experience, we can only guess what the customer wants in order to deliver on time.“ A reader recently wrote this to me.

These quotes point to a very challenging task: How do we find out what the customer wants, and whether we can fulfill those wishes? This endeavor is made more difficult by the fact that, in high-tech projects, the customer often doesn't really know what they need – and we don't know exactly what we are capable of.

„Don’t fret over such weaknesses. Who really knows what they want before they have it? Who knows what they’re capable of before they do it?“ the philosopher would comment with a serene smile. The psychologist adds with a scientifically serious expression: “That’s no wonder, because needs, motives, and actions like to hide from consciousness.“ Therefore, it’s difficult to determine purely theoretically what we want or don’t want, or what we can or can’t do. It’s like hoping to figure out how a dish tastes based on a recipe. We need sensory experiences or, to put it more prosaically, practical experience.

We have to accept, whether we like it or not, that it's normal for customers not to know exactly what they want, and for us not to know exactly what we're capable of. Even if this unlikely scenario were to occur, it doesn't mean we understand what the customer wants, or that they grasp what they have in us. "That's just the way it is. Why get upset about it?" Diogenes calls out calmly from his barrel. If only it were that simple, dear Diogenes!

Because now the human psyche comes into play and makes things really complicated. Who likes to admit they don't know exactly what they want? Ignorance makes you vulnerable and jeopardizes the hierarchy between the customer, who likes to feel like king, and the supplier, who is preferably seen as a deferential servant. A little arrogance or feigned sovereignty seems "helpful." It keeps annoying questioners and doubters at bay. Knowledge is power, ignorance is weakness! Just don't jeopardize your status. For the same reason, the supplier, when in doubt, tends to pretend that they understand the requirements and can implement them.

It'll work out somehow. If the project contract is cleverly worded, there's even room for additional claims and overhead costs. This can turn one or two bitter pills swallowed during price negotiations into a goldmine. Anyone planning this, however, should have a very strong legal department on hand. As a technician, you're best off steered clear of this territory.

The tendency to skillfully mask weaknesses is fostered by the experience that in highly competitive societies, strong self-confidence and skillful self-presentation often lead to success. Those who are too modest and too honest often don't get a chance to demonstrate their abilities in practice. They aren't even invited to the audition.

The risks of this game of hide-and-seek are considerable, however. It leads to project planning based on hidden knowledge gaps, assumptions, and wishful thinking. The result: numerous hidden agendas surface during the course of the project. A great deal of energy is wasted clarifying misunderstandings and resolving conflicts instead of focusing on driving the project to success. Ultimately, this results in unnecessary costs, and the relationship between project partners is strained precisely during the phases where trusting collaboration is essential.

Therefore, it is worth considering how we can counteract the consequences just described.

Five suggestions for dealing with requirements: Request them now!

I welcome your suggestions at denkanstoss@microconsult.de.

Further information

Training & coaching
MicroConsult Training & Coaching on project management

MicroConsult training and coaching - overview

Food for thought:
Column by Peter Siwon about the human side of project work

Peter Siwon: Systemic project management