CIOs who have partnered with vendors dismiss the common fear that they give away competitive advantage by allowing their intellectual capital to be built into products that are ultimately marketed to competitors.
Most have some critical internal or customer-facing applications that would never be shared through a vendor partnership, for fear of giving away competitive advantage.
But for back-office and other applications, the lead time they enjoy by being the first to deploy the software provides sufficient advantage.
Also, subsequent improvements in the software, gained from its wider use throughout their industry, provide a long-term benefit.
"There's a lot of talk about competitive edge in specific elements of software, but I actually don't buy into it," DLL's Arculus said. "Because it's what an organization does with the software that's importanthow they use it, not the actual core software.
"We're not really giving anything away to the competition. If a direct competitor picks up exactly the same product, it tends to improve the product to our benefit, as well. The subject is regularly brought up, but it's one that I personally don't have much concern about."
"The more successful the company and the product, the more enriched the product is going to become over time for you," adds John Sroka, CIO of Duane Morris LLP, a 550-lawyer firm based in Philadelphia that has helped a pair of vendors build software that integrates digital dictation and imaging with document management systems tailored to law firms.
But other concerns are bedeviling this growing practice.
Balancing company-specific requirements against the vendor's need to build capabilities that will have broader appeal across an entire industry can be tricky.
So can integrating new custom software with critical existing corporate applications. And serving as both development partner and beta tester typically places more of the quality-control burden on the customer.
"Clearly there's an expanded time of testing that we have to do, versus with an application that's in wider use," acknowledged Gilman of Allen Matkins.
"There's the potential that another product that we use, and that, ideally, we would love to have integrate with the new product, doesn't, because the new product is simply too new.
"There have been times when we've been offered a deal that we'd love to do, and some of our other key products just can't support it, so we can't."
And for every success story a CIO is proud to share, there are likely one or more failed partnerships that no one is talking about.
Particularly troublesome have been partnerships in which customer and vendor have shared ownership of the resulting intellectual property, creating legal and competitive complexities that eventually doomed the deal.
"Over an extended period of time, I can't think of a single one that hasn't been a disaster," says AMR Research's Shepherd. "And it's almost always an overreaching CIO who decides that the software business is more interesting than his business. It's an ego thing. When you look at the business proposition, the money or rights or capabilities that would be available to you, it's not worth the legal fees to negotiate the contract."
Though consultants and lawyers won't identify current clients who've been burned in a vendor partnership, David Whitinger, director of consulting for ICN (International Computer Negotiations Inc.), a Winter Park, Fla., consultancy that advises clients on how to negotiate better deals with vendors, tells of one large, well-known company that paid to have a back-office logistics application custom developed, but failed to negotiate ownership of the software.
The vendor ultimately "productized it," licensing the narrowly focused vertical application to direct competitors of the original customer.
But worse than any competitive advantage lost by sharing the software was the fact that the company ended up having to license the application again when it came time to upgrade.
"They just got into this quagmire of issues because they didn't own the software," Whitinger laments.
"We always recommend that if you pay for it, you own it. If you're going to have custom development, then you should own the rights to that software. You shouldn't accept a license."
Another unnamed ICN client, also a large, household name ("one of the ten most recognized names on the planet," Whitinger says), suffered an opposite but equally unfortunate fate.
Working with a major software developer to help design a complex new application, the corporation put people, time and money into the development, but for whatever reason, the product never came to market.
Not only was it a major waste of resources, it also exposed the customer to potential liability. Cautions Whitinger: "If someone buys the software based on, in part, you participating [in its development] and you recommending it, and it doesn't work or it never goes to market, they can sue you."
This article was originally published on 10-10-2005