Have you ever been confronted with a delivery scenario where you recognize that with just a little more effort, staff or resource of some sort, a potentially larger issue could be quickly and efficiently resolved?

It's much more valuable to all concerned to help avoid, or remediate, a problem early and efficiently, rather than try to compensate for the failure after the Project Delivery fails.

Customers may be tempted to focus on ensuring that the Consultant's failures are proven and acknowledged. In the same way Consultants are tempted to demonstrate how missing or inaccurate Customer provided data, along with lax Customer participation (project status reviews, not testing interim deliverables), combined with a series of changes from the initial SOW helped cause the Project delivery problem. In almost every failed Project there are generally plenty of things each party could have done much better, and much sooner, that could have helped prevent or minimize that failure. Neither party wins when they engage in a finger-pointing process; that process alienates the other party and defers any meaningful effort to actually resolve the problem.  If you agree with this requirement for a "win-win" Project philosophy, Contract Remedies can represent an excellent vehicle to accelerate the cure process and by-pass fault assignment and litigation sink holes.

When you choose to construct contract remedies, it requires more work early in the project by both parties in order to: 1) contemplate meaningful contract remedies as you construct the SOW; and 2) more work in careful monitoring of the Project delivery process so you can initiate the cure before the delivery gets too far off track (parties must rely upon following the Project Methodology). It's much easier to get the other party to agree upon appropriate cure measures when they are in a logical planning mode; i.e. before a problem occurs. If you do not bother to make this effort up-front and only introduce the subject after the Project starts to falter, the parties get defensive and try to assign blame rather than provide cooperation in an effort to cure the problem. For example, rather than argue why a Project is 2 weeks behind schedule, it might be more useful to have an additional Consultant and/or Customer resource assigned to help catch up...that is a contract remedy.

When you construct your project SOW ask yourself 2 simple questions: 1.) if something goes wrong with this Project, what most likely would that be; and 2.) how could I correct that issue (presuming the contract is carefully monitored and that issue was spotted early on). Then use that information to construct a meaningful contract remedy.

Most SOWs are built with an expectation things will work as planned, however once that job is completed, review that SOW to spot those areas than it  might be most likely to jump off-track during the delivery process (perhaps it includes coordinating input from multiple parties, etc.); and then target those areas for a Contract Remedy insertion in your final SOW. Documenting the ideal Project delivery expectations is only part of a good SOW: when you use that information to help spot potential trouble spots and then build contingencies in your delivery plan, that extra effort helps both parties. When a contract proactively defines the likely exposure areas, it reflects a thorough understanding of the Project requirements, which sends a positive message about the skill and professionalism of the Consultant, and also instills a level of Customer confidence that helps promote Customer loyalty.

Part 2 of 2
"Acceptance" sounds so simple, so what's the big deal? 
Acceptance is a transformational event in the world of Consulting Service Projects whether you are the Customer or the Consultant. On one side, everything leading up to acceptance is pre-sales (i.e. non-billable), and everything afterwards is post sale (billable),and you have very different legal rights depending upon what side of that line you stand upon. Perhaps the most import of these legal rights is simply the right of the Customer to cancel the order; once a Project is accepted you generally have warranty rights to address defects, but you no longer have the right to terminate the project (In "extremely" limited circumstances, Customers may rescind acceptance). Prior to acceptance, Customers often have certain rights to cancel "with cause" (Consultant has not complied with the Agreement and has not cured the defect) or "without cause", in which case the Customer generally pays for services delivered through date of termination. However,  if acceptance isunfairly delayed Consultants are often forced to try to pay their staff while they continue to deliver Services beyond those services that they expected and budgeted (i.e. free service) to induce the Customer to accept. One of the key issues with any acceptance clause is to place an affirmative duty on the Customer to faithfully proceed with the acceptance process upon delivery completion. If you divide the service delivery into Milestones, it can help manage the risk for both parties. Essentially, one set of deliverables would be defined as Milestone 1, which would need to be accepted before the service delivery continues into Milestone 2; so each milestone would have its own individual acceptance test and most likely the overall project would have a Project-wide Acceptance test at the end to demonstrate the Milestones work together. If the entire Project is lumped into a single large deliverable, that might seem easy when you are getting started but your project will not have the mile markers AKA "milestones" necessary to help keep the service delivery on track and to protect both parties interests. Remember, you are depending upon participation from both parties to make a service delivery project successful; i.e. the other party cannot make up for your lack of timely participation.

It is often said an ounce of prevention is worth a pound of cure. With regards to Acceptance Test Criteria and Planning, that relationship is understated. Acceptance Tests should not be viewed as a trial drive, it is intended to be much more rigorous than a few hours or days meandering through unplanned user testing:

If you have an important Project that you are negotiating, look at the acceptance criteria in the SOW:
  1. Do they adequately define all the critical functionality required;
  2. Is the project divided into a logical sequence of deliverable Milestones;
  3. Does it properly anticipate the volumes anticipated and the specific operational environment;
  4. Does it define exactly what constitutes each Milestone's success; and
  5. Does it provide how much time the Consultant has to cure acceptance test defects.

Part 1 of 2

"Acceptance" sounds so simple, so what's the big deal?

Acceptance is one of the most important terms in any Consulting Services Project.
        ∙ Most payment obligations are triggered by acceptance, so if it's not accepted it's not invoiced and the             Customer does not pay for the Service;
        ∙ The Customer's warranty rights start on the date of acceptance;
        ∙ The Consultant is allowed to recognize revenue upon acceptance;
        ∙ The Consultant does not reassign project personnel until after acceptance.

The acceptance criteria should be clearly defined within the SOW, this will determine what functionality will be tested.  SOWs typically include a very broad range of functionality and it's just not practical to test everything, under every possible circumstance. However, within any business operation certain functionality is essential to a successful operation, and that functionality should be tested against not only average use cases but also extreme demands and peak usage. Flushing all of that detail out is the job of your acceptance test.  Candidly, it is the due diligence  of talking to your staff and the overall effort of going through the process of defining meaningful acceptance criteria that forces a deep and thorough Customer understanding of the required functionality. Every Customer thinks they understand what they require, but until they are forced to define the functionality in the SOW acceptance test criteria, they never finalize those expectations. Consultants are falling into an age old trap of allowing Customers to change scope by deferring this task until later in the Service Delivery Project.

Would you hop in the car and start driving before you knew your  destination? Of course not, and you should follow the same discipline with your SOW relative to Acceptance; Frankly if you attempt to do this those acceptance criteria will change as the project proceeds as the project unfolds, so it becomes impossible to control.  Do not start doing the work, or if you are the Customer allowing the work to commence, until this critical test is properly defined. Whether you are a Consultant delivering the Project, or a Customer crafting the Project, don't assume the SOW will make it obvious what is expected; take the time to clearly state your expectations. When a contract proactively defines the acceptance test, it reflects a thorough understanding of the Project requirements. That preparation sends a positive message about the skills and professionalism of the Consultant, or if you are the Customer, it demonstrates a detailed understanding of the task at hand. The process instills a level of confidence for both parties, which helps establish loyal business relationships; i.e. you are prepared to execute on the project delivery. (See Acceptance Testing, Part 2 next month.)

"I paid you your standard rate as requested... why shouldn't I own all of the IP in the service deliverable?"

IP Ownership sounds like it should be pretty straight forward. The Customer says, I paid for the service, I paid the rate you quoted, so I should own the work. To fully appreciate the Consultant's challenge with the above statement you need to understand two related facts: 1) how IT consulting work is typically performed; and 2) how the US copyright law works.

First, when a consultant provides services they leverage a lot a previous work, while some code is brand new, and certainly the arrangement of the program code changes to make the custom work new, they inevitably use many of the pieces of program code that they used in earlier consulting Projects, so the overall work is never new from the ground up. Compounding this fact is the strong likelihood that Customers often selected their consulting vendor: i) because of their familiarity with the specific  application program package; ii) or maybe because of their subject matter familiarity; iii) perhaps the software application vendor recommended them, or iv) the Consultant did a similar Project for a customer in your same line of business. So the vendor is selected based on this very same familiarity, then they are asked by the customer to do similar tasks and they will be using the same pieces of code, the same application program package, and the requirements of the market/industry are driven by common business issues and regulatory requirements. When you add all that together with the vendor's QA training and experience it will inevitably push them to approach the issue in the same way. As a result of all those factors, the program code that they develop to address that issue will start to look very similar.

Second, under US Copyright law all one party needs to do to create a presumption of copying is to establish: (i) the works are substantially similar in a meaningful way (i.e. not totally copied but meaningful portions work appear the same) ; and (ii) that the party that did the second work had access to the earlier work. Once the Customer demonstrates those two simple facts, the Consultant then must be able to prove that he did not copy, which in practice is an extremely difficult task, particularly if a Consultant specializes in that market segment.

The challenge is that Customer's select their Consultant based upon their prior experience with the application software package and performing similar Projects, yet when they demand exclusive ownership of the work ("Work For Hire"), that creates a presumption under US Copyright law that the Consultant copied that work the next time they do similar Projects for others.

Software Patents are more common than in past years, but unlike Copyright rights that automatically attach upon creation, the author must go through an expensive and protracted claim draft, file and review process. At the end of the Patent claim process, the invention must be viewed as new, useful and unobvious in order for a Patent to issue. As a practical matter, the vast majority of software relies on Copyright, given the cost and procedures associated with pursuing a software patent. Patent protection is just not practical for most software developments, and therefore not the focus of this article.

There are ways to help strike a fair balance where the Customer owns the work, but the Consultant is not burdened with the presumption that they violated the Customer's copyright, however that is beyond the scope of this paper. From a Customer's perspective the contract must balance a Customer's need to utilize experienced and specialized consulting personnel and still receive the competitive advantage they are looking to achieve through the Project investment. From a Consultant's perspective, the contract must achieve all that while still allowing that specialized Consultant to perform independent work in the future. When a contract proactively defines a fair balance, it reflects a thorough understanding of the parties competing needs which sends a positive message about the skill and professionalism of the Consultant. That balance instills a level of Customer confidence that helps promote Customer loyalty.  


Did you ever wonder what the difference is between a Warranty and an SLA?

It's easy to get confused between a SLA and a warranty. A warranty is a UCC special limited right that is activated immediately after you accept a product, unless it is expressly disclaimed. The idea behind this special warranty right is to protect customers with an assurance that the product they purchased works as promised, and works in their environment. Whereas an SLA (service level agreement) does not usually commit to actually getting the product to work, it's more about a level of response and a level of effort based upon the seriousness of the service issue claimed (minor, medium or critical). An SLA usually includes an escalation path, troubleshooting methodology, and sometimes it provides a service credit remedy. If the new product purchased does not work once you install it, an SLA will not cure that problem.

Think of the Lemon Law for new car sales when you think about the warranty. If a product does not work; you have a chance (generally several chances) to get it resolved within a defined period of time. If the problem is still not resolved, you have an opportunity to get your money back. That is a heck of a lot different from saying that if the product doesn't work I will respond in 2 hours and if it's not working within x hours you will get a 5% credit on your next monthly maintenance invoice, that is an SLA. Since most software licenses are moving to a SaaS model, a careful review of the contract language is required to avoid having just an SLA rather than a warranty followed by an SLA (which is my recommended approach).

I encourage you to review your last software license to ensure it includes both a warranty and an SLA. This will assure you: 1.) the product works when you first install it; and 2.) it also includes an ongoing SLA methodology for curing potential defects that may be found months, or even years later. When a license proactively includes both a warranty and an SLA, it sends a positive message about the quality of the product, and instills a level of consumer confidence in the developer. This approach increases sales opportunities and establishes loyal customers who drive repeat business.