No one will disagree that successful IT outsourcing relies on good planning. However, good planning is not just about setting timelines and delivery dates. It also involves drawing a roadmap of how a project should proceed, understanding how it can unravel and detailing what the parties must do to ensure they stay on course.

As the following eight lessons will show, good planning is best conceived from experience.

LESSON 1

APPLY THE KISS PRINCIPLE

Keep It simple, stupid!

There is no problem with the technical specifcations being complicated – they will be read and administered by technical people who will understand the complexities. however, pricing schedules, performance arrangements and things that are administered by non-technical people need to cater to all levels of training, skill and even commitment.

For example, if the pricing is too complicated, with lots of variables and formulae:

  • invoices don't get checked, because they are too complex
  • it is too hard to vary charging arrangements over time as circumstances change – so even more inappropriate/inaccurate amounts are charged
  • service providers end up providing one-line invoices because the calculations are too long and complicated – and customers pay them because they don't understand the system.

LESSON 2

DON'T LEAVE TO TOMORROW WHAT SHOULD BE DETERMINED TODAY

Frequently, disputes arise because a part of the contract – such as a service standard – was thought to be too hard to work out prior to contract signature, so it was left 'TBD' (to be determined). The parties never got around to determining it because it remained too hard or didn't seem important at the time.

This is avoidable. you can:

  • work something out, even though it is hard (it will only be harder later)
  • put something in on the basis it will be revised later – chances are that it won't be revised later, but at least you have something in there
  • ask other people how they have handled the same circumstances.

Don't leave anything TBD – it will never happen!

LESSON 3

WRITE A SOW, SOR OR SPECIFICATION THAT WORKS FOR YOU

In the past, the description of what the contractor needed to do in order to get paid – whether expressed in a statement of work (SOW), statement of requirements (SOR) or specifcation (Spec) – was often written in a very technical way. Technical people wrote prescriptive documents full of detailed technical requirements: how many servers, how many routers, which versions of software etc.

These days, better practice is to write the sow/sor from the top down, focussing on output/operational requirements, not on technical inputs. This means the spec will be more functional rather than technical.

Good practice will often lead to something like a four-column document that sets out a description of:

  • the business requirements or required outputs
  • the delivery methodology
  • the required performance standards
  • how assessment of compliance with the requirement will be done.

LESSON 4

UNDERSTAND AND MANAGE IP

Mismanagement of Ip issues can lead to unforeseen consequences. customers may be inadvertently 'locked in' to certain solutions because of restrictive licences. They may even be forced to abandon solutions because of insuffcient Ip rights. They may have to pay inappropriate amounts for support.

Therefore, businesses must understand the Ip inputs. undertake an Ip audit, or get the contractor to do it, and produce an Ip register (as a schedule to the contract) that clearly identifes:

  • the Ip inputs (nature of Ip, who owns it, how it is provided, limitations on usage rights terms, licence terms etc)
  • what Ip will be created in the project (nature of Ip, who will own it, how it will be managed, ongoing usage rights of both parties etc).

Get Ip clarifed before the contract is signed – if it is left until later, it will never get done.

Make management of IP a KPI with monthly reporting by the contractor and proactive management by the customer.

LESSON 5

PLAN FOR TRANSITION

Nothing is forever.

Detailed planning and thinking about the requirements for transition in and transition out is critical to realising the benefts of IT outsourcing. otherwise the disruption and dislocation is so large that the negatives can outweigh any positives.

For transition in, it is necessary to understand your current arrangements. you need to document them carefully and then consider how they can be transitioned to a new service provider, what steps need to be put in place in advance and what steps need to be undertaken in the transition period.

Transition out is not so easy. It requires careful thought about where you might be up to either at the end of the contract, or at the end of any option period, or at an earlier time if the contract is terminated.

The contractor should be required to prepare a draft transition out plan as part of its proposal. It should then be accepted at an appropriate point after contract and updated periodically (which you must check) so that there is always a plan ready to be used if disaster strikes.

LESSON 6

MAKE SURE THE RIGHT PEOPLE ARE DOING THE RIGHT JOBS

People are critical to making outsourcing work. make sure the contractor doesn't tender the 'A team' and then deliver the 'B team' – and then bring back the 'A team' when re-tender time is getting close. Include and use your contractual 'specifed personnel' protections.

If contractor personnel are not performing adequately, make sure the contractor replaces them quickly.

Make sure your business has the right people managing the contract. They need to have the right skills and experience for what is generally a critical contract for the wellbeing (and program delivery) of your business.

LESSON 7

BUILD YOUR CONTRACTS FOR FLEXIBILITY

If there is one thing that is certain to stay constant, it is the changing nature of your business. It is critical to build your outsourcing arrangements in a way that caters for these inevitabilities.

Include mechanisms that accommodate business changes so that resultant costs are reasonable and savings are passed on. It is reasonable for effciency savings to be shared but scope-driven savings should be passed back to the customer.

LESSON 8

MAKE PROVISION FOR CONTINUOUS IMPROVEMENT

It is vital to write your contracts in a way that ensures that contractors are required to:

  • report on opportunities for improvement
  • adopt those opportunities where that is appropriate
  • pass on cost savings or the beneft of any effciencies to the customer.

Be as robust as possible in putting into contracts any known or anticipated opportunities for improvements and any anticipated cost savings that will result and how they will be shared between the contractor and the customer.

CONCLUSION

So remember:

  1. Apply the KISS principle – Keep It simple, stupid!
  2. Don't leave to tomorrow what should be determined today.
  3. Write a sow, sor or spec that functionally works for you.
  4. Understand and manage IP.
  5. Plan for transition (in and out).
  6. Make sure the right people are doing the right jobs.
  7. Build your contracts for fexibility.
  8. Make provision for continuous improvement.

© DLA Piper

This publication is intended as a general overview and discussion of the subjects dealt with. It is not intended to be, and should not used as, a substitute for taking legal advice in any specific situation. DLA Piper Australia will accept no responsibility for any actions taken or not taken on the basis of this publication.


DLA Piper Australia is part of DLA Piper, a global law firm, operating through various separate and distinct legal entities. For further information, please refer to www.dlapiper.com