How to effectively work with an IT consultant

What are some common challenges that arise when working with IT consultants and how can organisations mitigate those challenges?

There’s a few different areas that the challenges can fall into. Firstly, is whether you’re trying to fill a short-term need within your team or whether you’ve got a specific problem that you’re trying to solve. My advice would be to try and make the most of your consultant, get their input and ideas on how you can achieve your organisation’s objectives but in doing that, make sure that you’re ready and willing to listen to some new ideas. Are you and your teams receptive to that? The big benefit is that you’re likely to get some new solutions to old problems.

In addition, some of the challenges can include not having clear objectives, priorities, and expectations. As tech consultants, we live and breathe trying to make our customers happy and the only way that we can do that is to understand what will make you happy. So, from your side, I would advise making sure your objectives, priorities, and expectations are clear. You provide regular communication and updates, and the tech consultants will do the same. Also, feedback as soon as you possibly can if there are any course corrections needed. It’s very rare that anybody gets things perfectly right the first time. Please do share your thoughts and ideas regarding what’s working well and what isn’t so that the consultant can take steps to make things better.

Also, highlight good work. Everybody likes to know when they’ve done a good job regardless of whether they’re tech consultants or anyone else. So make sure to give those pets on the back.

Another common challenge is a little bit of an ‘us and them’ culture – you see the consultant as being an outsider and not part of the team. It’s a little bit cheesy, but I like to work on the motto ‘one team, one dream’ so integrating everybody within the team really does pay dividends. The team sharing common goals, learning lessons rather than appointing blame, and, probably most importantly, celebrating successes as a team.

The last challenge, which is one that can be difficult to mitigate, is engaging your consultant late in the project which means that the consultant has to play catch up. It could mean that key decisions have already been taken that could have been done differently if the consultant was engaged a little bit earlier. My advice on that would be to try and plan ahead and start conversations with your consultant early. Again, have regular communication to confirm the project status and the likely start date for the consultant so that they land at the right time when you need them. And make sure you understand your organisation’s onboarding process for third parties: any clearances, any mandatory training that needs to be done, laptop and account provision, access to different resources etc. It’s a little bit of a practical one but it often gets in the way of work getting started on time. So those are my big ticket things.

How does one ensure that the goals of an IT project align with broader organisational objectives? What role do you believe IT consultants should play in that process?

So if I take the first part of that question first: how to make sure an IT project’s goals align with the organisation’s objectives. First of all, it’s making sure you have clear organisational objectives. Know what you’re trying to achieve as an organisation and know your priorities as well because, more often than not, your priorities will be tested during the project delivery. Communicate those objectives and priorities to the IT project team so that they can see how their work is going to support the bigger picture. It will also allow the IT team to make sure the project goals align with the organisation’s objectives and that, in turn, enables the IT team to prioritise their tasks and deliverables. The goal of any project is to deliver as much value as possible within the constraints that that project operates in whether that’s time or budget constraints.

Talking of constraints, do listen to the IT team’s schedule and budget estimates. It’s always a tricky conversation. It’s always a lot of back and forth between the IT team and the organisation. And it’s right that there’s that challenge and drive for efficiency, and sanity checking that those schedules and budget estimates are correct. But if you do shorten timelines, if you try and get more done with less, there’s often a level of risk that’s introduced in doing that. So make sure you understand what those risks are and that everybody goes in with their eyes wide open as to what the opportunities are but also what risk that brings.

Another key item to think about is understanding any other projects and programs or initiatives that might impact the IT project and knowing what the relative priorities are for the organisation. For example, delivering a new feature or a new solution might seem more important but if one of your critical legacy platforms is going out of support, that might actually introduce more risk to the organisation and need addressing first. Having visibility of those issues and dependencies and decisions is key.

Then, once the project gets off the ground, it’s key that non-IT people are engaged throughout the project. Whether that’s business stakeholders receiving regular reports and updates, whether that’s subject matter experts supporting the IT project delivery, whether it’s the users of the solution being involved in some of the testing activities, make sure they’re involved throughout because then it goes a long way to guaranteeing that the IT project will deliver what the organisation actually needs.

For the second part of the question (the role IT consultants play), I think IT consultants first and foremost bring their experience with them. That’s from other similar projects and organisations but also from different projects and organisations, sort of cross-fertilising ideas from one activity to another. Consultants can offer alternative approaches and solutions so if there are those scheduling or budget constraints, the consultants may well have some ideas as to how you can run things in parallel and how you can get the biggest value for the shortest time.

They also are a little bit like a mirror in that they reflect back and play back your priorities and objectives. Sometimes hearing those things from somebody else who’s independent from your organisation makes them resonate and can challenge your perceptions of what they are.

As I said, consultants share experiences from other places that will help you to avoid common pitfalls in your project delivery, give you a higher chance of success, and also there’s a level of independence using IT consultants. They’re not engaging in any politics within the organisation, there isn’t always that history there so that baggage of ‘we’ve tried this before and it failed, and it’s inevitably going to fail again’, they don’t bring that with them. There’s that sort of independence and optimism, which can be really helpful if you’re delivering a difficult project.

In your experience, what are some best practices for establishing clear communication channels between IT consultants and those internal stakeholders?

First and foremost, you need to identify the relevant internal stakeholders. Usually, they are sponsors or budget holders who want the project to go ahead. Often end users as well because they’re the people who will be using the solution once the project is finished. But essentially those internal stakeholders are anybody with a vested interest in the project’s success.

Secondly, I’m a big advocate for transparent communication. So, open and honest feedback: good and bad. Whenever people think about feedback, everyone jumps to the bad but the good is just as important. But also capture any key decisions so they can be referred to and re-evaluated as the project progresses.

I think the most important thing is regular contact – getting to know your IT consultant, your IT consultants getting to know the stakeholders. That can happen in a lot of different ways: through daily stand-ups or weekly one-to-ones or even just ad hoc conversations, but in those interactions, it’s important for all parties to be open and aim to build that trust and rapport. Because once you’ve got that trust and rapport in place, it makes it much easier to have difficult conversations further down the line. If there are risks or blockers or delays or things aren’t quite going to plan, you need to be able to be open and honest with each other so you can work through that. If there’s a blocker to some of that conversation happening, if you don’t know about it then you can’t take steps to mitigate that and manage it through.

And to end on a more positive note, I strongly recommend sharing good news. Nothing helps to deliver a project better than the whole team feeling like they’re succeeding and progressing well towards the ultimate goal.