We have previously talked about the importance of the right stakeholders in MDM projects. Now we are focusing on another reality that affects all implementations – change. Together with Peter Karlsson we explore why changes occur, how they affect project progress and what it takes to manage them successfully.
Changes in a project are not unusual nor ar they in MDM projects. You too were subject to changes within the framework of your latest project Peter. Can you tell me more about it?
Yes, that's right. Change, is a fairly broad concept. We talk about changes in the requirements and scope, but also changes related to the conditions around the project. It can be about which participants you bring into the project team and how they need to be converted or replaced. Other types of changes are those that occur in the outside world or in other projects and domains that affect the own project.
– The customer organisation is initially provided with a first needs picture of what it intends to achieve and which is to be translated into requirements. But the longer the project goes on, more people become involved and interested in what we do in MDM project and what data we can supply. This has meant that more parts of the organization want to join the journey and take advantage of the quality-assured data that we can deliver.
That sounds more like the concept of “scope creep”. Is that what we are talking about here?
– Yes, in a way it is – on the basis that there will be more consumers of the data. But it is the same data that we deliver and from the MDM system side it does not matter much whether it is 1, 10 or 100 subscribing systems. From MDM's point of view, it's more about a queue with a predefined format that is independent of how many people read it. What would mostly fall under the term “Scope Creep” is rather extended discussions and explanations about what the data is and how it can be most efficiently consumed, and of course, more time and resources are spent doing this for 10 subscribers compared to 1.
How does the client feel about this?
It was accepted in full. After all, this is really only an advance for those who would have come along for the trip anyway, but were planned for lower down in time. The more people who connect to the MDM solution and use the data, the better it is for the business because it is faster to reach a consensus around data and entities.
– In parallel, we have an ongoing ERP project with links to our project that we are trying to manage in the best way. When we started, the ERP project had already been going on for half a year and there was already a formulated requirements picture for that project that we got to take part of. As they got deeper into their requirements picture, the requirements also changed for our project.
Were these changes anticipated and planned, or did they create new challenges for you?
– Yes, there were definitely new challenges, but you can't say, 'No, we don't agree, this was not an original requirement'. It wouldn't help anyone. After all, the new and changing requirements reflected reality and needs better than the original ones did. In addition, we work on the basis of agile methodologies, which gives the possibility that within 3 weeks we could control the direction towards the new requirements relatively painlessly.
Agile projects can handle any number of changes. How did you deal with that in this project?
– From the beginning, we planned and estimated the time to implement MDM for 3 domains. Amongst other things, we took steps for data modeling, setting up data quality rules, configuring the user interface for Data Stewards, etc. We also included a running record to be able to handle contingencies and changes. This gave us the “air” to deal with new demands to a certain level as they arose. And as mentioned earlier, the iterations ran for 3 weeks and therefore no more than 3 weeks in total were planned. Therefore, it was also easy to adjust for the changes.
That means you were estimating “air”, right? If it were to turn out that the allotted time for “air” would not be needed, would that not be risk that the project plan becomes misleading?
– Well, that's true, but experientially and in most modernization projects, many insights come to the surface only after the project has been running for a while. Each of them risks affecting the requirements picture. This is also why agile project methodologies are often chosen – precisely because of their effective tools for managing change.
How did you figure out what percentage of project time would be set aside for “air”?
– Well, that's about 20% of the entire project time actually. It is more or less a factor that we almost always use. We do this based on previous experience from similar projects.
– Having the post “air” included in the plan puts a lot of demands on follow-up. How was it handled?
– We have regular steering group meetings, at least once a month, sometimes even more often. This shows how much of the budget we have spent. If any change decisions are made that affect the budget in any way, we will lift it. Finally, we ensure that we receive acceptance of the extension or changes to the budget from the Steering Group.
But with increased budget, so is it well beyond the “air” planning? What kind of changes was it about then?
– Very true. It is important to have a clear delineation for what qualifies a change for the “air” part and does not. In this case, these were larger items that could more or less constitute a completely separate sub-project. For example, a question arose this summer whether to create its own central database for environmental data. This was not part of the MDM scope and could mean quite large departures from the plan. Therefore, we concluded that this first needed to be investigated more deeply, and it was that investigation for which we deserved extra time. Another example is the question of where to create a new customer, a new request that was added was that it should be handled in MDM. This too was outside the scoop and needed to be handled as an add-on.
“It's important to have clear and well-defined processes and tools for managing change – and we do!”
— Peter Karlsson, Senior Solution Specialist
Have the changes been so great that it has affected the timetable to a greater extent?
– Yes, it has. We had an initial plan to be ready before the summer, then information came from the ERP project that they will be ready with their parts only in the fall. And of course, our project also includes a complete integration with ERP. Therefore, we were simply forced to postpone the schedule.
In other words, have there never been changes in the requirements picture that caused adjustments to the project schedule?
– That's right. These have all been able to be handled within the framework of the “air” we have put into the project. It has usually been about things that have caused us to prioritise differently over a period of time, but never anything that has caused delays or revisions to the budget.
What has been the most difficult change you have encountered in the project?
– What caused it a lot for us were changes to the roadmap for the roll-out of different regions. There have been quite a lot of changes to which regions it should actually be rolled out first.
Why is it a big problem, surely it's the same MDM, the same kind of data being rolled out regardless of which region gets going first?
– True, but there are completely different people involved, in many cases from other countries and with different business cultures. Decisions that were completely clear, clear and implemented for e.g. The Nordic region may not gain acceptance at all in southern Europe. That, of course, sets it up for the plan. Things made based on a region must not be thrown away, after all, it should be used, but only later, in order to take a fresh look and create a roll-out based on a largely changed requirements picture. To solve such a situation, it is important to have clear and well-defined processes and tools for managing change – and we do!
