Beware of Definition Creep

Nele Schouteden, IMEC

Many project managers will be able to testify about the scope creep that happens once in a while. Business stakeholders who requested scope “A” in a given project, will start asking for scope “B” at a given point. This bears no wonder, as someone who can see the finish line coming up close, is probably able to see what lies ahead.

Now, let me introduce to you the concept of “definition creep”. For example, nearly everyone part of the organisation knew what a “customer” was in the first few years that the business started out, because, highly likely not many people were part of this organisation and constant alignment happened in the coffee corner. As organisations grew larger and larger, many more people started to use the word “customer”, albeit with less strict application. As the sales department grew, “potential customer” turned into its shorthand “customer”, while Finance used it to denote paying customers. In the meantime, some of the new salespeople did not come into contact with some of the new finance people since multiple coffee corners arose. Some of the new people had previous experience at another employer where terms were used for different concepts.

After several years, the result of this “definition creep” is that you have multiple definitions (concepts) for the same word. Enter confusion when people started bumping into each other, usually propelled through cross-organisational data projects which nowadays, are sprouting everywhere at once. To end the inefficiency of this Babel situation, organisations are inclined to press down “obliged definitions”, usually centrally contrived by very enthusiastic governance profiles. However, this forced language will lead to losing valuable concepts (the meaning behind the words) – they are valuable because business uses these concepts to operate day-to-day.

Therefore, I would advise, instead of forcing language, to use the following approach:

1) collect all concepts (definitions), even though the concepts are linked to the same term;  2) then specify the terminology for which multiple definitions exist;

3) and make a higher abstraction of that ambiguous term.

For example, if you end up having 5 definitions for “project” and they can’t be reconciled, meaning they all have a specification that can’t be brought under one umbrella, give the project terms a prefix (or suffix) to specify what makes this project concept so unique:

• Project 1: Has a fixed end date – Deadline project
• Project 2: Has a budget over 500K – Big Budget project
• Project 3: Involves at least human resources of 2 departments – Cross project
• Project 4: Involves an external partner – Partner project
• Project 5: Here my inspiration ends for now. But you get the point.

Then make sure that the definition of the term “project” addresses the ambiguousness: “A project is the collective term for temporary endeavours with a specific scope and budget involving multiple stakeholders.” As an FYI: these definitions are a great way to double check the current existing data models.

Instead of deciding top-down what a given word should mean, allow for the collection of all business concepts that are in use, and which might use the same terminology. Like this, the tower of Babel can be recycled safely without losing business value.