All Posts in Leadership

|In: Leadership|Last Updated:

Long-time reader William Yohman points out a non-technical pitfall common to many end-user-developed IT applications:

“I developed dozens of applications, templates and procedures that were ‘the next best thing.’ I then trained the other users in my work center on their use (and how it would save them time) only to find out the momentum died when I left. These are intelligent, highly technical people who chose to go back to their previous frustration instead of continuing to use a product that was easy to use and saved them time. Why? Because no matter how good or how easy it was, it was easier to go back to the way they had done it a thousands times before. The reality is that ‘organizational memory’ only lasts until the alpha geek leaves the work center.”

Many end-user-developed applications fade away once their developer departs, no matter how good or useful they are. One reason is the difference between grassroots programming efforts and full-blown projects. The latter include training and business change management tasks that make sure the new system is institutionalized. They include establishment of a business sponsor who owns the change and is accountable for its success. And, when the new system comes in, the company “burns the boats” as it were — there is no way to go back to the old way of doing things.

Successful projects, that is, give end-users leadership, support, and an absence of alternatives.

With an end-user-developed application, all they get is support, and once the developer moves on, that’s gone too. There’s nobody to make additional modifications, answer questions, or help ensure that those using the application do so as intended instead of developing workarounds that pollute the data. Unless IT agrees to take on the job of support, use of the application grinds to a halt.

This isn’t necessarily a bad thing. Some of these applications are more conveniences than essential tools. They make life easier for awhile, but in the end the inconvenience of maintaining them outweighs their benefit.

Interestingly, the opposite can happen as well. As several readers have related, IT can develop a professionally engineered replacement for an “Access tangle” only to find that end-users refuse to abandon the application they’re familiar with, regardless of its limitations and inconveniences.

Sometimes, even well-accepted grassroots applications die; other times they stubbornly live on, even when IT provides superior replacements. What’s to do, other than shrug our shoulders and ponder the unpredictability of our fellow human beings?

Plenty.

First of all, whenever you’re responsible for implementing a new system, make sure to find out what home-grown applications are currently in use. Learn everything you can about them, and in particular, find out who their authors are.

Add those authors to your project team, either as full participants, or at least as subject-matter experts. Doing so will have two salutary effects. The first: By definition the authors are influential in the end-user community, so making them champions for the new system will increase acceptance. Second: By definition as well, the authors understand how to design a system end-users will embrace. Having them on the team (and paying attention to their ideas) will improve the design.

There’s one more benefit to including these folks on your project team. When the project is finished and the new system is in production, it’s just as important to turn off the home-grown applications it replaces as it is to decommission any large legacy applications the new system subsumes. The legacy systems, of course, are within the project team’s jurisdiction, so unplugging them is just another set of tasks on the project plan (“just” being a relative term, of course).

The home-grown ones are another story. If the project team shuts them down it might be considered an intrusion. If, on the other hand, the authors shut them down, it’s a powerful message to the end-users that the replacement system really is a better alternative.

Who better to burn the boats after all, than the shipwright who made them?

Comments

|In: Leadership|Last Updated:

In the end, there are only two places you can create new business value in corporate America: You can increase profitable revenue, or you can decrease unproductive costs. Everything else — product quality, process throughput, customer satisfaction, is a discussion about methods.

Given a choice, revenue growth is more desirable than cost reduction for reasons that are, I hope, too obvious to require enumeration. So here’s my question: If this is so, why is the preponderance of IT investment devoted to the latter?

The answer is easy: Revenue is riskier.

For a cost-reduction project, the only significant risks are faulty design and failure to complete the project. If the planned business change is well-considered and delivered, cost reduction is guaranteed, since the entire scope of the effort is within the control of the business.

Revenue enhancement projects, in contrast, call for changes in customer behavior. In particular, you need them to buy more of your products and services, more expensive products and services, or both. Your business’s influence over the behavior of its customers is limited under the best of circumstances.

But wait! It’s even worse!

It’s pretty easy to demonstrate the connection between a cost-cutting effort and actual cost reductions. One way or another it isn’t all that hard for companies to measure process costs, so when you change a business process you can tell whether overhead and unit production costs increase or decrease. As there aren’t very many extraneous factors to take into account, you can be confident improvements came from the change in process and technology.

Revenue? Except for direct-response marketing, companies can’t even evaluate the effectiveness of advertising campaigns. Don’t believe me? Imagine you’re in charge of General Motors for a moment, trying to resurrect the Cadillac brand. It isn’t going well. (Everyone who’s in the market for a Lexus or Mercedes, or who just salivates when one comes into view … spent much time drooling over Cadillacs lately?)

Is the problem bad advertising? Maybe. Or, it could be the styling. Or the comfort, drivability, and performance. Possibly, consumers just have long memories, recall just how bad their last Cadillac was, and see no reason to give GM another chance.

Who knows? It could be that half the product line consists of SUVs, inconsistent with a luxury car image in consumers’ minds. Or, it could even be simple irritation over GM’s decision to call one model “Escalade.”

It’s even possible that the problem begins with your biggest competitive differentiator, OnStar, which mostly helps owners when their Cadillacs break down. (If you were GM, wouldn’t you be busy marketing OnStar to owners of every other car brand? What a great campaign that would be: “You own a Ford? You’ll probably need this!”)

Yes, customer surveys can answer each individual question. They can’t, however, determine whether the advertising campaign itself yielded useful results.

So. You’re in charge of General Motors, and you have two major capital proposals in front of you. One is to implement a customer relationship management program focused on Cadillac owners. Its goal: To reduce the customer defection rate, while supporting direct marketing efforts through better customer segmentation. How much improvement will it drive? There’s no way to predict, of course.

The other proposal is for a supply-chain optimization program that will reduce the total cost of parts and raw materials by 10%. How sure is the 10% claim? Since half the benefit comes from reduced carrying costs on inventory, it’s a very safe forecast.

It’s your company and your bonus. Which proposal do you approve, assuming you only have the budget for one of them?

Is there any question at all? Which is why revenue so often takes a backseat to cost in large corporations. Revenue requires courage, an appetite for risk, and to a certain extent a willingness to take things on faith. All that’s needed to cut costs is an implement with a sharp edge to it. So when times get tight, cost-containment always trumps revenue enhancement. That’s too bad, because no matter how much you cut costs, eventually a lack of revenue will kill you.

You don’t, of course, run GM. You run an IT organization. This is all very interesting, but how does it affect you? Lots of ways, unless you think company strategy is something that happens to you rather than with you. For example:

Chances are pretty good the CEO will ask your opinion as to whether your company should invest in CRM, assuming you haven’t had this conversation already. How should you respond?

You could say, “Industry statistics show disconcertingly low success rates for CRM projects. In my judgment we’d be better off investing in cost-reduction programs like supply-chain optimization and internal process re-engineering.”

Or, you could say, “CRM is risky for the same reason all revenue-enhancement efforts are risky. Even worse, we’ll never really know for sure whether we’ve succeeded or not. Still, we need to fix revenue and this is the right way to start.”

Which is the right response?

How should I know? It’s your company, after all, and in business there are no one-size-fits-all answers.

I just know it’s a tough question.

Comments