Innovating for all the wrong reasons

Guest post: There are various reasons why clients may want to innovate, such as to keep up with the competition or users are demanding it. TechRepublic's Chip Camden offers words of wisdom about what to say when clients pursue change for the wrong reasons.
Written by Larry Dignan, Contributor

Guest post: There are various reasons why clients may want to innovate, such as to keep up with the competition or users are demanding it. TechRepublic's Chip Camden offers words of wisdom about what to say when clients pursue change for the wrong reasons.


In response to my previous post, Encourage your IT consulting clients to embrace innovation, I received a few comments about when innovation really isn’t the right path. As with most things in life, the word innovation doesn’t mean just one thing, so we need to be careful about making blanket statements concerning whether it’s beneficial or harmful. For my purposes, I’ll give innovation the loose definition of “leveraging change to your advantage.” Within that scope, innovation is good if you do it right and bad if you do it wrong — by definition.

My good friend and fellow TechRepublic blogger Chad Perrin suggested that I write about when clients pursue change for the wrong reasons. If your client says, “We need to implement TPD” (an abbreviation I just made up to stand for Technology/Process of the Day), you better make sure it isn’t because of any of these motivations.

It’s buzzword compliant. The project manager’s manager read about TPD in an article that painted it as this decade’s revolution in the industry. It will without a doubt be bigger than OOP, AOP, TDD, or any other TLA. Anyone not doing TPD by the end of the year will be left behind, with the dust of obsolescence clinging to their outdated clothing. Historically, all industry fads have been trumpeted with the same enthusiastic injunctions to get on the bandwagon. Early adopters who jumped out in front of that bandwagon were actually run over by it. Even those innovations that have endured for years were implemented badly at first and refined later. Better to back off just a bit from the bleeding edge and see how it shapes up over time.

The competition’s doing it. We should know from our personal lives that “keeping up with the Joneses” never satisfies any real need. In the unreal world of sales and marketing though, any objection is bad — the worst of all is a competitor’s unanswered feature. It becomes an excuse for why the product doesn’t sell, so it morphs into a mandate from upper management: “Give me TPD, and give it to me now!” But who says that the competition knows more than you do about how to solve a given problem? Perhaps you could come up with a better solution that would become an objection to them! Rather than playing catch-up to your client’s competition, you’d do better to help them differentiate themselves instead. Just blindly following the competition isn’t innovating at all — it’s herd mentality.

Users are demanding it. The word has gotten out that TPD is “the way,” so your client’s users are uncomfortable that it isn’t part of their solution.  But users should be more concerned with results than with the technologies or processes involved, as long as you can assure them that your client will be able to respond to their future needs.

It’s a standard. Following standards is often a good thing, but if you really want to mummify a product, make a commitment that it will faithfully implement any standard with 100% compliance. You won’t have time for real innovation, and by the time you’re fully compliant, a new standard will have been developed to keep you busy for another few years. It’s better to take a more reasonable approach: implement the standards that you really need for interoperation or as an answer to the question “which way should we do it?” Never do it just for the sake of following standards.

It will be a final solution. Your client has a nagging problem they’ve been working around for years. They’re finally getting fed up with it to the point where they’re ready to scrap what they have and start over using TPD from the top. They don’t realize that there is never a final solution — every approach has its flaws, especially when implemented for the very first time. Furthermore, they may not understand the full scope of what “doing it over” really means. The existing solution probably includes many features they’ve forgotten about over the years, which they won’t rediscover until they get some user feedback — probably after releasing the new version. Users are notoriously bad about identifying shortcomings in the design until they actually use a product. It’s better to evolve than to reinvent.

We have no choice. The only way your client sees to get the features they need is to implement TPD. Even if they can perceive some opportunity for choice, they’d rather stick to the straight and narrow because it makes them feel safer. But every path is filled with choices, and most choices aren’t right for everyone in every situation. Help your client to see all the options that are available to them. Weigh the pros and cons, and then let them make an informed decision.

We must do something! Whether your client is losing market share, receiving bad press, or just not making as much money as they’d like (and when is that not the case?), they’re likely to feel an urgent need to take action. But sometimes the best thing they can do is to ride out the situation. Trying to rewrite major portions of their application might be just enough of a burden to put them out of business. The better approach might be to wait for the technology to evolve to the point where they can easily use it. It’s often a mixed result, though. It’s usually either “We implemented this too soon — it was way too much work for the benefit, but we learned a lot” or else “it sure would have been nice to have this five years ago, but we did well to let the technology mature first.”

In some cases, these motivators actually lead people to make changes that work out for them in the long run. But when the motivations are not on target, the implementation can often be suboptimal. The right motivation for embracing change is because the innovation solves an important problem in the best way you know how. So instead of asking, “Should we implement TPD?” try “How do we best solve this problem?”

Get weekly consulting tips in your inbox TechRepublic’s IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!

Editorial standards