Computeruser.com
Latest News

Who is to blame?

What’s the connection between a small business that is forced to dump a $100,000 software project and the FBI trashing a project that cost $170 million?

What’s the connection between a small business that is forced to dump a $100,000 software project and the FBI trashing a project that cost $170 million? Oh no, you’re saying: Is this another of those lessons-to-be-learned exercises–and probably a stretch at that? Not exactly. This is about accountability.

The scene is a local coffee shop, almost noon. When Ted (names and references are changed to protect the complicit) and I sat down for a quick lunch, I was expecting a routine update on the life of a hard-working IT administrator in a small company. The company is not big enough to have an IT department, although it is fully computerized and its business depends on its manufacturing software.

After greeting me, Ted quickly dispensed with small talk. “You know anybody who wants to hire an IT jock?” An IT confessional is not a pretty thing. Most failures or transgressions in this business are complicated. This is true of most failed software projects, especially the big ones. By big, I don’t necessarily mean big in scale, projects involving thousands of users and millions of dollars.

It could also be a project that is big for a company–that is, important. If a company has 50 employees and a new piece of software is intended for all of them–well, that’s big. After a pause, he volunteered some background. “It started last fall. We have a couple of large investors. One of them suggested that we consider new manufacturing and process control software–something to give us a competitive advantage. Who can argue with that, right?

“The executive committee delegated the idea to a group of six managers from the manufacturing departments,” he continued. “So far, we had 11 people involved; none has any IT experience. I got called in by this group to present options–in effect, to act as a consultant. That’s cool, it’s their business.” Ted took a sip from his coffee and grinned.

“I’ll bet you can fill in blanks from here. They picked a software package, my third choice, because it was less expensive and the vendor promised to make all necessary tweaks to have it fit our company. Hey, that’s OK; it could work like that. “Of course, it didn’t. The people on the shop floor didn’t get into the act until the software was announced. What they saw made their hair turn white. They were sure they hated it–natural resistance to change in any case. But it was OK because they were being told to do it. ‘Cut the crap and do the thing’ was the general attitude.

“Anyway, we started bringing in the new software–big package, about nine modules, and it required some new hardware, an upgraded network. The idea was a quick turnover, like 24 hours, or a weekend. Oh yeah–two days’ training.” Ted looked at me with another grin, expecting that I’d already seen the punch line.

“Let me guess,” I said, “Some of the software didn’t run. Some of it that did run, did not do what it was supposed to do. In general, the people who needed it the most found it almost unworkable.” “Pretty close,” he laughed, “Only the people who needed it the most were among those who never got the software running. Almost a hundred grand–whoosh!–that’s about two good salaries.” I tried to offer him some perspective: I reminded him that he could be working for the FBI. Imagine, after 9/11 with a national crisis breathing down your neck, you’re tasked with saving your agency’s reputation by updating your hopeless IT infrastructure. Endless reports and committees later, you start on a massive $380 million project called Trilogy to bring in new hardware, networks, and case documentation software. Of course, cases drive the FBI, so we’re talking mission-critical all the way.

Four years later, the hardware part of the project is staggering toward completion, two years late and about $70 million over budget. However, software is AWOL. After much handwringing, congressional meetings, and bad PR, you decide to admit that the $170 million case software project has to be scrapped. Time to start over. Ted stopped eating for a moment. “So whose heads were rolling?” “Well, the FBI churned through five CIOs and nine project managers in less than four years of the project–not a record, but close.”

“Anybody from non-IT upper management?” I shook my head. Ted said that under the circumstances, either they should have taken the personnel search committee out to the parking lot for a nice drubbing, or wondered what was wrong with management and the culture of the FBI that it couldn’t keep (or get) the right IT people.

I said, “IT people are convenient scapegoats.” Ted sighed. “Standard Operating Procedure the world over, I guess. It has a twin: Blame the process, the structure. Common story for major IT snafus, have reports done that blame faulty IT processes and fire a few IT managers. Like me. No mention of the people, usually executives, who set the whole thing in motion, who made some of the most important operative decisions, and who set the tone for the whole thing.” “Sounds like you’re talking from bitter experience.”

“Hey, smart executives know all about this. When it comes to IT projects, they get things going and back off. I’ll bet the FBI brass knew the project was unpopular, just as mine did, but once they commit to it, the last thing they want is to be identified with killing it–that’s a failure on their part.” Ted completed the all-too-typical scenario for me: The project lumbers on, usually until it’s busted the budget, broken the clock, and alienated the employees for years to come.

Much of the time, they get away with it because: 1)It’s tough to punish the big guns; 2) killing a few scapegoats made everybody feel better; 3) there’s always the rationale about burying the dead and moving on. Nobody asks whose bright idea it was in the first place, who made the key decisions, and who was responsible for making the corporate culture change so the project could succeed. I’d been through that myself, a couple of times.

I asked Ted, “So when it comes to big IT projects, where should the accountability be?” He laughed. “If you’re an investor, board member, auditor, SEC official, stock broker, analyst, journalist, or just a lowly employee with your job on the line: If you can’t equate accountability with power, especially decision-making power, then you haven’t got accountability.” I added, “Usually, that amounts to names – real people who made decisions. If you can’t put names to it, you haven’t got accountability.” “Right,” said Ted. We both laughed and finished our lunch.

Leave a comment

seks shop - izolasyon
basic theory test book basic theory test