Top Ten Tips for Running IT Change

IT Change Programme

IT change programmes can be massively complex. So, where should you start? What are the pitfalls and where is the most “Value-added?” Explore our Top Ten Tips for Running IT Change.

According to research on more than 5,400 IT projects conducted by McKinsey and the BT Centre for Major Programme Management at the University of Oxford, large IT projects typically run 45% over budget and 7% over time, while delivering 56% less value than predicted [McKinsey (1)]. This is why getting it right is so crucial.

TOP TEN TIPS FOR RUNNING AN IT CHANGE PROGRAMME

Fixing a negotiating strategy and agreeing this internally is essential before the first contract negotiation meeting with the vendor takes place. This should cover the negotiation objectives, timescales, internal leads, escalation points, governance, and decision stages.

The first meeting sets the tone for the whole negotiation. It is imperative that the vendor perceives you as knowledgeable, authoritative, organised and with a clear mandate from your business to negotiate on their behalf. This is likely to require senior business stakeholders to personally endorse you in that meeting.

The breadth and depth of the scope of work will evolve both during negotiations and after signing. During negotiation changes to scope should be carefully tracked. This will enable pricing challenges to be assessed based on the size of overall change. Commercial models in the contract must be flexible and unit priced, so increases and reductions in scope can be accommodated without renegotiating the contract.

Commercial negotiations should be separated from negotiations on service requirements and transition requirements. Commercial negotiations are fundamentally different in terms of attendees, objectives of the parties, outcomes and how the process should be managed. Service and transition requirements are focussed on mutual understanding and documentation of like-for-like requirements, or agreed enhancements managed between the knowledgeable service experts of both parties. Commercial negotiations inevitably require give and take where not every decision will be mutually beneficial.

The cadence of the meetings is important to determining the outcome. Running the process too quickly will result in important details being left unaddressed or only partially resolved. If there are too many ‘TBAs’ left in a signed contract then, in the absence of commercial comfort clauses, the price may vary post-signing by up to 50%. Running the process too slowly will result in a lack of focus, often with too few resources being deployed and issues being debated for too long without resolution.

It is very tempting to start the negotiation process with a contract that the supplier already has on the shelf. Whilst this gives both parties something to talk about, it often results in the overall process taking longer, because it does not represent what is required by the customer, and because the supplier has a greater propensity to stick to what they first issued. Creating and issuing the first draft of the contract to the supplier bears fruit at almost every stage of the negotiation.

The key to a successful IT services contract is a properly scoped and negotiated transition schedule. A good business case can easily be destroyed by a poorly drafted schedule with insufficient detail and commercial protections. As a rule of thumb, the transition schedule (including appendices) should be the longest schedule.

If you don’t manage your internal stakeholders, then your supplier will! Regular updates for internal stakeholders, including face-to-face time with senior stakeholders, are essential. These should be honest and open discussions where opportunities and blockers are discussed. Agreement on how to progress should be reached and supplier communication strategies determined. Hard work is required to ensure that a supplier is not able to ‘divide and conquer’.

Roles on the negotiation team should be clearly understood and adhered to. Internal debates should be had behind closed doors. Listening to an internal debate had at the negotiating table will often give the other party an advantage through revealing where weaknesses lie. One person on the team should be given the role of leader and the others on the team should follow their lead. It is important that if that person is not the most senior person on the team, the leader role is still respected.

Over the course of the negotiation, different risks will be identified. It is important to document these risks as they occur. Some risks will be mitigated through agreement with the supplier during the drafting process. For the risks where it is not commercially acceptable to the supplier to mitigate these, it is important that they are considered prior to the contract being signed. If necessary, they may need to be confirmed acceptable through internal governance procedures. Having the risks clearly documented and working with internal audit and other governance bodies during the negotiation will make this final stage easier. Considerable time and effort are spent training procurement personnel to be excellent negotiators, but much less time is dedicated to equipping those individuals to run large multi-stage negotiations that extend over multiple months, rather than weeks. Many of the points covered, although focussed on IT Services Contracts, are equally applicable to Service Contracts for areas other than IT.

(1) “Delivering large-scale IT projects on time, on budget, and on value”, Michael Bloch, Sven Blumberg and Jürgen Laartz, McKinsey Digital

Mark Elkington Black and White
Senior Managing Consultant at Barkers

Mark is a Senior Managing Consultant at Barkers, where his extensive experience of IT sourcing in FTSE 250 companies is utilised to support clients sourcing software, hardware, telecoms and outsourced services, including negotiating major software deals from vendors such as SAP, Oracle, IBM and Microsoft.

This website uses cookies and asks your personal data to enhance your browsing experience.