It’s common to assume that the key to success in IT project management lies in getting the right tech. Get the tech right and everything else will follow. However, based on my experience of helping numerous different local authorities manage complex technology implementations, it’s the human factors that really make the difference between success and failure.
Managing local government IT projects is tough. There’s no doubt about it. Local authorities work to extremely tight budgets – and those budgets are tightening all the time, often mid-project. Timelines can be extremely strict and subject to change due to factors that are often completely beyond the control of the project manager. There’s additional complexity due to the number of different stakeholders involved in public sector projects, often with competing demands. There are also some particular challenges associated with IT projects. For example, local authorities are often working with
Clearly, managing projects of this nature requires project managers with a rare combination of skills. I’ve worked with many such managers over the years and I’ve observed that those who are most successful tend to be those who combine ‘technical’ project management skills – time management, tight focus on budgets and timescales, attention to detail and so on – with people skills, emotional intelligence and a deep understanding of how people are the key to project success. So what does this mean in practice?
It’s not uncommon to see the tech become the driving force in a project, to the extend that the people involved in implementing the tech can lose sight of what it’s ultimate purpose is. The tech should be a means to an end, rather than the end itself. What really matters is the tangible benefits that users gain, whether those users are the authority’s own staff or the citizens that it serves. So how can project managers maintain a focus on end user benefits?
Ensure the solution does deliver tangible benefits
For this to happen it’s critical that any IT solution to be implemented is selected with end user benefits to the forefront right from the start. End users need to be part of the project team, involved in selecting the solution, not merely brought in at the end when it’s already a done deal. The only people who really know how well the tech is going to achieve it’s objectives are the people who are actually going to be using it. It’s depressingly common to see technology being implemented with little or no user involvement. Go down that route and the result is often tech that’s not fit for purpose, that end users simply refused to use.
Tap into the knowledge of existing users
Following on from the point above, the people who are currently using the system are those that know it best. They’ll know how the process is currently being performed, what works and what doesn’t in the existing system. They’ll be aware of all the hidden pitfalls and things you need to be aware of. They know how the legacy systems work, which processes are automated and which are manual, what’s been documented and what hasn’t.
Make sure existing users are kept in the loop
People tend to get twitchy when they feel that they’re not being consulted, that their views haven’t been taken into account, or that they’re not being kept informed about the progress of things that affect them. I strongly recommend keeping in touch with users (and indeed other stakeholder groups) through regular targeted communications. This might mean a page on the website where you put updates of project progress, or it could mean a series of emails or even meetings with particularly important stakeholder groups. It’s tempting to send information to managers and ask them to cascade this down to the users but in my experience this rarely happens in the way that it should. If you want people to know things, then tell them yourself.
Involve real users in piloting and testing
Tight timescales and tighter budgets often mean that testing is cut down to a minimum, but time spent on effective user testing will always reap dividends and save you time later in the project. Don’t be tempted to rely on members of the project team to do the testing. People who’ve been intimately involved in the development of the system are never the best people to test it as their experience in no way replicates that of a user. People who’ve been involved in the project’s development are no longer able to put themselves into the shoes of someone who’s never seen the system before and imagine what their user experience would be like. It’s more valuable to test your system with one genuine user than it is with twenty people who already know it inside out.
Make sure your rollout plan takes working patterns into account
Most local authorities have numerous staff who work flexibly, or part time, or who job share, or work shifts, or work remotely and are rarely on site. A good project manager needs to take this into account when putting together a rollout plan. How will you ensure that everyone has been trained appropriately and understands the new system? It’s rarely possible to get all the relevant people in a room together for a single briefing session, so more creative options need to be considered. Perhaps you can develop a number of ‘super-users’ – people in each team or department, or at each site, who are tasked with helping colleagues get to know the system. Or maybe you implement the system at a site, training all those who are present that day, then run a ‘mop up’ session a few days later to make sure that everything’s working as it should be and to help those who were not at the first session.
