A recurring disagreement keeps surfacing inside project management circles: when a practitioner says a dataset has been "normalised," what do they actually mean? The argument holds that "standardisation" is often the more honest word for what teams do when they reshape project data into a common format.
For project managers who own the reporting layer, the distinction is not academic. The word on the slide changes how stakeholders trust the numbers underneath it.
What happened
- The reference defines data normalisation in the database sense: removing redundancy and grouping related data so storage is efficient and structure is logical.
- It argues that the term "data standardisation" is a better fit when practitioners are reshaping data into a common scheme for analysis.
- The post links normalisation to two companion concepts: data rationalisation and data contextualisation.
- Data rationalisation is described as the ability to locate, link, and reuse enterprise data assets across model layers.
- Contextualisation is described as identifying the data relevant to an entity based on its surrounding context, filtering out the rest.
Background: how teams got here
Database theory has used the word "normalisation" since the 1970s. In that original sense, it means reshaping tables so each fact lives in one place and related facts sit together. The benefit is consistency and lean storage, not analysis-ready output.
Somewhere along the way, the word drifted. Analytics teams started using "normalised" for rescaling numbers into a standard range, a technique borrowed from statistics. Other teams used "normalised" to mean cleaning and standardising values from different source systems into a single shape. The reference is reacting to that last usage and arguing we should call it what it is: data standardisation.
For project managers, this matters because the data flowing into a status report rarely comes from one clean source. Timesheets sit in one system, costs in another, scope changes in a third. Something has to reconcile them.
Our analysis
Two reasonable people can use the same word and mean different things. That is the entire problem. The reference is correct that calling a cleaning-and-shaping exercise "normalisation" borrows confusion from a different field. Standardisation is the more honest label when the goal is a common format across sources.
There is a trade-off, though. Standardisation is a bland word. It does not signal rigour. If your audience already understands normalisation in the database sense, swapping the term costs you nothing and gains precision. If your audience is non-technical, "normalisation" sounds more impressive than it is, and "standardisation" might land as plain English, which is usually what you want in a steering committee.
The other lesson is that none of this is a statistical technique, as the reference notes. When PMs talk about normalising project data, they are almost never talking about z-scores or min-max scaling. They are talking about deciding on one definition of "active project," "billable hour," or "scope change" and enforcing it across feeds. That is a governance problem dressed as a data problem.
Who should care
| Role | Why it matters |
|---|---|
| Project/Programme Managers | You own the reporting narrative. Using the wrong term misleads stakeholders about what work actually happened. |
| Data Analysts / PMO Staff | You reconcile feeds from multiple systems. Getting terminology right prevents downstream confusion when models are built. |
| Enterprise Architects / Data Teams | You implement the governance layer. A shared glossary prevents the same word meaning two things in the same meeting. |
| Senior Leadership / Steering Committees | You act on dashboards. If the underlying terminology is muddled, confidence in reported numbers erodes quietly. |
A worked example
Say you run a portfolio of twelve projects and you want one consolidated status report. The finance system reports cost in the local currency of the legal entity. The project tool reports effort in hours. The CRM reports customer satisfaction on a 1-10 scale, but two business units use opposite conventions: for one, 10 is great; for the other, 10 is terrible. Before any chart makes sense, you have to standardise: convert all cost to a single currency, lock the hours definition, and flip one of the satisfaction scales. That is standardisation, not normalisation. Once the data is standardised, you can add context: filter out inactive projects, group by programme, and surface the views the steering committee actually needs. Call it that on the slide and nobody in the room will be misled about what just happened.
What to watch next
If you are tightening up how your team handles project data, watch the words first. Agree on a one-page glossary for terms like normalisation, standardisation, rationalisation, and contextualisation, and pin it to your reporting standard. Then watch the data flows: every new source system should pass through the same standardisation layer. If the glossary holds and the layer holds, the dashboards will hold. If either drifts, the dashboards will lie politely and confidently, which is the worst kind of lie.
Key takeaways
- "Normalisation" in database theory and "standardisation" of analytics data are different jobs; pick the word that matches the work.
- Most "data normalisation" inside PMOs is a governance exercise, not a statistical one.
- A shared glossary pinned to your reporting standard prevents the same word from meaning two things in the same meeting.
- The three related concepts—normalisation, rationalisation, and contextualisation—form a progression from storage efficiency to enterprise-wide data discovery to context-aware filtering.
Frequently asked questions
What is data normalisation in the database sense?
It is reorganising data in a database so there is no redundancy and related data is stored together, also called data normalisation. This minimises disk space and increases performance.
Why does the reference prefer "data standardisation"?
The post argues that when practitioners reshape data into a common scheme for analysis, "standardisation" is a more accurate label than "normalisation," which is a separate concept rooted in database design.
What is data rationalisation?
It is the ability to find, use, manage, and reuse enterprise data assets and their underlying models, linking model objects to expose higher-order conceptual objects across the organisation.
What is data contextualisation?
It is identifying data relevant to an entity based on its surrounding context, filtering out irrelevant data and reducing volume for more focused analysis.
Does data normalisation involve statistical methods in project management?
The reference explicitly states that none of these terms involve statistical methods in the field of data and computer science. When PMs talk about normalising project data, they are almost never talking about statistical rescaling.