Tip of the Week #78 – Recognizing Risk Factors in a Print MIS Implementation Project
Senior Consultant Kit Tomshøj brings us much more than one valuable tip this week – an entire menu of things to look out for during an implementation project!
My company’s strategy is to sell software licenses and implement standard print ERP systems.
My customer’s goal is to implement my system comprehensibly and inexpensively.
We are all in it together – and I want to deliver the best system in the shortest time possible.
Sometimes things get in the way of us doing this together, risking the implementation becoming more expensive than necessary.
I have made this list of things which lurk in the bushes while we work:
- Change of Staff
If the super user we start with gets replaced in the middle of the work we may have to repeat training or decisions.
- New Boss
If a new boss or project manager comes in and wants to re-examine the project and strategies we have been working with, things may be stalled or delayed.
If I go onsite and the resources I plan to work with are unavailable for some of the time, too busy to settle on the work we have planned or preoccupied with phones or email when present this will cause delays.
We have to have online access without any problems, and at least 2 independent access points.
It is important that our customer is able to provide the technical information as well as the business side information we need to set up.
Lack of information can seriously hurt a project.
It is very important for an implementation of a company’s estimation module that we have decision makers on the team – people who are able to make the decisions without being overruled by others.
A project must have the attention and sponsorship of the company management. If the management does not take it seriously – the employees will not.
If we have homework – both myself or the project team I am working with, this must be attended to.
Homework is often a prerequisite for getting to the next step in the project.
My project team members will be required to test the setup we make together – in all aspects where there might be something to test. They will know their business much better than me, so they will have to make sure we have thought of everything.
My project team members will be required to think – inside the box and outside. Which things can we optimize? Which things could be made smarter to be quicker for the customer?
For my part, I am required to think about keeping things standard. And when thinking about customizations, I need to ensure that I am helping my customer to not become locked in the future because of certain requirements they make today.
If a customer require us to customize PrintVis functionality more than we usually would (there are always some smaller things) this can take time to define, build, test and put in place with the rest of the base data.
It is important that we learn to communicate in clear terms about the project – specifically this is true for issues we bump into along the way.
I am hoping to teach my team how to report a problem and error or an unexpected message or behavior from the system. But I could go on for days about this.
Scary, long list?
Well, we rarely run in to a larger collection of these in any one project – and as long as we are clear about the dangers when we see them it should all be something we can address and correct when we do.
Thank you Kit!