Understanding IT Systems Change Part 2
Blog: Solitaire Consulting Blog
In this second of a series of articles on understanding IT systems change I will discuss the importance of considering the change management aspects of your project continuously throughout its implementation
Read the first article here:
>>> Understanding IT Systems Change Part 1 – Context and Initiation <<<
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.
Consider using a RACI matrix to ensure there is clarity around roles and responsibilities.
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 ensuring that they deliver according to the plan. However, this is no subsitute for not having your own Project Manager. 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!) like to see a Project Plan, usually displayed as a Gantt chart in Microsoft Project, but there are many better alternatives. Apart from their presentation value these charts are of little practical use to the PM and are very much overrated. It is far more important to have a list of tasks with dates, responsibilities and their dependencies. Whilst there are a number of specialist tools for managing projects, for a small project, you can get away with using Excel 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.
As your projects get larger and more complicated you do need to invest in more sophisticated management tools. I regularly use Basecamp for managing a single project and recommend KeyedIn Projects when you have a large change programme or portfolio of smaller projects to manage.
Whatever tools you use or size of 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.
A critical success factor in managing any systems change project is engagement of the main body of users (i.e. staff) who will use the new system. Consider adopting a formal change management model to guide you through this process and help overcome the many barriers to change. I favour basing my framework on the 8 Steps to Change model developed by Dr John Kotter. Whichever model you use though, it is important that this runs in parallel to your project management methodology.
It is important to remember that this change model is not a Gantt chart and one element doesn’t automatically start when the previous one finishes. Many of these processes are needed throughout the project lifecycle.
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.
Coming soon, the next article in this series:
Understanding IT Systems Change Part 3 – Embedding the change once live
Leave a Comment
You must be logged in to post a comment.
