This is the continuation of the transcript of a Webinar hosted by InetSoft on the topic of "Data Management Implementation." The speaker is Mark Flaherty, CMO at InetSoft.
Flaherty: There are several stages of the information management implementation process. Most consulting firms and vendors prescribe this kind of methodology. They might call it something different, but for the most part, the five bases are A, project planning, B, application exploration, C, system design, D, system testing and E system activation.
I’ll just talk a little bit about each one. In the project planning, it’s exactly what it sounds like. You are putting together a form of plan. You are picking dates. You are assigning resources, and you are making sure that everything makes sense.
Afterwards, you send the people to training, and they come back, and they actually start playing around with the application under the supervision of consultants. They figure out what makes sense for them, get their hands dirty, start to process transactions, or have employees run payroll and add journal entries. They are really trying to figure out the best way to use the application.
Next up is system design. First you kick the tires a bit, and then you want to set up that system and build the future configuration after it’s designed. Next, you want to make sure that you are testing the system. For the most part, you are trying to emulate real life scenarios and see if you can pay vendors and/or employees or set up security classes for people so that they can get into the system and see only what they are supposed to see.
Flaherty: Finally, after the system has been tested, you are supposed to activate the system to make it go live. If everything has been done properly then the transition should be smooth. Very rarely though is this process linear, and it’s not uncommon for people to go back to the project planning phase and reevaluate because of some unforeseen delay.
It really does all start with project planning, but sometimes it is very difficult to foresee every conceivable kind of scenario. If the project was properly implemented, in other words, the client definitively made out their business requirements, then hopefully, the project was priced in such a way that the goals are attainable without going over budget and passing the deadline.
Some of those compromises don’t have to be made, but that’s the basic framework. Of course the terms may differ from vendor to vendor and from consulting firm to consulting firm, but for the most part it’s pretty standard. I mean, it’s tough to test the system that you haven’t designed first.
Flaherty: Obviously different people need to be involved with different levels at different times. There is something called a group responsibility matrix. It’s important to think about the people who may have roles in the implementation process such as the senior management team, the project manager, if there is one, the internal team for testing, implementation team, and the external consultants.
They play different roles at different times in terms of project planning. You definitely want buy in from the senior management from the beginning because you are going to be committing their dollars, and there are people out there who at significant periods of time are working on something else other than their day jobs.
Now when it comes to system activation, for the most part, the senior managers are kept in the loop but aren’t really involved in the system design and testing. They are certainly dependant on people who do their jobs, but aren’t really the hands-on kind of people.
I mean conceptually if you don’t think that end users need to be involved in system design and testing there’s a problem. In that case, you should probably address that red flag before you create a very complex project plan. People should sign off on that kind of thing knowing that it is a general rule, and there may be times in which one party is more involved than the matrix would really suggest, but that’s just the way that the project tended to evolve.
Flaherty: Communication is key throughout all stages of implementation. Regular status meetings and clear documentation help ensure that everyone remains aligned with the project goals and timelines. Miscommunication or lack of updates can lead to misunderstandings, duplicated efforts, or missed deadlines, so establishing a cadence for updates is essential.
Another important factor is flexibility. Even with the best planning, unexpected challenges may arise, such as changes in business requirements, technical limitations, or resource availability. Teams should be prepared to adapt their approach and revisit earlier stages if necessary, rather than rigidly following the original plan at the expense of project success.
Finally, post-implementation review is often overlooked but critical. After the system goes live, gathering feedback from users and stakeholders helps identify any issues or areas for improvement. This review process not only ensures that the system meets business needs but also provides valuable insights for future projects, fostering a culture of continuous improvement.