Last time I wrote about the importance of considering the Change Management aspects of a systems implementation, prior to embarking on the project. However, this is something that must also be considered throughout the life of the project, so in this blog I will be discussing the importance of change management during your implementation.
Let’s assume that you have selected a new core business system, it could be that you are migrating from another system or this is your first integrated IT system and you are therefore starting from manual systems and spreadsheets. Either way the process of change is going to be similar.
If you have followed the advice of the previous post you will already have documented the project objective and scope into a Project Initiation Document or PID. You should also have established who the main players are going to be in running and controlling the project.
Once you have signed contracts with your chosen vendor it is important to establish the project governance and define roles and responsibilities on both the client side and with your software vendor. This provides clarity on how the project has been broken down, maybe into individual workstreams with a business SME (subject matter expert) responsible for each.
The most important role in the project is the Project Manager. He or she will be responsible for ensuring the project is delivered on time and to budget. This role can be likened to a conductor of an orchestra, they don’t need to be able to play each instrument but they do need to be able to bring them all together at the right time!
Your vendor will probably appoint their own Project Manager who will take responsibility for a lot of the onsite configuration of the software as well as the traditional PM duties. Your project is likely to include within its scope more than just the implementation of a new system – there may be some legal or risk work to be done, impacts on internal policies and procedures, documentation etc. Therefore the responsibilities of the PM are likely to be a lot wider than just the system implementation. An independent will be more objective than an internal staff member and should have a lot more experience in this type of project. One would hope that you won’t be changing core systems any more frequently than once every 10 years therefore you are unlikely to have a lot of in house expertise in this area.
The number of workstreams you need and the size of the project team will vary greatly depending on the scope of the project and the size of the organisation. Usually you will want to ensure that your Project Team meets on a weekly basis and the Steering Committee at least monthly.
Now you have your project structure established how are you going to keep track of everything? I strongly recommend having a formal process for this, particularly when it comes to recording and tracking actions.
Everyone involved in your project (the Stakeholders – more about them later!) likes to see a Project Plan (or Gantt chart, usually produced in Microsoft Project). Apart from their presentation value these charts are of little practical use to the PM are very much overrated. It is far more important to have a list of tasks with dates and responsibilities. I use an Excel template with individual sheets to record Actions, Changes, Risks, Assumptions, Issues and Dependencies. This becomes the central record of the project and can be used as the agenda for the weekly project team meeting and as the source for a summarised Steering Committee meeting. I am also a great fan of traffic light status indicators (Red, Amber or Green) to show where we are with the project.
One of the most important, if not the most important, aspect of managing change during a project is Stakeholder Management. Stakeholder is just jargon to describe anyone who can either influence your project or is going to be affected by the new system. It is worth spending time analysing who your stakeholders are, their power in the organisation and how they could influence your project – both positively and negatively. Depending on where they are on this scale of power vs influence will define how much effort you spend on keeping them informed or getting them involved. Your time is limited so you want to ensure that you are expending your efforts in the right place. Regularly reviewing your stakeholders needs will help you to do this.
In this article I have described how you go about managing your system implementation, getting the right people involved and ensuring you keep track of events as the project moves through its various stages to completion. In my next article I will discuss what happens after you go-live.
