X
Innovation

Sleaze Pretending to be Innovation

I write this blog and see lots of weird stories, many of which I find hard to believe. Today’s topic is a good example, and deals with manipulative behavior justified in the name of innovation.
Written by Michael Krigsman, Contributor
I write this blog and see lots of weird stories, many of which I find hard to believe. Today’s topic is a good example, and deals with manipulative behavior justified in the name of innovation. We all know that innovation involves accepting some level of calculated and anticipated risk. Sometimes, however, nice-sounding ideas like innovation are used to justify and excuse simple, garden variety failure. Along those lines, here’s a quote from TechTarget.com:
[Ed. note: I have removed names from the quote below to avoid causing embarrassment to the source.] “This same principal of not fearing failure should apply earlier in the project management process, too. CIOs should not be afraid to cut their losses with projects on their way to failure. “When I say kill a project, it could be, ‘We’re going to build a portal for the first time,’” [he] said. You fire off a project, do an assessment and pick a product to build it on. And then we find the product isn’t getting it done. I would say more times than not companies will continue to fight with the product and try to work with it.” [He] said on many occasions he has stopped a project, articulated why the product he is using in the project doesn’t work, and then asked a vendor for a full refund. After that, sometimes the project doesn’t need killing. The CIO can start over with a new vendor. [He] said this takes courage, to admit mistakes and the support of corporate counsel.

Let me get this straight. The person being quoted recommends not fearing failure, because innovation depends on it. Alright, I’m cool with that. But then, he recommends breaking a contract and bringing in lawyers if his project doesn’t meet expectations. In my view, that’s a fundamentally irresponsible perspective. Why didn’t the buyer perform due diligence prior to starting the project? When a sophisticated buyer takes on a risky project in the name of innovation, it is wrong to put all blame for failure on the vendor.

I often criticize vendors for their poor behavior toward customers. Now the tables have turned—the quoted article seems to recommend that IT buyers avoid responsibility for their own failed projects, even if the causes of failure lie within their own company.

Dishonesty is wrong, whether it comes from the vendor or the customer.

Editorial standards