elemental links

Rosabeth Moss Kanter on the discipline behind "Instant Success"

As I've mentioned numerous times, one of the great things about my job is I get to interact with lots of smart, interesting people and organizations.  But, odds would be that's not always the case.  Once in awhile, I find myself hearing about, or witnessing, a situation and I can't help but be astonished, and not in a good way. 

Inevitably, these situations -- failed projects, bloated budgets, redundant portfolios, spiraling technical debt, sinking delivery rates, flat-lined morale, general stasis -- can be attributed to a lack of discipline (business and/or engineering) augmented by a stunning lack of leadership.  Yes, that sounds harsh, but these are difficult times, and hiding from the truth only makes matters worse. 

Having (perhaps) recently been astonished, Rosabeth Moss Kanter's recent post, Instant Success Takes Time, caught my attention this afternoon.  Not because it describes a radical new management concept, but rather because it's a good, case study backed, call to business basics -- discipline, leadership and hard-work.  [emphasis is mine] 

""Instant success takes time" is one of my favorite sayings. New products, people, or ideas that appear to burst on the scene unheralded and soar to the top quickly have often been preceded by a long period of preparation, rehearsal, and trial-and-error experimentation.

One of the more mundane differences between perpetual winners and long-term losers among businesses, sports teams, and other organizations is that the winners simply work harder. As I learned from case studies and surveys for my book Confidence, winners are more likely to take the time to keep honing skills and testing ideas in preparation for change. That's not too dramatic or glamorous, but it's among the biggest differentiators.

In contrast, teams or organizations headed for losing streaks lurch from tactic to tactic without any apparent long-term direction. They lack discipline, do not always rely on facts before chasing fads, and panic under pressure."

Check out the full post.  Pass along as needed.  I certainly will.

Quick Poll: Economic Downturn & Discipline in IT Business, Engineering

I'm sure it comes as no surprise that lately the bulk of my conversations with IT practitioners and providers center on the economic downturn that started in the U.S. and is now going global.  As I've written previously, the natural reaction in hard times is cost cutting.  But, cost-cutting alone is often problematic in the long-term, as a recent McKinsey article on Managing IT in a down-turn calls out:

"IT capabilities have fostered new sales channels, defined new customer segments, and even helped create new business models. 

These factors make reductions in IT spending more complicated than ever. Simplistic cuts, applied across the board, may endanger critical business priorities from sales support to customer service. That potent message should resonate even among corporate officers anxious to find quick savings. 

CIOs, of course, should continue to make their operations more efficient and to reduce costs, especially in areas that show signs of bloat. Discipline tends to slip during a lengthy upturn in spending such as the one that has occurred in recent years. Reducing pockets of unproductive expenditure will bring savings that help meet corporate cost targets. 

Still, except in the most dire circumstances, turning off technology investments during a downturn is counterproductive. When business picks up, you may lack critical capabilities. Besides, many technology investments can improve profitability in the short to medium term."

So, the wise IT executive should continue to invest, but those investments need to be selective and well-executed.  This brings me to a second conversational theme of late -- software engineering discipline.  At the recent SOA Consortium meeting, one of the findings Jeanne Ross shared was that "the table stakes for SOA success are mature project management and software development practices".  The software engineering theme re-emerged during our 'soapbox derby sessions'.  While respectfully disagreeing on the "how", both Victor Harrison of CSC and Peter Walker of Sun called out the more 'art than science' (my term) mode of the majority of today's software development.   And that to achieve success with any highly distributed, shared software development approach, more (some) rigor is required. 

Yesterday, with these ideas swirling around, I tweeted the following question "does corporate IT gain or abandon discipline/structure in software dev/delivery in tough economic times?"  The responses I received varied from "I hope so, lack of discipline caused this mess" to "the first victim of any time/$$$ pressure is quality". 

All that said, I've created a quick poll to gather additional perspectives on my question "Does your IT organization gain or abandon discipline during an economic downturn"?  The poll answer choices separate IT business discipline and engineering discipline. 

If you would complete the following quick poll, I'd appreciate it.  Feed subscribers, here is the direct link. 

UAL falls victim to GIGO processing at hyper-speed

Interesting piece in the WSJ today about "the computer glitch that cratered UAL's stock yesterday".  Apparently, this was a case of GIGO processing at hyper speed:

"...blame spread to the computers that robotically troll the Web for news stories and execute stock trades automatically.

An old article about UAL's 2002 bankruptcy-court filing resurfaced Monday as an apparently fresh report on Google's news service. Stock in the parent company of United Airlines quickly dropped to $3 a share from nearly $12.50 before the Nasdaq Stock Market halted trading and UAL issued a statement denying any fresh Chapter 11 filing."

The evolving story on the glitch involves web-crawling, search engine optimization (SEO), syndication and complex event processing (CEP):

Web Crawling

"Google traces the appearance of the 2002 article in its search engine to a process that began late last Saturday night. At 10:36 p.m. PDT, Google's "crawler" -- the technology that finds Web pages -- discovered a new link on the Web site of Tribune's South Florida Sun-Sentinel newspaper in a section called "Popular Stories: Business." The article -- which didn't carry a date but was published by the Chicago Tribune in December 2002 -- hadn't appeared there when Google's crawler last visited the page at 10:17 p.m., the company said."

Search Engine Optimization

"Amid serious storms in Florida and on the East Coast, Web surfers checking for news about travel delays may have stumbled onto the old UAL story by mistake, and a small number of fresh hits may have been enough to drive it onto the list. A Tribune spokesman declined to say how many hits the article received but said there was no indication of fraud."

Syndication

"From the Sun-Sentinel site, the article became available through Google News service, accessible if a user searched for keywords like "United Airlines." The article didn't appear in any of the headlines on Google News's home page, but it was picked up and sent via email to people who had created a custom Google News alert about UAL or related topics.

The stock market opened Monday with no drop in UAL shares, but the UAL story began circulating widely via a posting by research firm Income Securities Advisors Inc. that was made available to users of Bloomberg L.P., the financial-news service widely watched on Wall Street. Shortly after a headline from the outdated report flashed across Bloomberg screens at about 10:45 a.m., UAL shares began a precipitous drop. Over the next 15 minutes, before Nasdaq halted trading, they dropped as low as $3."

Complex Event Processing | Algorithmic Trading

"The damage was exacerbated by the growing use on Wall Street of automated programs that trigger stock trades without any human interaction. The so-called algorithmic trading mechanisms, which buy and sell stocks based on news headlines and earnings data, were responsible for roughly a quarter of New York Stock Exchange trades in the last week of August.

Investors said simple human scrutiny would have indicated the UAL story was old, but computerized trading systems don't make such determinations.

"A trader can pull back before proceeding, but some of these less sophisticated [automated trading systems] can't do that," said Bernie McSherry, a senior vice president with New York institutional brokerage Cuttone & Co."

At the end of trading, UAL's stock had regained much of its value, but the loss to traders and market value was still significant:

"UAL's stock price ended Tuesday's session at $10.60, down 2.8% on the day and nearly 13% off Monday's open."

As regular readers know, I'm a big proponent of automation, syndication and event processing -- casting a wide information net to discover opportunities and threats, and reacting accordingly.  So, I'm not posting this to create FUD -- I hate FUD. 

Instead, I am posting this to remind folks that shiny technology alone doesn't guarantee better decisions.  Just faster decisions. 

Good decisions require good data, and for that tried, true and boring concepts like data quality and source checking remain imperative.  Oh, and when something seems too good or bad to be true, add a little human scrutiny.

What does that cheap server really cost?

Kenneth G. Brill, executive director of the Uptime Institute, has an eye opening piece in Forbes on the full cost to purchase, house and run cheap ($2,500) servers.  In his work, Brill aggregates facility related server costs that are typically dispersed across several budgets:

"Data-center building depreciation is often carried separately from data-center mechanical and electrical equipment. Utility bills often go to a centralized energy function. Site operation costs for technicians, security staff, power and cooling equipment maintenance, property taxes and other costs are often split between facilities and IT budgets. Nowhere is the total picture consolidated."

What Brill found is that "Annual facility costs will exceed the cost of a "cheap" server in two years in the best case scenario, or 14 months in the worst."  In other words, "Spending $2,500 on a server really means spending between $8,300 and $15,400 in facility capital to provide the necessary space for housing the server and powering it."

Other interesting data points:

"--Just the electricity required to provide power and cooling will exceed the cost of the server in six years. Utility bills virtually never go to IT, and often don't go to facilities either, which inhibits conservation."

"--For an organization with 5,000 servers, the industry rule of thumb is that up to 30% are technologically obsolete. This means that up to 1,500 servers can just be unplugged with no negative impact on data-center production. The savings: $12 million to $23 million recovered in data-center facility capacity, $700,000 in annual electric savings and 6,000 annual tons of reduced greenhouse gas emissions. These savings result merely by telling the "kids" to turn off the "lights" when they leave the room."

Brill then continues by asking what this turns the lights of habit could mean for companies and the economy -- not to mention the environment:

"If we did this on a broad national scale, do we really need to be building all the new data centers, or could we defer a large portion of this investment into the future? Our companies and economy would be far better off if that money went into new application development instead of bricks and mortar!"

While $15k might seem like small money, Brill concludes with an example of a $22 million blade investment that didn't account for facilities in the purchase decision:

"One company's IT department decided to invest $22 million in blade servers but forgot to inform facilities. The facility investment required to merely plug-in the blades was an unplanned $54 million. An additional unplanned $30 million was required to run the blades over three years. So what appeared to be a $22 million decision was really an enterprise decision of over $106 million."

I've only provided some excerpts here.  I think this article is a "must-read" not just for managers and senior IT executives, but for all IT professionals making server line-item requests.  How can you help shift investment dollars from facilities to the delivery of business capability?

Believe it or not, this is an actual customer service response to 'where is my order' inquiry

My first reaction to a snippet of this customer service response that was forwarded to me was "that's a joke, right?".  Sadly, it's not.  I then received the entire email chain between the customer and this customer service representative.  My favorite part is the caveat on using the proffered store credit.

Though an apology cannot compensate for your disappointment in our company, we do wish to say how very sorry we are that your experiences were so negative; from ordering, to your interaction with our customer service staff. Although our staff is well trained (though this particular agent was quite new) to represent our company, there are circumstances beyond even their expertise. Namely, our web commerce system which takes orders, but does not accurately determine inventory, nor does it correctly and efficiently notify our customers of out of stock or sold out items. Unfortunately, the customer service representatives are not aware of this unless a customer inquires about the delayed shipment of their orders; in turn, leaving them unable to give a satisfactory reason as to why this occurred.

However, I have forwarded your email to [redacted] to be used as a prime example of the effect that this particular defect in our web commerce system is having upon [redacted] valued customers and the staff who serve them, and we should see major improvements over the next few days. I also spoke with [redacted] regarding this matter, and she would like to offer you a $20 in-store credit to be used towards future merchandise if you so choose. It will be credited to your account immediately; however, it can only be accessed by phone order due to the web system being unable to determine available credit.

We sincerely hope that you find our response to your message satisfactory, for you are considered a highly valued customer of [redacted].

It was sent to me as 'a potential lead', but I'm taking a big time pass on this one.