« Overheard at Our House, Without Context | Main | This Tired Old Man that we Elected King »

October 25, 2006

How Corporations Lose a Lot of Money

I work in IT, at a company currently taking a lot of financial hits. In such a company, you would think that every effort would be bent towards fixing problems that cost a lot of money. You would be right only at the smallest level, closest to the ground. Above that, there are counterveiling priorities that always win out. Here are three examples:

1. When a problem is occurring in a project, and you are responsible for getting it fixed, and you don't know what it is exactly, what do you do? Well, if you are a director, you might choose to look into the problem to see what is going on, and then react. You might also fly a dozen people half way (OK, 35% of the way) around the world on a moment's notice to make sure that you have all the right people in place to fix whatever the problem might be.

Now, if the problem were with a production process, such that your company is losing money in six figures or more every day, the "panic" option is not necessarily a bad one: it can easily pay for itself. But when the problem does not incur such a cost, even in the worst case, it is a lot cheaper to find out the nature of the problem, then send the right one or two people to fix it.

But the counterveiling priority in this case is appearing to your boss (a company executive) as if you are doing everything possible to fix the problem. The appearance of action takes precedence over wise use of resources, particularly money and time.

2. If you have a problem with your software development process, such that most of your projects fail, you can look at this a few ways. The first is that you can realize that it is a process problem, and fix the process. The second is that you can realize that it is a process problem, and actually adhere to the process. The third is that you can realize that it is a process problem, but ignore the process. The fourth is that you can fail to realize that it is a process problem, and just assume that your project teams are stupid at best.

I was in a meeting yesterday where we reviewed why we had gotten into a bad state with a project. The project had delivered code, but was having all kinds of performance and functional problems, and the user community is unhappy. The documentation for the project is so bad that at this point, the architects are throwing up their arms and saying they cannot even review the documentation, because it embeds all kinds of objects from tools they do not have, as well as largely consisting of links to other documents, sometimes documents that don't exist or are not viewable for some reason. (Please note: the documentation in question is the documentation that, if you follow the company's stated process for development, is used by the programmers to code the application.) All along, for over a year, the architects assigned to review the project had been throwing up red flags about performance, functionality, and documentation inadequacy.

At the meeting, it was agreed that the problem was that the project manager kept approving deliverables over the objections of the architects on the grounds that it was necessary to meet schedule deadlines. This led to shortcutting the processes that would have found (indeed, did find) and prevented the problems, delivering a higher-quality application to the users. Now, what to do about it? There are at least two minor enhancements to the application the project delivered to fix a bunch of problems and to prepare for the next major version, and the first of those is expected to start coding any day now, with delivery in November. The next major version is also supposed to start coding any day now, with delivery in March or so.

Since the next major version is basing its coding documents on the flawed documents of the prior version, they are having all kinds of issues. These range from simply having to ignore the documentation and read the code to figure out what's going on, to replacing code wholesale because they don't realize it's there, to being unable to deliver a reviewable coding document. So again, what to do?

Well, unfortunately, the schedule pressure is such that it appears the project is going to be given the go-ahead to code without complete and workable coding documentation. Here, the pressure of time leads to taking shortcuts, which leads to problems, which increases the time pressure because the dates did not have any slack in them for fixing problems. But no one is willing to go to the business and say that we're going to slip dates, because that would look bad. The pressure to meet arbitrary deadlines counterveils the pressure to cut costs, and overwhelms it. Everyone who matters will see the missed deadline now; no one who cares about costs will really notice the long-term costs, since they will be incurred in the future. Looking good to your customer is more important, it seems, than doing a good job for your customer and actually providing for the customer's needs.

3. Let's say you are the CIO, and you have a long-term strategic vision, developed with millions of dollars of consulting time, that you want to use to change the way your company provides itself with IT services. Now, you know as the CIO that such efforts at the top are meaningless: it's only when they are applied throughout the hierarchy that they are felt. To make that happen, there are many, many necessary steps, none of them sufficient by themselves. These include the actual creation of the vision, communication of the vision to all levels, aligning the organization around the vision and measuring to detect change (or lack of change) towards compliance with that vision.

Generally, for this to work, the highest levels under you have to understand and buy into the vision, and their incentives have to be arranged so that they will push the vision to their teams, who will do that downwards and so on until everyone is moving in the same direction. With a large company, this takes notable amounts of time.

Now, the problem with strategic visions of this nature is that they are not self-enforcing. Buzzwords don't help much when you are facing the kind of day-to-day decisions that come up at lower levels of the hierarchy. Counterveiling pressures of schedule and available tools make any strategy difficult to implement in practice. Unless the incentives all point towards the strategy, the cumulative effect of the friction at the ground level overwhelms the higher ideals. How can a project manager, for example, be expected to implement a vision that "integrate[s] emerging technologies" with standardized non-functional requirements to "develop a culture that leans forward", when he is being measured on whether or not next week's release schedule is met? Particularly when non-functional requirements aren't standardized and he has no power to standardize them.

So instead, what ends up happening is that hundreds of architects from around the world are flown in for a week-long conference where the vision is communicated, with the help of numerous artists, novelists and other such aids to capturing the output of the conference in an appealing and very presentation-worthy way, packaged for display to the (always-fawning) technical press. This has virtually no effect on the day-to-day work, because it doesn't address it. The higher-level managers and directors who should be translating this into terms that do make day-to-day sense are being measured on other things, and so that is what they are responding to.

The pressure to look good to the press, and thus to your peers, though, is incredibly strong. Stronger by far, in fact, than the pressure to do the dirty work of rooting out the flaws in execution of your last strategy, and stronger than the pressure to reorganize to execute the new strategy.

In all three cases, which are really just representative of the hundreds of cases that come up over a given year in any large organization, the pressure to look good in some way overwhelms the pressure to do good work and deliver good results. Failing spectacularly is more likely to get you promoted than succeeding quietly and consistently. And it costs money by the bucket loads. On the other hand, it's very hard to figure out where the money is going, so looking good has a payoff, and being fiscally sound doesn't.

It's just that the stockholders aren't well served by that approach.

Posted by jeff at October 25, 2006 5:46 PM

Trackback Pings

TrackBack URL for this entry:
http://www.caerdroia.org/MT/mt-tb.cgi/2364

Comments

Posted by: Dave Schuler at October 27, 2006 10:49 AM

Posted by: Jeff Medcalf at October 27, 2006 8:31 PM