Procurement and planning

Cameron Crawford of therightslawyers looks at how IT procurement can be practically managed by a business.

  • E-Mail
By  Cameron Crawford Published  July 19, 2008

The chief consideration when approaching procurement contracts is that of risk management, which is best addressed by effective planning.

Drawing up a comprehensive risk plan and appointing team members to specific responsibilities can be the first step.

From there come the specifics: narrowing down the various requirements of the business to (a) select the right package and (b) enable a full contract governing the terms of procurement to be drafted.

Planning which deliverables will need to be achieved and specifying the functionality of the software and/or hardware in question is a very detail-oriented process, but one which is worth doing thoroughly: if it's not in the contract, it will not necessarily be delivered.

It is certainly best to err on the side of caution and include as many details as possible (whilst keeping within budget), as attempting to expand the brief after the signature of the contract - and while the project is in progress - may lead to further negotiations, which unnecessarily wastes funds and manpower.

While the commercial side is important, there are some more legal issues to consider that may not be instantly obvious: for example, one fundamental issue to consider when beginning the project is whether to acquire the product - especially software - outright (meaning to purchase ownership of all the intellectual property) or to simply purchase a licence (essentially a permission to use hardware or software within specific limits).

The difference in costs between these two options is likely to be substantial: acquisition will ensure that a software product is not made available to competitors and, crucially, that further revenue streams may be opened up by licensing the product to third parties.

However, this will cost more, with maintenance, updating and customer care to be paid for; internal resources to put this into effect will also require specific investment which will only be recouped if the product succeeds.

Licensing is a lower-risk solution, meeting the short-term IT requirements of a business but not providing any additional value to it. A good analogy is that of renting a property rather than buying one: one is faster, easier and less stressful, but ultimately is a pure cost centre rather than representing an investment that may pay off over time.

Another key factor is the source code: is it potentially for sale? Source code access will often need to be guaranteed in the contract as this may be needed to maintain or modify the software.

Crucially, the contract must also ensure that the obligations allowing such a contract will be transferred to the buyer in the event that the source code is sold to a third party.

Without this, the result could be a software package which cannot be fixed when it crashes or updated to meet requirements.

It will also be important to remember what happens in the event of the source code owner's insolvency. The correct approach varies according to each territory's insolvency laws, but provisions retaining the requisite rights will need to be enshrined in the original licence agreement.

Cameron Crawford is a solicitor with therightslawyers.

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code