Patents

When clients embrace innovation for the wrong reasons

There are various reasons why clients may want to innovate, such as to keep up with the competition or users are demanding it. IT consultant 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!

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

19 comments
cmaritz
cmaritz

Another splendid discussion! Thanks Chip for the 'reasons which are not really reasons' to watch out for. Very helpful. The response on fundamentals was great. Often the basic maths says the change is good, but the finer points of hidden cost and lost opportunity are not considered and then everyone wonders why things are more difficult after the change than before. What rang with me was the point on 'We must do SOMETHING!" Many companies, IT and otherwise, suffer from 'initiativitus', where they just HAVE to be running improvement projects and change initiatives all the time. Otherwise they think they're doing something wrong. Meanwhile it might be wise to just 'leave good enough alone' for a while longer. So, Step 1: Forget the TDP and rather understand the problem first, if there is even a real problem in the first place, and hence whether a change is really needed. Step 2: Now go find the right tool for the job (might very well be the TPD, but at least now you know why, and you didn't just grab the TDP first for it's own sake), and do the due diligence in the selection of solutions, make/buy, budgeting, planning, teams, etc. Step 3: When it's time to roll out, have a back-out plan, no matter how small or harmless the change seems to be (I learnt this the hard way, as they say, experience is the thing you get just after you need it). In fact, if possible devise an 'early warnings of failure' list and watch for these signs once the change has begun. If you see them building up, it might be better just to switch to the back-out plan. Sounds far too easy. Now, I long for the day when we can do these things properly and completely and without the pervasive interference and politics that seems to be in almost every IT department :-) Cheers all, have a good one,

JohnMcGrew
JohnMcGrew

...as I do trying to sell them. Sometimes it's something they saw at a competitor or a trade magazine. My worst enemy often tends to be some "friend" of the client who knows just enough to be dangerous, and has not a clue as to what it costs to develop and run a reliable mission critical application. This reminds me of one of my favorite Dilbert cartoons: http://dilbert.com/fast/1995-11-17/ Always ask what color they want the database. (These days, it seems they usually want "green")

samuelwongch
samuelwongch

Thanks will keep that in mind till i start working :)

reisen55
reisen55

I just departed a datacenter run but an idiot. The middle management and staff was great but the top guy, new, believed that when a NEW product comes out, JUMP TO IT before pre-testing. Symantec BackupExec 12.5 wrecked backups from 54 servers. The earlier version worked great and when you are in RESTORE MODE at 2 in the morning, failure on a backup is not something to be contemplated. WHY DO THAT? Just because it is NEW? If it ain't broke, don't necessarily fix it. I evaluate change and projects on the basis of the above, if it is CRITICAL to do (such as server drive running out of space), THEN do it. I have a medical office with 18 stations, of which about 12 are fairly old (4 years or so) but they are running and meet standards, not causing a whit of problem anywhere so WHY CHANGE! Replacement will occur in the fullness of time (perhaps a year or so more) but meanwhile, their office is running without a glitch or an issue at all. Technicians love to propose change for the sake of change or something new. DON'T DO IT. Respect your client's financial and working parameters first and I also realize I can upgrade something to breaking it totally. Do not be the first EVER to own a new Microsoft product. Do not believe Steve Ballmer either. New versions may cause more problems than older versions. If the older version is great, there is no reason to change. IF support for the older version is being withdrawn, then evaluate that support change on that basis. THEN pre-test your change. ON TESTING: so few actually do this one too. I conduct regular server failure and restoration drills using methods I know work and can restore a failed Windows 2003 server for my clients in 20 minutes flat. Not hours, not using Symantec Server Restore. Not rebuilding accounts. 20 minutes flat and I did it and tested it this Sunday gone by for an account.

john3347
john3347

There are those who see a product then look for a need; and there are those who see a need then look for a product. The former is a very bad reason to embrace innovation, yet probably the most common.

JamesRL
JamesRL

It was IT (my own deparment) that was hooked on TPD, not senior management. One datacentre director I knew was expressely told by his boss that he hadn't seen a compelling business case from them for a SAN, so he could not approve one. The director snuck one in by buying in small pieces on different invoices. Another place I worked had a gang of people who were charged with staying on the edge of technology. They spent way too much time going to MS HQ and seeing demoes of products that never delivered the value. After I left, they were re-org'd and all of them lost their jobs. James

Phantom2487
Phantom2487

Management should never be involved in producing a 'TPD'. As when they do the guys (me) who implement it laugh and send it back up the pipe saying 'WTH MGT!' Then if MGT wishes to implement this plan of epic failure because of complaints about myself having problems with their authority more so their lack of IT knowledge the users loose in the end, more so the employees because their project failed and the joint goes the way of ENRON. There in lies one advantage of IT, even though it is a no-glory business, in the end you know when the firm-company-etc is going to flop, and you will already have your job posted on dice.com months before the pink-slips arrive!

PMPsicle
PMPsicle

The only one I can think of that you forgot was ... "it's perfect and will solve all our problems" Unfortunately, panaceas only exist in the mind of the sick. Glen Ford, PMP http://www.trainingnow.ca

Sterling chip Camden
Sterling chip Camden

I'll have to remember that one. Having a back-out plan is critical. Another good thing to do is to have a plan for leaving some things out. Then do those last if you have time.

thomas_w_bowman
thomas_w_bowman

If an opportunity is apparent that can offer saving by implementing new Technology (or pretty much any change) - a Cost : Benefit Analysis plus Risk Assessment should be prepared and accepted by the Business. Sometimes the Cost : Benefit Analysis is incomplete - example... Of course where I'm working is very focused on budgets (who isn't ?), so the Operations Department decided to drop a product that was used by Application Developers for Quick Reference - saves Operations $36,000/Yr. However it will add (at least) 4 Hours weekly to Application Developers to access the needed references (using Google - not a great plan), there are about 100 developers and we can assume that their cost averages $100/Hr, so 52*4*100*100 = $2,080,000 Annually in decreased productivity (this will not 'appear' as a hard dollar loss, what will happen is development and support will take longer), even assuming that the company might get 80% of the extra time as 'unpaid overtime from Salaried employees', it still would incur real cost of at least $416,000 for the Hourly Developers and Support staff. Applications managers won't think of this, Operations only cares about their area's budget performance...and since Applications is spread over 8-10 'types' of applications, Applications Management won't even know what hit them - it'll appear that 'Project budgets are slightly higher than estimated

Sterling chip Camden
Sterling chip Camden

A colleague asked me the other day, "How can our customers make use of cloud computing?" I replied, "That's the wrong question. The right question is 'Would any of the problems our customers face be better solved through cloud computing?'"

PMPsicle
PMPsicle

One of the problems is TPD affects management processes and thinking as well. I know of a company where the upper management was convinced that the IT department needed an R&D group ("We've got to be constantly Re-engineering! Otherwise we won't be able to compete."). Mind you they also downsized the company because it was the vogue (and because they had one section that had over-hired). Of course, I've also dealt with companies who seem to be convinced that the biggest mistake the company made was to get out of the buggy whip business. Glen Ford, PMP http://www.trainingnow.ca

Sterling chip Camden
Sterling chip Camden

... you may want to get out now, if that's the kind of relationship you have with MGT.

Sterling chip Camden
Sterling chip Camden

In the "it will be a final solution" section. Today's panacea is tomorrow's albatross.

Sterling chip Camden
Sterling chip Camden

I used to work in an R&D department. It was a mixed bag -- we really did drive innovation for the company, but we also wasted a lot of time on stuff that never amounted to anything. As with most things, it's not the theory that's right or wrong -- it's the execution that matters.

PMPsicle
PMPsicle

It's not just that it could turn into an albatross. Using unrealistic expectations as your baseline, sets you up for failure. A perfectly good practise or technology or process (or any other type of innovation) gains a bad reputation and is rejected as a result. As a result, you will reject the use of the tool in precisely the situation where it is of most use. To illustrate with a silly example ... you decide to adopt the newest innovation ... steel nails. They're great, perfect ... easy, quick, one smash with a hammer and they go straight in. So you try them when installing floor boards. Oops, shoulda used screws! Floor squeeks. So you reject using steel nails. Then when you go to install the 1/4 round you go back to that ol' standby -- screws (DO NOT TRY THIS IN REAL LIFE BTW). (Can you tell I'm doing renovations? :^0 ) Glen

alex.kashko
alex.kashko

Like venture capital 9 out of 10 projects go nowhere. The 10th pays for all ten and makes a killing. The venture capitalist puts in money, the R&D people put in time and effort. I think any large organisation needs an R&D department that carries out a mix of internally generated ideas and ideas from management and the rest of the workforce. The trick is getting the budget, right, the balance right and the right people

Sterling chip Camden
Sterling chip Camden

Absolutely, and it applies to software just as well as to your hardware example. Right now I'm facing objections from some developers who refuse to use macros. Why? Because they got so confused once upon a time when trying to figure out what was going on with a particularly complex set of poorly-written macros that they decided "Macros Bad." It's difficult to clearly make the point that every tool has a purpose, but no tool should be used for everything.

Editor's Picks