Main idea

On paper, two customers of the same business software can formulate an identical request. What they expect behind it is not identical, because what decides the expectation is not the need as stated but the way the organization decides: its relationship to risk, its degree of centralization, the relationship between head office and sites, the level of standardization it imposes on itself.

A group where head office sets the reference data expects the same feature to standardize; a company that lets its sites organize themselves expects the same feature to adapt to each one. Neither says so, because for each of them it is obvious.

A team that has not identified this dimension can deliver something correct and nonetheless beside the point: the feature does what was asked for, and does not do what was expected.

Why it matters

This forbids treating a need expressed by several customers as a consolidated request. Adding up identical formulations coming from opposite decision cultures manufactures an average specification, which satisfies none of the expectations it covers.

It also indicates what to look for in customer interviews beyond the need: how arbitrations are made, who decides, what the organization expects of a standard. Those questions are not questions of comfort — they determine the shape of the answer to be built.

Nuances and limits

An organization's culture is not homogeneous: management, sites and support functions can carry contradictory expectations beneath the same request.

And not every gap in expectations is cultural: a regulatory constraint or a technical legacy produces the same divergences without any culture being involved.

Open questions

• How do you detect a cultural divergence in expectations before delivery, when it is expressed in no formulation of the need?