One of the most important and fundamental aspects of every IT consulting agreement is also one of the greatest sources of legal misunderstanding and commercial risk for those transactions. Luckily, based on my experience, that all too frequent and formidable source of IT project risk is entirely (yes, completely) within the ability of IT customers to mitigate, if not entirely avoid, if handled well.

Those commercial and legal risks arise directly out of a pervasive, and yet deceptively simple, misunderstanding concerning the important differences between an "advisory" consulting service and a "deliverable" consulting service.¹ The failure to appreciate and take that simple, yet profound, distinction into account lies at the heart of many of the most serious disputes and liabilities that arise in the course of IT consulting projects.

When an IT consulting transaction is structured as an advisory service, the consultant is retained to provide their expert, experienced and professional advice and assistance to the customer in support of a particular endeavour or to even facilitate a particular outcome. Although consulting services may be provided by world leading authorities in their relative fields, such retainers do not promise or guarantee any particular results, benefits or outcomes. All professional services that are advisory in nature must adhere to prescribed (and often onerous) standards of diligence, quality and care, whether those standards arise by contract, statute or the common law. However, the providers of advisory services never assume the risk of a failed outcome or result (except to the extent that such failure is caused or contributed to by the failure to adhere to the prescribed professional service standards) and the consultant will not be responsible for whether or not the customer's desired outcomes or business intentions are realized or achieved.

Common examples of advisory services (in the broadest sense) include: a law firm that is retained to help a corporation acquire another company, or to defend an accused at trial, or to negotiate a complex outstanding transaction; a surgeon who is retained to remove an infected appendix or to diagnose a particular illness; or, an IT consultant who is retained to help guide the customer through the prescribed process of configuring and implementing complex enterprise software. In each case, the service provider does not guarantee a particular outcome, is not promising a cure, is not assuming liability for a failed M&A transaction, and is not agreeing to serve as the customer's insurance policy for the customer's poor business decisions or any mistaken judgments that are undertaken during the course of the service retainer. Contrary to popular perception, there is neither inherently nor necessarily any liability associated with a surgeon's failed operation, misdiagnosis, or even for failing to remove a surgical instrument from a patient after an operation. On the contrary, as long as that surgeon did everything that a reasonably diligent and prudent surgeon should have done in comparable circumstances, then no liability will accrue to the surgeon for the failure of that patient's desired outcome to be realized.² By analogy to such professional duties of care in the medical profession, subject to the consultant's compliance with all applicable duties of care in the performance of the services, the outcomes of IT consulting services that are strictly advisory in nature, will entirely be the customer's risk.

On the other hand, so-called "deliverable" consulting service agreements have (in many ways) much in common with product purchase agreements. In such deliverable transactions, a consultant is retained to provide far more than mere hands-on guidance, assistance and advice by guaranteeing that a specific or particular outcome, result or benefit will be delivered to the customer. By analogy, other deliverable retainers might include: fixing a roof so that it does not leak and will not leak for another 10 years; or, to build the house in complete accordance with the detailed requirements of architectural blueprint, engineering reports, and interior design specifications. In such transactions, the successful performance of a consulting agreement can only be determined by direct correspondence to the precise nature, scope and extent of how well the "deliverable" is defined from the outset. Since those transactions focus on the production of the defined deliverable, the professional quality of the services is irrelevant (and not a factor in any risk or liability assessment) as long as the outcome that is contracted for was delivered in accordance with the contract.

In my experience, it is the failure to contractually respect the clear demarcations in law and commerce between "advisory" and "deliverable" services where customers of IT consulting services most often fail to properly manage their consulting projects and transaction risks. As a fundamental matter of legal (and liability) distinction, the risks of either type of transaction can be managed well within the confines of their extremely different commercial and risk contexts. However, any contractual confusion between (or among) those very divergent risk contexts will very likely lead to a failure to manage the risks of either type of transaction, leaving both the customer and the consultant vulnerably exposed to unintended project risks. Unfortunately, customers who are not in a position (for many reasons) to materialize their otherwise vague or subjective expectations into a well defined and clearly articulated outcome or "deliverable" often mistakenly (and dangerously) want to structure their IT consulting procurement as a "deliverable" rather than more prudently and correctly as an advisory consulting service. In fact, the tendency to force an IT consultant into service obligations that appear to require "deliverable" obligations without being able to clearly define all of the requisite requirements and necessary attributes of such transactions, often creates many more project risks and transactional liabilities than customers appreciate or realize – hence the recommendation in the above title that customers need to be very careful of what they ask for.

To properly manage the risks of "advisory" consulting services, customers should strictly focus on the following important contractual provisions:³

1. clearly stipulate the nature, scope and quality of the professional standards of care that must be exercised by the consultant;
2. stipulate quality assurance obligations and protocols to promote service excellence;
3. stipulate all applicable personnel/consultant qualifications, experience, security clearance, training, and other relevant attributes;
4. mitigate against personnel transfers to promote service consistency and continuity of project knowledge and experience;
5. ensure there are frequent reviews of services quality performance, especially concerning project progress;
6. include provisions that promote consultant customer communications, including stipulations related to timely customer decisions, determinations and instructions to the consultant; and,
7. include an express disclaimer and denial of any representation, warranty, covenant or guaranteed outcome, result, or that any particular solution will be fit for a particular purpose.

For customers who wish to properly manage the risks of "deliverable" consulting services, then those customers should focus on the following contractual provisions:⁴

1. (this is the golden rule…) the less completely, accurately and clearly the deliverable is defined, the greater the risk will be of project failure.⁵ If the customer is not in a position to define the deliverable thoroughly and clearly, then that customer is not (in the customer's own best interests) in to enter into a deliverable consulting agreement – although that customer may be in an excellent position to retain a consultant to provide advisory assistance to help define the deliverable that the customer will require for a future "deliverable" transaction;
2. provide deliverable development/delivery milestones, which are perhaps (but not always) tied to fee payment thresholds;
3. ensure there is deliverable (in part or whole) acceptance testing based on the empirical qualities of the contractual definition;
4. explicitly set out all of the customer's material decisions, contributions, determinations and governance duties upon which the creation of the deliverables depend and rely;
5. deliverable change management provisions must be included to deal with requested amendments to the contracted definition of guaranteed outcome;
6. stipulate all related services that are associated with the delivery, implementation or use of the deliverable, such as training, maintenance and support, integration with other IT, or associated advisory advice; and,
7. even though the deliverable must be well defined, it is reasonable and customary to include pre-conditions, exclusions, assumptions, and prerequisites upon which the production and delivery of the defined outcome materially depends. However, as noted below, such service performance "hedging" can never be a substitute for properly and thoroughly defining the outcome that the customer requires the consultant to promise.

As noted above, the real danger for IT consulting projects will arise, and associated risks greatly exacerbated, when a customer (who is not in a position to provide all of the empirical specifications, requirements, or specifications for the desired outcome that they want), requires the IT consultant to enter into a deliverable transaction and (therefore) assume the risk for the failed production of an undefined deliverable. Since the most fundamental risks of a deliverable project are that the required "deliverable" will either be not produced, will exceed the agreed upon budget, or will become irrelevant due to project delays, it is absolutely essential to completely, accurately and clearly define the "deliverable" in empirical terms. Unless that is first done, the customer's risks associated with "getting what it has paid for" (value for money); knowing what decisions a customer must make throughout the services; the required personnel and professional expertise; the price of the deliverable; how long it will take to produce the deliverable; and, what deliverable changes or compromises may be required during the service term, are going to be beyond each party's operational management or control.

To focus on one of the examples referred to above, consulting services to assist with the configuration and implementation of complex enterprise software into an operational solution that will ultimately satisfy a customer's business and technical requirements can be structured in either one of two ways to prudently and properly minimize IT project risk: either as an advisory service; or, as a deliverable service. In my experience, customers who dare to confuse that essential legal and commercial distinction by trying to push the square peg of an undefined ERP outcome into the round hole of a deliverable transaction are inviting exorbitant IT project risk. Attempts by customers to deviate from those fundamental legal and commercial structures by forging a middle ground of risk allocation by artificially propping up an undefined deliverable outcome with a litany of contractual assumptions, preconditions, exclusions and qualifications to the (otherwise) promised delivery of such unknown (or as yet undetermined) deliverables is a highly dangerous risk game for both the customer and the consultant. That approach absolutely fails to address (if not ignore) the most serious and fundamental root origin of transactional risk in that circumstance – the failure to comprehensively and clearly define the outcome that the customer is insisting that the consultant deliver. Essentially, such a patchwork approach to risk management dangerously relies on the untenable and uncertain correspondence between the consultant's delineated service performance hedging (assumptions, pre-conditions and qualifications) and the nature of the customer's unmet (and uncertain) outcome expectations – and the less those correspond, the closer both parties will be to the very centre of a liability bulls eye.

Instead of untenable and ineffective attempts to manage risk by ignoring the root cause of project failure when the outcome deliverable is not yet known or defined, there are two rapidly developing best practices for IT consulting risk management that will greatly promote the success of a customer's IT project:

• First, customers are now better understanding and appreciating the (increasingly) obvious risks of entering into so-called deliverable IT consulting transactions before they are ready to do so, i.e. when they are unable to clearly, completely and contractually define the outcome that is required in empirical terms – whether in business, operational, technical or other terms. That means that more effort, time and expense is increasingly being devoted to the planning, preparation and readiness of such deliverable transactions – mostly to ensure that deliverable contracts (with all due allocation of risk and liability) can be entered into.
• Second, IT consultants are more aggressively helping their customers understand and appreciate that such profound project risks can be greatly mitigated, if not avoided, by first providing their customers with the advisory and consultative assistance and guidance their customers require to thoroughly and clearly define the precise results and outcomes they seek, in contractual, empirical and commercial (time, expense, and innovative) terms. Customers may not appreciate what they don't know about all of their desired outcome options, possibilities or pitfalls at the outset of an IT project, and such advisory consultative services can be focused on optimally defining an "outcome oriented" IT project to drastically lower the risk profile of those projects when commenced.

Indeed, customers must be very careful what they ask for and demand of their IT consultants. If it is industry advice and consultative guidance that they require, then erroneously structuring those services as an "outcome guarantee" will rarely leave IT customer satisfied. If the IT consulting service is, in fact, best designed to deliver a particular outcome, then the IT customer must ensure that such deliverable is very clearly, completely and empirically defined, and subject to all of the contractual protections and stipulations addressed above.

Notes

1. To a great extent, many of the risk management issues identified and discussed in this Update concerning consulting services are common to many other IT service contracts. However, in the interest of clarity and illustration, I have decided to focus herein on only IT consulting agreements.
2. A surgeon owes a patient the duty to adhere to the standard of practice in his area of specialty. With regard to the example cited above, in a hospital setting that requires a surgeon to adhere to the policies and procedures set out for the performance of surgery such as a sponge and instrument count at the end of the surgery. It is the hospital's responsibility to have a policy in place that sets out the requirement to perform a sponge and instrument count prior to the onset and at the conclusion of abdominal surgery. The surgeon is entitled, in law , to rely on the advice of hospital personnel regarding if the count is correct or incorrect. If hospital personnel determine that a sponge(s) or instrument(s) (foreign body) is missing and so advises the surgeon, the duty of care requires the surgeon to take the necessary steps to ascertain if the foreign body has been left in situ. The standard of care would require the surgeon to visually check the operative field to determine if he can visualize the foreign body. If nothing is found, the surgeon would be expected to order investigations such as an x-ray to confirm that the field is clear. A note should appear in the surgeon's operative report as well as a note by hospital personnel on the count sheet that the count post op did not match the count pre operatively and what investigations were undertaken or planned to determine that nothing was left in situ.
3. This is not intended to be an exhaustive list of risk management strategies for advisory consulting services, but merely a representative delineation of several "best practice" approaches for consideration.
4. This is not intended to be an exhaustive list of risk management strategies for deliverable consulting services, but merely a representative delineation of several "best practice" approaches for consideration.
5. This is true for many reasons, including: reduced vendor agreement for deliverable outside their ability; better pricing; better time expectations; empirical (rather than subjective) assessment criteria; evidence of definition misunderstandings; etc.
6. Parties should not confuse advisory consulting agreements to assist the customer reaching the customer's desired, expected or intended outcome as "deliverable" contracts – they are not. Surgeons and lawyers always assist their patients and clients toward an outcome that is desired by the patient or client – but such services are never provided on a "deliverable" basis where the surgeon and the lawyer agree to assume the risk of the patient/client outcome regardless of the professional quality of their services.