<img alt="dcsimg" id="dcsimg" width="1" height="1" src="//www.qsstats.com/dcs8krshw00000cpvecvkz0uc_4g4q/njs.gif?dcsuri=/index.php/c/a/IT-Management/Projects-Gone-Wrong-234902/2&amp;WT.js=No&amp;WT.tv=10.4.1&amp;dcssip=www.baselinemag.com&amp;WT.qs_dlk=XlEPAxbtSm0bzgDA94ZmtwAAAAA&amp;">

Irking the Workers

By Ericka Chickowski Print this article Print

Big IT projects sometimes go wrong in spectacular ways, with some common themes running through the disaster stories like fault lines.

It is imperative that an organization pay its employees on time and as promised. In today’s environment, IT is a critical partner in making that happen. When IT fails to do so, the whole organization suffers.

Sprint-Nextel Get Static Over Unpaid Commissions

Last December, news trickled in from the District Court of Kansas that a cadre of former and current Sprint-Nextel employees had filed a class action lawsuit against the telecom giant to fight for more than $5 million in sales commissions they say were never paid to them. Though Sprint has so far chosen to fight the suit, it has admitted that it has consistently had problems figuring out how to pay its employees accurately the first time around. The culprit? Creaky back-end systems that were never appropriately integrated when Sprint and Nextel merged in 2005.

Details about the systems themselves are scanty, but what the court documents did disclose was illuminating. According to Sprint, it has spent close to $10 million to fix problems within the computer system governing sales tracking and commission payouts. The company says that it provided underpaid employees a process for fixing pay discrepancies. Therein lies the rub.

The plaintiffs in this case charge that this paperwork-laden process was needlessly complex; it was too difficult and took too long to navigate, they say. This case is a good example of how executive response to end users after an IT snafu can greatly affect the ultimate response to technical problems. Had Sprint made a more comprehensive effort to make its employees whole, minus a lot of red tape, it likely could have avoided the lawsuit.

Lessons Learned: Throwing money at a problem doesn’t always work. Communication and an earnest effort to make users whole after IT failure.

LAUSD Payroll Problems

When the Los Angeles Unified School District announced it was ready to flip the switch on an ambitious, $95 million plan to migrate its payroll systems to SAP, the teachers’ union response was, "Are you sure it’s ready?"

Union leaders asked that the district test the new payroll system while concurrently running the old one in order to ensure a smooth transition. The district, and its consultant Deloitte Consulting, chose to ignore the request. LAUSD and Deloitte said that such testing would be too costly.

Even after a spate of red-flags popped up during the preceding months -- so many that the district CIO resigned in disgust six-months before showtime -- the district pulled the trigger and brought the system live in late January 2007. What followed was a year-long chain reaction of failure that caused teachers to picket, kept payroll clerks from going home on many long nights, and eventually cost the school district an additional $35 million to clean up the mess. Over the course of 2007, some employees were overpaid, others underpaid and some were not paid at all for months on end.

So many things went wrong that it’s hard to pinpoint a single cause for the pain. Among the contributing factors: a failure to scrub data before migration, bugs in the custom code developed by Deloitte to tailor the system to LAUSD needs, and inadequate system training for payroll clerks. All of this was exacerbated by the convoluted and complex contract arrangements with individual teachers and creaky hardware infrastructure tasked with running the payroll platform.

Some believe that what really torpedoed the project, though, was an extreme lack of leadership. The executive the school district brought on to sponsor the implementation program didn’t just lack ERP experience, he had very little knowledge or expertise about any IT systems. Furthermore, when CIO Megan Klee resigned in 2006, the district piled her duties on top of the CFO. Clearly, no one was manning the tiller.

Lessons Learned: Difficult projects require experienced and intuitive leaders to reign in costs and address problems before it’s too late to fix them. Careful testing is a must before going live with any new system.

This article was originally published on 2009-05-15
eWeek eWeek

Have the latest technology news and resources emailed to you everyday.