Note: Nothing in this post constitutes legal advice or a legal opinion on any aspect of the referenced matter, Ultria, Inc. v. New York Times Company, No. 1:2021-cv-05507 (S.D.N.Y). The matter in question serves only as an example for purposes of discussion. Nothing in this post should be construed as implying a position on the merits of the referenced matter, including but not limited to any actions that either or both parties took or did not take.
I think we can all agree that the lawsuit reported by Legaltech News, filed by Ultria against its customer, The New York Times, is likely unpleasant for all parties involved. Litigation is never pretty and, typically, the last resort in dispute resolution. Many lawsuits ruin significant human relationships, personal and professional, and it may well be the case here. Not fun.
All of this makes me wonder, how could this have been avoided? In disputes between vendors and customers, a customer might take the stance, "if the software just worked as advertised, we would have no issues" -- while the vendor's reply might be along the lines of, "if our customer was just more rational about their customizations, it would all be good...," or something like that. But once things reach litigation, in my experience, the "disagreement" is well beyond those sorts of placid statements.
As far as I know, a simple misalignment in "expectation management" isn't a valid cause of action. Nevertheless, in any project or program, small or big, there are certain expectations created by the provider and internalized by the customer. In a CLM implementation, as in other scenarios, these are reflected in statements of work, project plans, marketing collateral, demos, oral descriptions of functions, deliverables, timelines, etc. Amidst all these communications, however clear, often there is a key step overlooked. This is what I call "affirmative consent."
Affirmative consent, in a business context, is not just a "sign-off." Rather, it is codified in an iterative/agile process, a progression. Ideally, it begins with something like, "This is what I thought I heard you say you wanted -- I get it right?" The next stage is, "OK, now that we have confirmed that I understand what you want, does this (e.g., sample build) reflect your expectations?" From there, one can imagine the next step as, "Thanks for your feedback on the sample build; here is the final version." The next stages might be, "Now that you agree with this final version, let's put it through user acceptance testing (UAT)" and (ideally) "We all agree that the build meets UAT, so let's enter the final deployment phase."
At every junction along the way, there should be simple and clear documentation that demonstrates both parties have acted in good faith on representations and data available to them at the time. Whose responsibility is this? I can't speak to the legal issues, but from a practical standpoint, both the customer and the provider would do well to handle it as something they must do together.
The key point is that misaligned expectations are an invitation to conflict. The antidote is proper documentation of actions and decisions taken/made -- and actions that demonstrate good intentions and good faith.
There's an old saying that when elephants fight, the grass is certain to suffer. With litigation, people on all sides typically bear the cost in the form of distraction, tension, and stress. And, let's face it, these days, daily life is tension-filled enough. So, communicate, be clear, take things one step at a time, and work with your customer or vendor as a partner, not a potential foe.
“alleged problems or deficiencies with the software amounted in reality to a lack of acute customization”