Monday, December 01, 2003 | Six decisions IT people shouldn't make

Extract, courtesy

Six decisions IT people shouldn't make

By John Hogan, News Editor
01 Dec 2003 |

IT professionals don't expect business executives to reboot servers or write lines of code. Conversely, senior managers shouldn't burden IT executives with critical business decisions related to IT.

Collaboration is vital to a successful relationship between IT and the business side of an organization, but there are good reasons for leaving IT out of the final say on some key matters involving IT, said Jeanne Ross, a principal research scientist at the Center for Information Systems Research at MIT's Sloan School of Management.

At a recent Gartner Inc. Web services conference in Baltimore, Ross offered her take on "six decisions that IT shouldn't make." She said that the first three are strategic decisions that involve IT strategy. The second three are executive decisions that revolve around IT implementation and execution. To make her point, Ross used several real-world examples of the good, the bad and the ugly.

1. How much should an organization spend on IT?

This is the basic question that comes up in any discussion about IT, Ross said, and it's one that often gives CIOs and IT managers nightmares. "Clearly, this is not a decision IT wants to make on its own," she said.

It's also a premature question to ask until an organization decides what it hopes to get out of an IT project.

For example, FedEx is only two-thirds the size of rival shipping company UPS, and yet both profess to spend about $1 billion a year on IT. That doesn't mean FedEx spends too much or UPS spends too little, Ross said. It simply means that they have different priorities to achieve different business goals. The former bases its IT decisions around a business model of providing niche services -- at a premium, of course -- to its customers. The latter uses IT to create new business efficiencies that drive down costs.

2. Which business processes should get IT funds?

Once the first question is answered, the challenge becomes how to divvy up the IT budget. Ross said that because many organizations have far more IT projects requests than they could possibly fund, decision gridlock becomes a problem. "What we found is that they end up not making any decisions and going for more than they can handle," she said.

An example is the case of Hershey Foods, which a few years ago tried to simultaneously implement ERP, CRM and supply chain management systems. What the candy giant ended up with was a crisis in which product deliveries were botched for the critical Halloween season.

The lesson here, Ross said, is that senior management needs to step in and decide what the organization's top IT priorities should be. "If we can't do everything, what can we do?" she said.

3. Which IT capabilities need to be company-wide?

It may seem like a great idea to have an IT system span the enterprise, but it's not always a good choice. Ross said. If IT makes this decision on its own, there's no guarantee that the business as a whole will benefit from it.

GTECH, a provider of lottery services to government agencies, has a strong incentive not to make mistake about which IT systems to deploy across the business. Many of its government contracts stipulate that GTECH will pay customers $10,000 for every minute of lottery system downtime.

"That gives them a lot of motivation to spend a lot of money making sure they have no downtime," Ross said. "Most organizations don't have that same motivation."

4. How good do an organization's IT resources need to be?

When Dow Corning deployed an ERP system, business management demanded that there be no downtime. The IT organization said that through disaster-recovery planning and backup systems, that was entirely possibly, but it would cost "an arm and a leg." Armed with that knowledge -- and two arms intact -- management was able to determine how much downtime it could realistically afford without having a negative impact on business operations. The answer? Four hours at a stretch.

5. What security and privacy risks will we accept?

Determining security and privacy risks are similar to determining levels of system reliability. Ross said. In this instance, however, it's a matter of both technology spending as well as expending time and effort to train users on policies and practices.

Last year, Yale University launched a Web site where applicants could enter their Social Security numbers and birth dates to find out whether they were among the lucky 10% to win acceptance. Unfortunately, since high school students often apply to several colleges, Ivy League rival Princeton had much of that data and beat some applicants to the punch. Fireworks graphics and a congratulatory greeting were displayed for only the first time the site was accessed, so some accepted students thought they hadn't made the cut.

The resulting controversy was a privacy nightmare for Yale and an ethical fiasco for Princeton, which suspended an admissions official over the incident.

"This was a case of senior management -- or at least business management -- not being involved in the design of the system and not thinking through, with IT, the privacy and security issues," Ross said.

6. Who should get the blame if an IT initiative fails?

This is perhaps the most important of all six critical IT decisions, Ross said. "Now, of course, the logical scapegoat has been and tends to be IT," she said.

Several years ago, when Patrick Zilvitis became CIO at Gillette, senior management told him that they wanted a PeopleSoft enterprise software system deployed company-wide. Such a deployment would have been difficult at best given the high degree of autonomy that Gillette's business units enjoy, but Zilvitis knew it would have been disastrous without a senior business sponsor. Because he was still in a honeymoon phase as CIO, Zilvitis was able to hold out until one vice president agreed that there was such a critical need for those applications that the VP would shoulder the responsibility. Ultimately, that VP realized that no one from IT would have been able to clear the business hurdles involved in the deployment.

The pain experienced by several companies in dealing with these six questions is a valuable lesson to the next generation of IT and business managers, Ross said.

"None of these decisions could be made without IT input, of course," she said. "IT needs to be there to explain the options, to explain what the technology can and can't, to highlight the costs.

"So IT plays a very important role in all of this, but if business managers don't make these decisions, it really doesn't matter what IT does. Nothing good will come of it."

Friday, November 28, 2003

This talks about how we have turned education into a kids race - where we believe that sooner they start, sooner they finish.... which is not true. I intend to follow David's readings more.

Much Too Early by David Elkind - Education Next - Summer 2001

Sunday, November 02, 2003

Good source of info on Port scans that I saw on my machine.
FAQ: Firewall Forensics (What am I seeing?)

Wednesday, October 29, 2003

Aberdeen Report on SIM
Enterprise Incentive Management: A Market on the Move
Intersting read.
CommentWire by Datamonitor - Indian call centers: cracks begin to show

Job disillusionment is perhaps the most general way to describe the problem facing India's call center workers. According to Manesh Mathew, director of HR consultancy PeopleEquity, "A number of unique factors peculiar to the call center work environment impact the call center professionals and their perception towards their work. These range across a gamut of human issues which include peculiar working hours, working days/holidays determined by geographic considerations, assuming pseudo identities, learning foreign accents, operating in alien business environment, altered social and family life, besides harboring the risk associated with working in a nascent industry."

Thursday, October 09, 2003

McD franchisee in Colo. routing orders through call center

Here's the text:

A McDonald's restaurant operator in Colorado is funneling customers' orders through a telephone call center to improve service speed and accuracy.

Here's how it works: Customers at six McDonald's restaurants in Colorado Springs, Colo., call in their orders on telephones sitting on each table.

The employees at the call center electronically relay the orders, as well as orders made at the drive-through, to the appropriate restaurant's kitchen. The orders appear on a screen in the kitchen, and identify the table or car where the order originated.

Inside the restaurants, McDonald's employees take the orders to the tables and collect payment. Customers at the drive-through pay for their orders and pick them up as they always have.

A seventh McDonald's restaurant, this one in Brainerd, Minn., recently set up the high-speed data line necessary to run its customer orders through the Colorado Springs call center.

Though the call center employs as many as eight workers -- it reaches a peak during busy times -- the system halves the 35 to 40 cents in costs that a restaurant normally incurs to take a customer order at the counter, said Craig Tengler, co-founder and chief marketing officer of Exit 41, an Andover, Mass.-based firm that supplies the system's software.

The call-center workers are trained to urge customers to buy more, so an average order is 10 to 15 cents greater under the new system than an order taken at the counter, Tengler said Wednesday.

Corporate executives in Oak Brook are impressed enough by Colorado Springs franchisee Steve Bigari's idea to expand the call-center test to as many as four additional restaurants by early 2004, said McDonald's spokesman Bill Whitman.

"We see that it has some potential to help reduce customer wait time," Whitman said, declining to release numbers. "It also reduces order time."

Those are magic words to McDonald's, which has consistently ranked at the bottom of customer service surveys and consistently lagged in speed-of-service surveys. CEO Jim Cantalupo, who took over in January, has begun efforts to grade each restaurant's quality and hold the managers accountable.

Bigari could not be reached for comment, but Tengler said Bigari intends to expand the initiative to include cell phones. It's hoped that by early next year, customers will be able to call in orders on their cell phones, with those calls also being routed to the call center, Tengler said.

One possibility is to let a customer hit a number on his cell phone to relay his most frequent order, without having to say anything.

The Colorado Springs restaurants already have set up new drive-through services to speed order times and improve accuracy.

Digital cameras are set up at the drive-throughs to take a photo of each car. The photo is matched to the order that the driver made.

The restaurants also feature new Zoom-throughs.

The Zoom-through drive-throughs have no menu boards, so customers must know what they want. Customers place their order, swipe a credit card, bypass the drive-through line, and pick up their orders at a window separate from the normal drive-through pickup window.

Plans call for a Virtual Zoom-through sometime in the future, in which customers would call in their orders and the payment would be deducted from a prepaid McDonald's card.

The Colorado Springs restaurants also each have an Internet kiosk, and most tables have Internet access hookups.

Separately, McDonald's announced Wednesday it will provide its New York, New Jersey and Connecticut customers with literature and information on how to order their favorite McDonald's food and still stay on a low-fat, low-calorie or low-carbohydrate diet.

The program, to start in January, is part of McDonald's "Real Life Choices" initiative. It is being created in part by nutritionist and wellness coach Pamela Smith.

Self Service stats - Knowledge Management CMP Media

Tuesday, October 07, 2003

New Study Predicts Call Center Spending Will Rise Silicon Valley Biz Ink :: The voice of the valley economy

Wednesday, October 01, 2003

Presentation Tips from one of Microsoft's finest. See "My Way".
Don Box's Spoutlet

Here's the extract:

Everything you know about network protocols applies. How do you know people got it? You need an ACK. What happens if you transmit too much data too fast? Buffer overflow. How do you ensure successful reception in the absence of ACKs? Forward error correction via redundant transmission.

Preparation is a lifestyle. I never rehearse talks - I want to have a genuine experience when I talk and rehearsals always feel contrived. That said, I try to only speak on topics I'm focused on in my daily life, so hopefully I have tons of relevant data in L0 cache. I also try to avoid staying up late the night before - being rested is far more important than any benefits you may get from cramming the night before.

Less is more. This applies on many fronts. Smaller/minimal code examples (preferably coded up on the fly) are preferable to opening up a huge sample app and highlighting 7 lines of code. Less content in PowerPoint is preferable to 200+ word slides (damn that auto-font-downsizing feature). At most, PowerPoint should give you visual cues as to the flow of the talk and give attendees visual reinforcement. A little PowerPoint goes an awfully long way - don't let it ruin your talk.

It's all about attention span management. It's your responsibility to keep attendees focused no matter what. There are countless tricks you can use to snap people back on track. My favorite example was a United Airlines flight back in 2000. The flight attendant decided she wanted people to pay attention to the safety lecture - so out of the loudspeaker came the following:

Your seatbelts are useless [pause] unless they are buckled low and tight across your lap with your belongings stowed…

The entire cabin snapped to attention. It was quite stunning and I now think of that experience every time I fly.

Contrast is your friend. If you normally speak fast, occasionally slow it down. If you've had PPT in the foreground for 15 minutes, Alt-Tab to something else fast. If you've been sitting for 30 minutes - stand up and walk around.

Just the facts ma'am…not! Facts are great. Concepts are much better. Your job is to convey concepts and/or demonstrate techniques - facts are at most a means to an end. Also, don't underestimate the importance of motivation - this is both the "why is this this way" as well as "why should you care."

Selecting text looks like crap using the default settings for Windows. OK, this one may not sound very profound but you have no idea how important it is. By default, Windows displays selected text using white text on a black background. On most projection equipment, this means that when you highlight some text, what you just selected is virtually unreadable (which is the opposite of the effect you were hoping for). To deal with this, I set the selected text colors to black text on a Cyan (light blue) background. That makes selection look much more like running a highlighter over the text.

Tuesday, September 30, 2003

Technolkogy review article chronicling recent trends.

Saturday, September 20, 2003

Call Center Market
Jack Welch says that it always helps to define a market where you have no more than a 10% share. This forces thinking OOTB to new opportunities that you may not be aware of exising.
For call centers, it is instrumental to note the areas that they play in , like:
1. Multichannel interactions
2. Case admnistration software
3. Training and e-learning
4. Workforce optimization
5. Knowledge Management
6. Offshoring

Other attributes include certification, virtual call centers etc.
TBD :; Assessment of the current market size, where we are with respect to this size and projected growth.

Saturday, May 17, 2003

Product Management
Can I ask you a question ? To what degree does a technical background help in product management ?

My perception is - a lot. Product managers are tasked with building plans for the next generation of the product. This means a lot of market and competitive analysis, and many other inputs from customers, partners and other internal subject matter experts(SMEs).

Technical knowledge is not mandatory for this. However, it is immensely helpful while interfacing with your customer for the MRD or BRD that you write - the engineering team. Since they are the audience that makes your "vision" come alive, put yourself in their shoes for a second... what does an engineer want to design something ? How close can you make sure the design meets the requirement ? what is the performance metrics do you want the system to adhere ?

I was in a meeting recently where a product manager carved out his vision for a user interface - resplendent with 3D rendering of a feature, with drag and drop and cubic representations. Think outside the box he said.But there was only one catch - the architecture needed to be on the browser with no code on the client as a basic design limitation. The engg folks admired the vision, encouraged it too. Then they walked out slowly, shaking their head in disbelief.

Answers to these key questions can make or break a product. And failure to understand these critical dimensions really is the loss of the company, and the blame rests on the product manager.