Monday, April 28, 2008

Political correctness is just noise

In signal processing there's a measurement called Signal to Noise Ratio or SNR. A given 'channel' can only carry a limited, finite amount of information during a given time period and will have a particular SNR. Here's a practical example of SNR. Let's say you are talking on a phone to someone with a cellular phone. They're standing on a windy street. Some of what you hear is the wind blowing across the microphone. This is noise. Your voices are the signal. You can talk louder and that may help but as the wind gets louder you will have to start repeating yourselves in order to be understood. It will eventually get to a point, if the wind is strong enough, at which you will not be able to understand anything he/she is saying. As the noise increases, the amount of information that can be conveyed drops.

The same is true of political correctness. Have you ever felt you couldn't speak directly about a problem because if you did people would become offended or angry? In consequence they may dismiss what you're saying because their defensiveness will get in the way of them placing any value on what you're saying. This need to couch uncomfortable realities in niceties is a problem. All of the finessing that goes into our politically correct conversations is noise, preventing the information - that which is valuable - from getting through. This doesn't mean we should dispense with manners or politeness. As Peter Drucker says in his essay, Managing Oneself,
"Manners are the lubricating oil of an organization. It is a law of nature that two moving bodies in contact with each other create friction."

Rudeness or insensitivity are no more justifiable if done in the name of 'honesty'. Let's consider the following two approaches:
"Although it was a sound decision to delay the move on our process improvement effort until some of the uncertainty around our contracts and revenue was sorted out at the time, we really need to reconsider our position on this given the new competitive information we have..."

"We made a mistake in delaying this decision. We're now behind the eight-ball and haven't got the efficiencies we should have. Our bid on the such and such contract failed because we were too expensive, too inefficient. Now that we know this a) we'd better act to fix it and b) we need to challenge our thinking more. We shouldn't have delayed. What other negative outcomes are facing us now because of this inability to make tough decisions we seem to have? How are we going to learn from this?"

The first approach is soft and non-confrontational. No one could possible get offended. No one will feel any urgency to change. The sins of the past/present will be repeated in the future. You can bet on it. The honesty and directness of the second approach lets us see the problems so we can make the changes we need to. It also shows you have confidence in the maturity of your colleagues and that they are capable of confronting and dealing with reality - even if it's unpleasant.

Sunday, April 27, 2008

Why cloud computing is risky

I enjoy Nicholas Carr's blog Roughtype as he addresses a lot of issues IT professional's / vendors are not willing to look at because a) if they did they might have to change and b) if they did they might have to change. He's being doing some writing about cloud computing of late prompting my response to one of his posts. Nicholas believes IT Doesn't Matter. If you haven't heard of his articles and book on this subject you can look it up here.

He discusses the move of IT from a strategic model to a utility model where it is no less important than electricity. Similarly what company gains strategic value today from being hooked up to the power grid?

Here is my response to his blog post:

You say, "When the Amazon system was only used by the Amazon store, in contrast, its diversity factor and capacity utilization were woefully low - a trait it had in common with most private corporate IT operations." I see your point. If we liken IT to a utility model - the more customers you have with demand coming at different hours, different intervals, different volumes - the smoother your demand (I wonder how you translate power factor to IT?). Ultimately with an infinite number of customers spanning the globe your load will be flat, allowing you to right-size your supply vs. oversize to deal with spikes.

Correct me if I'm wrong but this can be achieved at the enterprise level - by consolidating loads from different applications with varying demands on the same physical box (virtualization of memory, cpus, networks, storage). It gets even better if the loads are global and on the same hardware. Of course if you extend this far enough you''ll achieve the same loads and efficiencies as Amazon. Today's virtualization technologies are functional/valuable but still immature. Give them time and the efficiencies will improve. All that to stay I think Enterprises have a way to go before they run out of ways to manage capacity/value better.

The downside of all of this, including all the cloud efforts is the underlying complexity. Not only is Google's hardware investment growing yearly so will the support infrastructure required (people and systems). This leads me to a different point. IT utilities are different from electrical. Electrical are geographically limited while IT is not. You just need to put bigger 'pipes' in and the data could be flowing to servers across the globe versus across the city. Clouds can balance load across a geographically distributed infrastructure. This becomes problematic when you consider that more complex systems have a higher tendency for catastrophic failure. What would happen if half the world's computers shut down at the same time? This will never happen with local computing (except at that location) and is why inefficiency is desirable as it's required for redundancy. Imagine if that power outage that affected parts of Eastern Canada plus the US East Coast a couple of years ago (due to the system's complexity) had affected 1/4 of the planet. Hmmm

Wednesday, April 09, 2008

Massive project failures are really massive leadership failures in disguise

We can now add another colossal IT failure to the list already in the heads of CIOs. ZDNet has an excellent article chronicling the Heathrow Terminal 5 project, a joint British Airways and British Airports Authority £4.3bn ($8.5 billion) effort, of which a reported £175m ($346 million) represents IT systems. Apparently Queen Elizabeth herself gave the opening speech calling it a “a 21st Century gateway to Britain.” I'm sure that in her mind she was not thinking about "canceled flights (54 short-haul in one day), lost baggage, and substantial delays". Hmmm, maybe she should have picked up The Standish Group's Chaos Report first. I doubt BA's CEO was anticipating a 3% one-day share price drop when news of the extensive problems became public. Since I started writing this post (1 1/2 weeks ago) two senior executives, a director of operations and director of customer services have been fired over the T5 problems. I'm surprised the CIO still has a job...maybe they're afraid to fire him until the problems have been fixed.

We know about Nike's runaway i2 supply-chain implementation that resulted in excess inventory imbalances triggering a 20% share price drop and a $100 million quarterly earnings shortfall. It prompted then Nike Chairman Phil Night to ask, "This is what you get for $400 million?" Nicholas Carr, famous - or infamous - for his May 2003 Harvard Business Review article, "IT Doesn't Matter", wrote another article, "Does Not Compute" in the January 22, 2005 Op-Ed section of the New York Times. In it he details a number of high-profile IT failures including the FBI's 170 million dollar virtual paperweight and Ford's supply-chain project - abandoned when it was $200 million over budget.

Here's what I find alarming. We've known the root cause of project failures for some time. A number of really solid project management methodologies, proven to work, have arisen to counter these risks. So what's the problem?

The Challenger disaster was not ultimately a technology failure but was rather caused by broken and dysfunctional lines of communication through the NASA hierarchy.

Management, and I include all involved parties from the CEO and CIO down, continues to ignore best practices time and again or simply fails in their execution. I'm not going to get into iterative development and/or integration nor will I discuss the principal behind detailed (but iterative) analysis nor architectural prototypes. I'm not going to talk about project failure rates and their correlation with total person-years or budget - I'll review these in later posts. The failure is not due lack of data or sufficient guidance in effective implementation methods. Every time you see a project failure like this your are seeing evidence of management failure in the organization. Management who does not deal with employees who aren't equipped with the 'process' tools they need to get their jobs done. Who are not dealing with breakdowns in communication across the company's departments (looks like BA's failures are at least partly due to this). Management who are not hands-on and fully engaged in the project - passing the buck down through the organization instead.

What are the solutions? Make sure departmental responsibilities are not only defined but that there is also accountability. The CEO should be fully engaged in major projects. Deal with non-performers in your organizations. Make sure the project's business case is results-oriented. Once the project is over, compare actual to planned results. In short, senior management needs to create a culture of execution throughout the company that starts with the C-level and flows on down through the departments and project teams.

If you expect people to deliver results and they know it, the one's who you'll want to keep on in your organization are the same ones who will find the right methods to get those results. They're the people who hate to fail. Within a culture of execution they are also the ones who will thrive.