Understanding how your IT project got off track will help you to realign your project and relationship; helping to deliver more value. The chances are, both you and your vendor contributed to the issues, but don’t take it to heart though, research shows that IT projects typically fail to achieve the client’s most important expectations
Major IT projects are tough to manage. Many of the challenges you’ll be faced with arise when representatives from both your organisation, and the supplier’s, misunderstand each other’s expectations.
This usually has two fundamental causes:
1. The service outcomes might not have been clear
You may have sat through hours of meetings, spent nights planning and checking all of your documented requirements and specifications. You may even have spent weeks or even months hosting the beginning of fair and transparent procurement process. At the end of it all you will have arrived at what you feel to be a list of your requirements. This is where many have room to improve. Whilst you might understand how these relate to a business outcome, the vendor might not. As a result, many vendors then focus on the prospect of implementing technical requirements you’ve stated, rather than on devising a solution that will meet your business needs. In situations like this, a good vendor will challenge your thinking and ask “what does ‘good’ look like to you?” – If you can’t quantify this, either in deliverables or value added, you may need to think on your existing requirements to avoid any future misunderstandings. If you’re unsure as to exactly what should be delivered, the vendor probably won’t be able to deliver it.
2. The supplier may not have exercised its ‘duty to warn’
A good vendor will challenge your thinking and will often ask you to back up your statements, requirements and assumptions with hard evidence. This can sometimes be difficult, and perhaps even uncomfortable, but it’s strictly necessary to ensure that your IT project has the greatest chance of succeeding.
If however, they don’t challenge or warn you, you could be in trouble, some vendors don’t act as a true ‘critical friend’ to their clients. From the outset, they should proactively and constructively challenge the client’s lack of clarity about their expected business outcomes. Without this clarity, the vendor is unlikely to understand your envisaged business outcomes. As a result, it means the vendor is unlikely to deliver a fit-for-purpose system that’ll meet the needs of your organisation, or the expectations of your peers.
How the law can help you sleep easy…
It’s important to note that in the majority of situations, IT vendors of mission critical systems have ‘expert responsibilities’ in law, which if followed, would avoid the consequences of miscommunication and unclear requirements.
Look at it like this. Very often, you bring in a vendor because they have experience in setting up and implementing systems and change in organisations like yours. In many cases, they’ll have done this hundreds of times.
As such, if you give them a set of requirements, they should know from past experience as to whether or not the requirements you’ve set out will actually aid you in delivering your desired business outcomes. If they’re sat at the other end of the conference table thinking, “having that integration is all well and good, but how does that help them increase satisfaction/sales/revenue?” – Then it’s at this stage that they need to pipe up and ask the question. In doing so, they may inform you that there’s an easier, less complicated way to achieve the outcome you want. Their expertise may lead the project down an entirely different route that will deliver the outcome you need, but in another, more cost effective way. This is their ‘expert responsibility’, this is why you’re paying them. If they don’t put it to use, they’re doing you a legal disservice.
In Stephenson Blake (Holdings) Ltd. v Streets Heaver Ltd. [2001] Lloyd’s Rep P.N. 44, QBD (OR) the UK court set out the obligations of a consultant in such contracts. It was ruled that consultants must advise clients as to whether their perceived needs coincide with their actual needs; they must point out if these actual needs will be met by the proposed IT project or implementation, and whether or not the employees of both parties have the skills and capabilities to deliver such a project. Finally, it also falls to the consultant to ascertain whether your budget will be sufficient to meet your objectives, and to tell you about it.
So If your project has gone over budget, or if you feel that the business outcomes you were working towards aren’t being delivered; but you documented and agreed your business outcomes at the very beginning of the project, then the law may be on your side.
However
If at the beginning of the relationship, you were unclear on your business outcomes, then the vendor will not necessarily have known what they were working towards.
At the same time, if you or members of your team felt that things weren’t going your way, and actively told the ‘expert’ vendor what they ought to be doing – you’ve ultimately eroded their position as the ‘expert’ because you’ve stepped in to rectify everything. This makes you look like the expert, and makes things a little difficult. If the vendor can’t use their experience and techniques to do the job, because you’ve told them to do it differently, is it really their fault if it all goes wrong?
This behaviour can sometimes inadvertently hinder the vendor’s performance, which frustrates everyone.
No one likes fielding awkward telephone calls or shirty emails.
When mission critical isn’t critical
Larger IT projects enable business change for the organisation, which is usually operationally critical. However, we find that some senior executives in client organisations regard these systems as just a ‘technical project’, almost like a lower level back- office function. These projects often don’t get the senior stakeholder buy-in they need to enable transformation. On its own, this can lead to project failure.
In turn, as your organisation’s CIO or Senior Head of Service, you are responsible for making sure you ‘sell’ the criticality of this project to your peers and other senior stakeholders. If they take it seriously, then your organisation’s behaviour will demonstrate a genuine commercial trust building process. This will result in successful behaviours, driving maximum value and a successful implementation for you and a fair profit for your vendor.
Pulling it all together
To help your vendor, make sure your business outcomes are clear. Get them to challenge you on your requirements to ensure that your vendor is clear about precisely what you intend to achieve though the delivery of your IT project. At the same time, ensure that your stakeholders know exactly what’s at stake and just how important your project is. This will help to drive the right behaviours from all parties to ensure a positive relationship that delivers greater value.
