We have previously talked about Importance of Data Discovery in MDM Projects. Now we will delve into another key aspect of MDM projects – the role of stakeholders. Once again we have with us Peter Karlsson with vast knowledge about the subject.
How would you sum up this topic in a single sentence, Peter?
“Well, that would be the English “Engagement is key”. It is important in any project that it is anchored at the appropriate level, that you have engaged stakeholders, and that they understand the importance of what you are trying to do. If this is not the case, there is a very high risk that the project will fail. In a MDM project, engaged stakeholders are even more important because there are so many parts of the organization involved. You need to reach the right level within the organization.
What do you mean by “right” level, and how does one know what is “right”?
“It is above all about having stakeholders who can and are allowed to make decisions. Stakeholders who can delegate and prioritize for the individuals within the organization affected by the change. In addition to the stakeholders, there are designated participants with free resource time for the MDM project, but there are many individuals who can both influence and be affected by the changes that come out of the project. Therefore, access to the business is needed on an ongoing basis. Primarily to validate which fields and entities should be included. They are also needed to check the information collected, validate the data, find errors and problems, and evaluate whether it is in the source system that needs to be corrected.
Are there more than just stakeholders who are formally involved in the project?
“Yes, that's right, it is the stakeholders who have the mandate to prioritise the work of the other participants and that is precisely why it is important to bring them with them. However, detailed knowledge of each individual issue cannot be expected from the stakeholder group. This is when more participants become involved. We are talking here about 3 different types of project participants:
- Stakeholders: Decision-makers with the ability to prioritize and delegate
- Attendees: Designated resources with freed resource time for the project
- Contributors: Resources within the organization without freed up resource time, but who need to get involved in parts of the project if necessary.
Why was this one of the “lessons learned” you took from the project?
Because initially we didn't have access to the resources we needed. We had several cases where the people designated as stakeholders did not fully understand the impact the project would have on their part of the organization. There we felt that if we had been clearer from the beginning, for example explaining that “you will need x people in half time to correct the data in the source systems”, the project implementation would have been much smoother, but it is also difficult to see the need early enough.
When you entered into this project, the quality level of existing data was unknown to you, how did you go about making the right demands on which stakeholders were needed?
“Well, that's what came later, and was also the reason why we realized we didn't have the right stakeholders. It became like an awakening for them that they needed to assist with so much time and resources. We should have been clearer and earlier in explaining that at a certain point we will start work on Data Profiling and then we will discover many of the problems with the basic data. This, in turn, will require a lot of time from the participants. We had actually flagged for these parts, but perhaps didn't realise how much time was needed after all. The ambition was that we would be completely finished with the Data Profiling part by the date of the first POC, but the corrections in the source systems have really started only now, almost half a year later than planned.
Have you figured out why there was such a long delay?
“Yes, we realized that we actually had pretty much underestimated how low the quality of the data was in the source systems.
What was the reason for the incorrect estimate?
We looked at the business, it was successful. They manage to keep their orders in order, make the right purchases, get their invoices off and they sell well. One is then easily lulled into a belief that everything under the surface is then also in order. But once we started making demands on the data, it turned out that quite a lot was being corrected manually. Persistent and loyal employees who invented their own procedures and processes to correct things that would otherwise go wrong — things that internal systems are normally expected to solve.
How did you formulate yourself, what requirements did you set when it came time to select stakeholders?
“We started from which domains would be managed. Then the IT manager was the client and then a number of domain managers, and there were not really the right people for this project. They saw it mostly as a technical IT project that would not affect their organization very much. There was an image that MDM would help them migrate from an old to a new system. However, they did not understand that in this process it would also entail rectifying much of the incorrect data. Of course, a lot is corrected automatically using data quality rules and Data as a Service services, but there will always be some manual corrections.
“'Commitment is key' It is important in any project that it is anchored at the right level, that you have engaged stakeholders, and that they understand the importance of what you are trying to do. If this is not the case, there is a very high risk that the project will fail.”
– Peter Karlsson, Senior Solution Specialist
You later did a review of who would be the stakeholders, did you get IT staff again?
“No, then we managed better and got staff from the business. In connection with the start of the Data Profiling phase in earnest, we set up ongoing reconciliations with the group. There we went through the corrections made to the data since the last time, and got an indication of how much more accurate it has become. This then became the basis for the KPIs that are followed up at the steering group meetings, thus supporting the right deployment as well as increased resources if necessary.
After all, the participants of the organization also have their usual work. Do you have time to spend the time allotted for the project to move forward?
It's been mixed. It is largely an anchoring effort. We are talking to people who have such well-defined roles. They are order takers, for example, and have experience from their old systems that they know on their five fingers. They will now take on a new MDM system, look at the information, understand what to do with it, correct inaccuracies and how to keep track of how to re-report it. It has been a challenging journey and taken a lot of time, both from them and also from us.
So we're still talking about fixing the data and cleaning it?
– Yes exactly, and a lot still happens in the source system although we do a lot of fixes automatically much still remains. Data quality is so low in some areas that there is no point in trying to push it into the MDM system before it is established. And to correct this requires the commitment of the business.
So the conclusion is exactly as we started — “Engagement is key”?
– Exactly – “Commitment is key”!
