Top ten tips for controlling IT Procurement

Riskmonkey audited a procurement project last week. Unfortunately, things hadn't gone very well - the system met the specification but just wasn't welcomed by the IT department, which refused to support it. Here are ten things they could have done differently to avoid the problem and make the IT procurement exercise a success - are they in your audit programme?

1.    Define the non-functional requirements, as well as the functional ones.

What systems does it need to be compatible with? What organisational policies must it comply with? There's no point buying a system that requires SQL Server 2008 when IT are only using 2003- or even worse, buying Microsoft when your organisation runs Linux. You don't want a system that enforces six-character passwords when your Information security policy requires 8 characters. Databases may be all the same to marketing, but they are not in IT.

2.    Identify how it will be managed, not just who will set it up.

IT weren't happy to be told they would have to manage access rights for hundreds of users of an application that wouldn't integrate with Microsoft's Active Directory, which they used for network and application authentication. in the end, an expensive third party utility has to be procured to sync the two sets of permissions. Easily avoided by explaining up front who will have to manage access rights, do the backups, maintain user profiles, undertake upgrades - and of course manage the operational aspects of the application. Then involve them in the project, and wait for them to say 'hold on a minute, we're not doing that....'

3.    Involve people from the start

So you need a new HR database. That doesn't mean HR should go and buy it then pass IT the disk. It means HR need to consult with key operational departments they will be reliant on - IT Technical Services, Information Security, Datacente Operations - as well as legal services, compliance, and even perhaps audit. That way you can get everyone's requirements up front and eliminate solutions that don't meet requirements. If nothing then fits the bill, it's time to rethink - but better to know now than later.

4.    Establish and communicate technical guidelines

You can't expect operational departments to comply with policies and guidance that don't exist. Do you have clear, established policies and guidelines for IT roll-outs? Most systems involve - at a minimum - an application and a database. This means that all network, system, database and application risks and policies are relevant. Do you have a standard configuration for operating systems or databases? Do you have security standards that prohibit the use of certain Windows services - if so; does the proposed solution use them? Does the application need to be run from a system admin account, or have a large number of stored procedures that need the public role? Do your standards allow this? There may be good reasons why not. Best to get this clear up front - for example, with a questionnaire to be filled in by the supplier or by the procuring department in conjunction with IT.

5.    Get the support right

Who is going to configure the solution? Who will support it? If this is in-house, do you have the skills and the time, and does the supporting department understand it's role and the commitment that entails. What happens when something goes wrong? How often are upgrades, and how involved is the upgrade process? How much testing will be required? If you're getting support from the third party will they need access to your network and systems? How will this be controlled and managed? How will you monitor access and restrict access to other systems? Are you confident the third party has the skills and the resource, and do you have a contract - including data protection and confidentiality?

6.    Think about the data

Who will have access to your data? What data is involved? Think about whether you will need to supply data to a third party for testing or installation, or whether they will be on-site (which can pose its own risks - such as visitor access to data centres). How does the solution ensure data integrity, how can data be backed up, retrieved, and shared with other systems? Is the format open or proprietary? Getting it wrong can impose big costs down the road.

7.    Right to audit

In many cases, the third party will be providing an outsourced process or storing and processing data on your behalf. Do you have a right to audit their operations and visit their site to check their operating procedures, processes and controls? Who will do this, and do you have the time and resource? If not, are you prepared to take the risk that they may let you - and your customers - down?

8.    Location

Is the supplier local? If they are abroad and processing your data, in Europe you will need to make sure this is reflected in your DPA registration or equivalent. Does it affect your customer contracts? Are there political or economic risks that would not normally apply. Do you understand the legal risks - and are your lawyers qualified to comment on and understand the implications of the contract?

9.    Lifetime cost and sustainability

Buying it costs £70,000. The procurement project is 54 days, which you've added up to £13,500. The hardware is £14,000. The cost is NOT £95,500 - it's much more. Have you considered the cost of the additional network bandwidth, data centre capacity, management time, administration time, audit resource, security costs, user management, upgrades, ongoing license fees, and support? How long do you expect the solution to last, and is that realistic - when do you need to budget for replacement? Will the supplier still be there in five or ten years time. If it's based on obsolete technology, will people still understand the code it's based on a decade from now - remember the year 2000 problem, which only came about because systems operated longer than expected. Then remember the life of an average web site of application is under three years. Are your expectations reasonable and prudent?

10.    Understand the risks

It sounds obvious, but whilst you may do risk assessments for corporate projects, do you do risk assessments for suppliers and procurement exercises? Do you monitor critical suppliers and have a reserve if they let you down?