InetSoft Webinar: Stages of an Information Management Implementation

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.

Moderator: Who should be getting involved at each stage of the implementation process? What departments should be represented here?

View a 2-minute demonstration of InetSoft's easy, agile, and robust BI software.

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. I personally haven’t met too many CIOs who are entering journal entries and SVPs of HR who try out applications themselves. They are certainly dependant on people who do their jobs, but aren’t really the hands-on kind of people.

So things vary at different points, and the group responsibility matrix is just a general guideline of how people should be involved. Going back to the earlier question on project planning, it probably makes sense for people to buy into this group responsibility matrix before they create a 600 line, complicated projected planning in Microsoft Project or some other tool.

Read the top 10 reasons for selecting InetSoft as your BI partner.

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.