Congratulations. You’re on the Board, or maybe the audit committee. You have decided to go for it – you’re going to implement a new system. Perhaps you want to ‘use new technology to realise efficiencies’. Or maybe ‘bring in a new service’. Or even replace your system before a service provider withdraws support (heaven forbid). Whatever the reason, you want to make sure things are on track.
Well, here are the basics:
1. Does everyone have a common view of what you are implementing?
Lots of people in the organisation may want a new system. Have they listed what they want the new system to do? This is your ‘requirements’ and, it sounds basic, but most organisations don’t do this.
Bonus level if you list requirements that don’t relate directly to what it does (for example, security, how well it can be supported, data protection, resilience). These are ‘non-functional’ requirements and most forget these.
TL:DR – ask for the requirements document.
2. Does everyone (relevant) have an input to the changes?
You won’t succeed unless those impacted by the change have some involvement. I know they’re busy, but their involvement is a part of your decision to implement a new system. This could be a ‘steering group’ involving relevant departments, or people nominated in different parts of the business to validate or test changes. Make sure they’re involved and that progress is shared with them. Better still, give them authority for certain decisions.
TL:DR – ask for the members of the steering group.
3. Do you have a proper plan?
This means you know what is happening and when. It means you have a proper budget and are tracking performance against this. It also means you are tracking changes to scope, issues, dependencies on other things and risks when things go wrong (they will go wrong) and doing your best to manage these.
TL:DR: Ask for the latest project plan.
4. What does success looks like?
Define what ‘complete’ means at the start and run the project until it’s achieved. Note, the end point will likely not be a perfect system, but unless you define an achievable end point, you’ll never get there.
TL:DR: Ask for success criteria at the start. Or at least ‘how will we know when it works’?
5. Do you know when to stop?
Many IT projects don’t work as planned. I know that’s inconvenient – after all, you’ve likely spent money and time on this. However, sorry, but some just don’t work for whatever reason. Learn the lessons from this, (to make sure the next one goes to plan) but don’t waste your time slaughtering the survivors. It happens – you don’t always need to throw good money at failing projects. It helps to define a timescale and budget after which you won’t continue with the project or will take another approach.
TL:DR: Ask what the terminal budget and terminal duration of the project are. If they aren’t met, then be brave and can the project. It’s sad, but it happens. I have found that IT projects that take over two years are in real danger, unless you’re in a massive organisation.