InetSoft Webinar: How Long Does It Take to Complete an Information Management System?

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.

Moderator: Now some people might be wondering, “how long does it take to complete an information management system?” In regards to how long the implementation should take, I imagine that there are a various number of different factors involved especially if the plan goes as planned, or it doesn’t. What would I tell a company who wanted a time estimate upfront? How long would their implementation take?

You have to hit them down on the head. It really is more art than science. It’s not an algebraic equation or a recipe. It’s not a two parts data cleansing and one part training where you come up with some sort of number. Certainly a lot hinges on the scope of the project and what the client wants to do.

For example, if you have a lot of customized interfaces, or they want to get under the hood of the application and really modify it, that’s a lot different than implementing something “out of the box” or going with the vanilla configuration.

I often talk about how the architecture of the new system really drives how long the project will take and how complicated the project plan needs to be. If an organization is stitching together a bunch of best of breed systems along with an enterprise data management system, you probably don’t want to do too much at once but I would say it’s pressed.

Flaherty: Again, it depends on a lot of factors but to implement the core modules like financials and payroll for a two or three thousand personnel organization, and the size and age of the data and the legacy system, you know it should take anywhere from six months to a year. This could obviously be too high or too low.

The fundamental mistake that a lot of organizations make is that a lot of times, organizations make the mistake of picking a date and then retrofitting the project plan into that date. I think that’s very dangerous. There are a lot of valid reasons for going live on the first of the year or the first of the quarter. Don’t get me wrong, but it’s very difficult to say when we have to go live on this date and then six months earlier you are back into a start date, and as a result you are pressing a lot of things together.  

Ideally you can do that pre-implementation audit and identify what your issues have been and naturally pick a start date that makes sense. If you feel like you don’t have enough resources, and are short a couple of people, you could bring on another external consultant to bring that date closer to what you want, but I think the worst thing that people can do is just arbitrarily pick a date and then hopefully make it.

Moderator: Once the company thinks they are ready to go live, there might be things that can go wrong at that stage. What should you watch out for at that time and how do you set up for success with the go live date?

Flaherty: The short answer is that if the testing went well, issues were documented, investigated and solved, then the activation really should be a mere formality. Most go live issues that I've seen really do stem from poor testing or planning around the entire implementation.

Read what InetSoft customers and partners have said about their selection of Style Scope for their solution for dashboard reporting.

Yes it’s possible that programs bombed. There might have been extracted data from the old system and brought into the new system, or the security somehow prevents something from happening. That tends to be really exceptional. 

Organizations that purchase very well established enterprise resource planning systems are really spending a lot of money but they are getting a quality product so the last thing that these vendors want is for the products to fail at the last minute. Of course, there is only so much that vendors can do, and it really does tend to come back to people, and the things they didn’t do well or thoroughly during the project.

Also, it’s been always a problem if they didn’t have the time. It all goes back to the earlier point of something with the project plan or the resources or the training. All of those things, if they are done well and properly, should result in a very smooth activation in a new ERP system.