May 29th, 2009

IBM's Devil's Triangle: An enterprise software soap opera

Posted by Michael Krigsman @ 9:24 am

Categories: Government projects, IT Devil's Triangle, IT issues, Politics, Project failures, Uncategorized, Vendor relationships

Tags: IBM DB2, IBM Corp., Paul, Databases, Enterprise Software, Software, Data Management, Michael Krigsman

IBM faces lawsuits and public embarrassment in the Philippines over a failed government project involving the company’s DB2 database product. The situation offers a textbook example of the Devil’s Triangle, and demonstrates the tensions and conflicts that arise between technology vendors, customers, and system integrators.

Background. The Government Service Insurance System (GSIS), a Philippine agency responsible for managing the pensions of government employees, installed DB2 in 2006. By early 2008, the system began showing signs of weakness. Local newspaper, the Philippine Daily Inquirer, describes what happened:

[GSIS chief legal counsel Estrella Elamparo] explained that the software started showing problems in early 2008, particularly in handling voluminous chunks of data.

“IBM upgraded its database system purportedly to enable it to handle unlimited volumes of data,” Elamparo said. “However, the reported upgrade only worsened the problem because instead of fixing the problem, the database began mishandling data and prevented the simultaneous use of data.”

The government threatened lawsuits in response, according to the paper:

Read the rest of this entry »

April 24th, 2009

Twelve large IT failures to remember

Posted by Michael Krigsman @ 3:14 pm

Categories: News roundup, Project failures, Uncategorized

Tags:

IT failures are so common that it’s hard to pick out unique examples worth looking at in closer detail. I usually examine failures that are large, serve as good teaching examples, or demonstrate severe organizational hubris.

Although I question just how useful such lists actually are, their popularity can’t be denied. In that spirit, here’s a top-ten (well, twelve in this case) list from CIO Insight magazine. The related links refer to more in-depth blog posts I’ve written.

1. IBM’s Team for Texas Consolidation. The State of Texas partnered with IBM to consolidate data centers across the state. Service levels have dropped so low that many agencies gave IBM failing ratings and complained it was taking too long to perform routine tasks. What went wrong: Poor project requirements and a lowest-bidder vendor pick. RELATED: Texas gov. intercedes in failing IBM project
2. US 2010 Census Handheld Rollout. The ambitious plan to arm US Census Bureau employees with handheld computers to compile and transmit 2010 census information to headquarters was mostly scrapped after two years of work. What went wrong: Scope creep. RELATED: Billion-dollar IT failure at Census Bureau

Read the rest of this entry »

April 1st, 2009

IT failure contributes to UK bank collapse

Posted by Michael Krigsman @ 12:24 pm

Categories: CIO issues, Governance, IT issues, Project management, Project strategy, Uncategorized

Tags: Software, Bank, Risk, Information Technology, Banking, U.K., Temenos, Temenos Newsletter, Tools & Techniques, Strategy

A failed business strategy involving a large IT blunder contributed to the collapse of Scotland’s largest customer-owned lender, the Dunfermline Building Society. As a result, the Society is writing off a £9.5 million IT loss, despite total profit for the year of only £11 million.

The UK government will pay Nationwide Building Society 1.6 billion pounds ($2.3 billion) in cash to purchase the troubled bank.

The Financial Times reports:

Jim Murphy, Scotland secretary, said the previous management had made “reckless decisions” because of its over-exposure to commercial loans, involvement in the subprime market and unfortunate decisions on technology. Dunfermline was forced to make a £9.5m write-off on last year’s £11m profits because of a failed IT system.

Finextra reports that the company lost focus by attempting to establish a software business selling mortgage-processing systems to other banks:

Read the rest of this entry »

January 9th, 2009

IT failures town hall recording [podcast]

Posted by Michael Krigsman @ 6:18 am

Categories: CIO issues, Cultural issues, IT issues, Project strategy

Tags: Podcast, Town Hall, Information Technology, CRM, Advertising & Promotion, Customer Relationship Management (CRM), Strategy, Enterprise Software, Marketing, Software

Fellow ZDNet blogger and top CRM analyst, Paul Greenberg, and I led a discussion among enterprise technology consumers, vendors, analysts, and consultants on issues that interfere with achieving successful IT. Modeled on the town hall format popularized during the last presidential election, inclement winter weather forced us to cancel the in-person meeting and conduct the discussion via conference call.

• Related: IT failures town hall: Jan 7

The participants were a sophisticated group whose comments and insight were obviously forged in the fires of experience. As the cliché suggests, although failed IT projects are torturous, those who survive do emerge stronger.

The role of culture and collaboration in driving failure emerged as a central theme. Often referred to as lack of alignment between business and IT, the practical meaning reflects both groups’ inability to work cohesively with each other.

IT frequently asserts its own perspective when selecting and implementing projects, while business groups often don’t recognize the constraints and limitations under which IT must operate. Although project management is an easy target when assigning blame, focusing on symptoms rather than underlying cause doesn’t improve success rates.

Read the rest of this entry »

December 29th, 2008

CIO strategy: 10 qualities of IT greatness

Posted by Michael Krigsman @ 9:53 am

Categories: CIO issues, IT issues

Tags: CIO, Information Technology, Successful IT Group, Paul M. Ingevaldson, Strategy, Management, Michael Krigsman

Successful IT groups are resilient, flexible, and highly responsive to organizational business needs. For many CIOs, this goal appears elusive and completely disconnected from the daily grind of servers, users, downtime, and help desks. Despite the difficulty, CIO success depends on connecting the chaotic, often crisis-driven, IT environment to high-level strategic and business priorities that matter to the broader organization.

Linking a tactical IT culture rooted in reaction and response to broader strategic goals is a worthy, if difficult, challenge, which requires understanding the areas of intersection between IT and the business. Despite the obstacles, IT must cross this bridge without disrupting its own operational ability to deliver projects on-time and within budget while still achieving planned scope. To be sure, this balancing act requires careful and delicate choreography!

Paul M. Ingevaldson spent 40 years in IT, most recently as CIO of international retailer, Ace Hardware. His recent column in Computer World caught my attention because it presents ten qualities of IT departments that have successfully bridged the strategic gap.

I spoke with Paul and asked him to explain the list:

Read the rest of this entry »

September 18th, 2008

3 steps to IT preventive maintenance

Posted by Michael Krigsman @ 7:15 am

Categories: CIO issues, IT issues, Project portfolio management

Tags: Project, Information Technology, Roi/Tco, Team Management, Strategy, Finance, Managerial Accounting, Management, Michael Krigsman

As Wall Street struggles and economic markets seesaw, it’s time to perform preventive maintenance on your IT project machine.

Poorly performing projects waste precious budgets, hurt morale, and pull dollars from ROI-producing activities. Follow these steps to ensure that manageable problems don’t become expensive failures:

1. Examine the portfolio

The first step is establishing systematic criteria against which you can evaluate your portfolio. Some examples include:

• Value. Rank your projects on a relative scale of significance to the business. Let’s face it, some projects matter more than others and you identify the most important ones.
• Risk. All things being equal, keep the projects you can finish easily and successfully. Balancing project risk against strategic business value is a critical part of this equation.
• ROI. Determine which projects offer the clearest financial benefits to the organization. Conversely, take a hard look at projects offering murky financial returns that can’t be quantified.

2. Gain consensus to reduce trauma

Natural selection is an important part of ongoing portfolio maintenance. Not all projects are created equal, making periodic reviews both desirable and healthy. That said, many organizations have difficulty stopping any project mid-stream.

Given reluctance to interfere with ongoing projects, it’s important help your team recognize the need for action. To make that process easier, remind colleagues that it’s far better to kill a marginal project today than to face an enormous failure tomorrow.

3. Pull the plug decisively

Having identified the poor project performers and gotten the team to agree, it’s time to pull the plug.

Make your decision, line up whatever support you might need, and then just do it. Be prepared to explain your logic and reasoning to the naysayers but move forward as planned.

——

Let’s face it, killing troubled projects is neither fun nor easy. However, it’s a natural process and key part of preventive maintenance for your IT portfolio.

[Image via MJ Mechanical Services.]

August 19th, 2008

The triple sins that cause IT failure

Posted by Michael Krigsman @ 3:18 pm

Categories: CIO issues, IT issues

Tags: Information Technology, Failure, Bruce F. Webster, Bruce, Team Management, Strategy, Management, Michael Krigsman

Why don’t more organizations recognize potential IT project problems before they escalate into full-blown failures? Bruce F. Webster believes many companies reject good solutions to fix bad projects for three reasons: internal politics, budget, and fear/pride.

Bruce’s column in Baseline describes three sins that make failure almost inevitable in many organizations:

Internal politics. Large internal IT systems…usually involve several different groups, each of which may or may not be all that happy about having to work with some of the others, but are forced to do so for various budgetary, departmental, or business alignment reasons.

Budget. This may seem counter-intuitive, but management often finds it easier and safer to have a project drag on year after year, ultimately costing large sums of money, than to spend a relatively small (but still painful) portion of that amount up front and fix the problems now.

Fear/pride. Fear and pride can be closely related, particularly when the issue is admitting you made a mistake. This is particularly true if a key manager, architect, team leader, or developer has championed or defended a given approach that turns out not to have worked.

Organizational inertia, the decision-making gridlock that arises when conflicting personal agendas and viewpoints prevent team consensus, lies at the heart of many failures.

While experienced CIOs may recognize that politics and fear cause failure, simply wishing the problem away accomplishes nothing. Instead, wise leaders must take active steps to change organizational attitudes toward failure itself. In fact, it can be healthy for companies to prune back their project portfolio periodically, encouraging natural selection to leave only strong projects untouched.

Facing the inevitability of failure, what’s a responsible CIO to do? Aside from seeking new employment, transparency is the best weapon in the fight against corporate inertia. Exposing self-interested agendas to the harsh glare of daylight is the surest way to keep the system honest.

And that, my friends, is precisely what’s needed to improve IT project success.

[Image via http://home.att.net/~s.l.keim/Sermon.htm.]

July 25th, 2008

Did Levi's use failed IT as a 'convenient scapegoat'?

Posted by Michael Krigsman @ 6:16 am

Categories: CIO issues, Financial impact, IT issues, Implementation, Project failures, SAP

Tags: Financial, Implementation, Information Technology, ERP, Levi Strauss, Software Deployment, Francine, Enterprise Resource Planning (ERP), Strategy, Enterprise Software

Levi Strauss recently blamed a substantial drop in quarterly net income on problems related to its ongoing ERP implementation. Following that report, several observers suggested the company used IT failure as an excuse to deflect attention away from deeper and more significant financial challenges.

Last week I wrote:

SAP implementation problems prevented Levi Strauss from fulfilling orders for a week during the second quarter of this year.

These shipping problems, combined with other economic issues, caused the company’s net income to drop 98% relative to the same quarter in 2007. Levi’s most recent 10-Q SEC filing states that negative effects arising from the implementation “constitute a substantial portion of the decrease in the region’s net sales in the second quarter as compared to the prior year.”

Retail industry analyst, Paula Rosenblum, raised general questions about Levi’s financial reporting in a blog comment:

Companies have been blaming poor results on ERP implementations for 20 years. In my years as a CIO, I always found this notion to be a convenient scapegoat for other, deeper corporate issues. My years as an analyst have only deepened that conviction.

Considering this issue in her customer newsletter, Paula added:

How else do we explain how ten apparel manufacturers successfully implement a package, and an eleventh fails to implement the same package, blaming revenue shortfalls on a poor implementation? Perhaps the IT department didn’t gel well with the systems integrators hired to do the implementation. Perhaps the users didn’t document exactly what they did “in the old system.” And maybe even worse, perhaps standard operating procedures had fallen so much into folklore that no one even really knew who did a particular task, and why it was critical to the running of the enterprise. What if all of the above was true? Most likely there were mixed emotions about implementing a new infrastructure anyway.

Having similar suspicions, ZDNet colleague, Dennis Howlett, discussed more specific concerns with me privately and on Accman, his personal blog:

I suspect there is more to this than meets the eye. Levi anticipated ERP issues to the tune of $18 million so you can’t realistically count that because they took sales credit for those advanced shipments - at least that’s my reading of the Q1 10-Q filing. The company was anticipating a decline in revenues anyway from a variety of other factors, including a substantially weakened economy (in its opinion).

I have no doubt there were issues related to the ERP. But assigning so much emphasis when the company had already anticipated an issue is stretching credulity.

Former auditor, Francine McKenna, whom I quoted in the original piece, focused on possible financial controls issues at Levi’s:

Multinationals have long struggled with getting an ERP implementation right in one country on the first go around. When they implement multiple instances in quick succession, they accept the challenge of automating manual processes, adding automated controls to those new processes, and making these new and improved processes conform to the software capabilities and their business objectives. That’s almost impossible to get right the first time.

THE PROJECT FAILURES ANALYSIS

Given the frequency of failed projects, it’s not surprising some companies blame business or financial issues on IT. Large software deployments are complex by their nature, especially when an organization uses the implementation to change and improve business processes while integrating legacy systems. This complexity leads to high project failure rates and creates the opportunity for scapegoating and misdirected blame.

For private companies, the IT blame game is a political maneuver used by an individual or group to push culpability onto others. Public companies may sometimes use IT scapegoating to shift investor attention away from strategic management or financial challenges toward narrow technical issues.

Francine believes companies can mitigate the problem by improving auditor oversight on their large IT deployments:

[C]ompanies constantly make the mistake of thinking that if the consulting firm in charge of the implementation doesn’t consider internal controls as an important part of their implementation, then maybe they don’t have to focus on them to the extent that they should be focused to get them right.

In an interview, I asked Paula how organizations can prevent scapegoating. She believes compensation is the key to ensuring successful IT projects. Her newsletter elaborates:

There’s only one choice. And that’s to tie every single involved party’s compensation to the success of a new implementation. Start with systems selection and drive all the way through to post-implementation support. The business executives, the actual line staff, and the IT group should all have skin in the game. Of course, this requires executive level support. The correct word is “mandate.” But it also requires a coalition on the ground. It requires teamwork and willingness. Willingness doesn’t mean “happiness.” As I said, no one really likes to change.

So what really happened at Levi’s? Although perhaps we’ll never know for sure, Dennis summed up the entire matter nicely: “It is always easier to blame the ERP implementation.”

[Image via crosschurch.org]

April 12th, 2008

Absolutely amazing: Integrator completes ERP project on-time

Posted by Michael Krigsman @ 5:17 pm

Categories: CIO issues, Consulting, IT issues, Implementation, Project management, Project success, SAP, Vendor relationships

Tags: ERP, Consulting, Outsourcing, It Operations, Business Operations, Outsourcing & Subcontracting, Michael Krigsman

CIBER (NYSE: CBR), a system integrator, completed an SAP implementation on-time and within budget. This amazing accomplishment must be extraordinary news because the company released a press release specifically to alert the media.

I interpret the press release as an indictment of CIBER and the entire implementation consulting industry. This business is so failure-centric that success seems an aberration worthy of media attention.

THE PROJECT FAILURES ANALYSIS

The solution to late and over-budget projects is harshly aligning consulting compensation and incentives directly with the interests of the customer. I recommend that enterprise software customers create vendor penalties that kick in when projects are not completed on-time or within budget.

Consulting companies may claim that’s not fair because so many variables lie on the customer and software vendor sides. My response: deal with it by planning more carefully. If you can’t plan a project successfully then get out of the business.

At the same time, IT services customers must learn to be responsible and intelligent consumers. Get multiple bids and don’t rely only on low cost as your selection criteria; as a wise man once said, “buy cheap, get cheap.” Most important to ensuring IT project success is binding services vendors into the agreed-upon schedule and budget; that’s called skin in the game.

For more information on fake promises of trust and consulting compensation, see: Consulting’s dirty little secret.

These are complicated issues, so please leave comments with your views on managing vendor / client technology services relationships.

December 18th, 2007

Colorado decertifies voting machines

Posted by Michael Krigsman @ 7:40 pm

Categories: Government projects, IT issues, Project failures

Tags: Colorado, Audit, Ballot, Financial Accounting, Scanners, Finance, Hardware, Peripherals, Michael Krigsman

Coming quick on the heels of a scathing voting machine report from the Ohio Secretary of State (see Larry Dignan for details), the machines have been decertified for use in parts of Colorado.

According to The Denver Channel:

Secretary of State Mike Coffman cited security or accuracy problems in the decertified machines.

A number of electronic scanners used to count ballots were also decertified, including a type used by Boulder County.

Coffman said the system had a 1 percent error rate when counting ballots. “So for every 100 ballots we tested, we found there was an error with one of those ballots,” Coffman said.

The post-election random audit on which the decertification was based is available for download here. Detailed county-level audit results are available here.

Ohio and Colorado are only the latest states to experience voting machine problems. Rest assured, there are many more voting machine screw-ups and decertifications to come. Folks, this story has hardly begun.