IT Projects: Expert Witness, CIO, In-House Counsel & Litigation Forum

New Legal Finding Against SAP: 'Guilty by Reason of Customization

"If it walks like a duck and quacks like a duck..."
The Wisconsin Supreme Court ruling of July 11, 2008 discussed here in Byron's blog brought this old adage to mind.  My analogy to the packaged software issue  being something like the fabled ugly duckling that turned into the beautiful swan.  The swan's beauty and appeal required time for the "add ons" of its growth and maturity, while from the get-go, a duck is a functioning package, including flying as well as swimming, albeit not offering the aesthetics of a swan.  What, if any, import could this ruling have in litigation involving  failed software projects?  Any  thoughts?
Marlene Palmer, Consultant, WSR Consulting Group LLC

http://www.itbusinessedge.com/blogs/den/?p=132
Posted by  Dennis Byron on August 4, 2008

In the dog days of August here on Cape Cod, it’s harder to find something to write about regarding enterprise software on a daily basis than it is to actually write it. It’s summertime and the living is easy, blah blah blah. But not for bloggers.

My choices looked pretty bleak this morning as I scoured the Web for news over the last few weeks while I was on vacation. Let’s see: Write my umpteenth post about enterprise software being too expensive? Is enterprise software good or bad for open source? Or I could write that enterprise software is doomed by software as a service!

And then this story from Wisconsin popped up and hit me across the forehead with all the subtlety of a two-by-four at a stick-ball game.

The Draft Expert Report—Caught In The Tug of War Between Full Disclosure and The Work Product Doctrine

Below is an interesting piece taken from the articles posted on  http://www.hgexperts.com/article.asp?id=4778.  I have found http://www.hgexperts.com/ in general to be a well researched and reliable source of information in the past?  This article covers important material. Have any of our readers hsd to test this or some other theory in their court cases? please tell us what happened and the result.   Thanks.   Warren

There is a split in authority in the federal courts regarding the discoverability of attorney work product provided by counsel to his or her expert and in particular, the discoverability of draft expert reports. Most jurisdictions have ruled that the 1993 amendment to the Federal Rules of Civil Procedure makes it clear that any materials provided by counsel to a testifying expert is discoverable, including information contained in draft reports.

INTRODUCTION
The retention of an expert, the formation of his or her expert opinion, and the creation of his or her expert report are all part of an overall process that should be carefully planned and monitored. In this overall process, a particularly important issue is the treatment of draft expert reports. Often, these reports contain indications of core attorney work product. Core attorney work product may include the legal counsel’s legal strategies, mental impressions, and case conclusions.

By James J. O’Sullivan, J.D., CPA, and Richard T. Cordano, Esq.
Provided by Willamette Management Associates

Working With an Expert Witness: The Seven Deadly Sins

This post presents Gabrielle Bonne's, Law.com article from April 12, 2006, on what lawyers do (or shouldn't do) to get the most and bests from their expert witnesses.

I just finished presenting two seminars on this topic to ACCA, along with Steve Brower, Esq., a Superior Court Judge, a Federal Court Judge, and an Appellate Court litigator. I'll post my thoughts/notes from this important seminar in a few weeks.

Meanwhile, what do you think of Gabrielle's checklist?  Have you ever been asked to break some of your own ethical rules as an expert? What did you do?  What happens if the relationship starts off well, but then the attorney begins to practice some of these "Sins" -- What do/did you do then?

"So, I'd really like it if I could say this ..."

If you've just said that to your expert witness, you've just made his blood boil. And that's probably not going to be very good for your case. As engineer Steven Murray, Ph.D., of Exponent Failure Analysis Associates in Menlo Park, Calif., says, "Our job is not to support a lawyer's theory, it's to find out the technical truth."

Working on a case can be like a juggling act -- you've got your client, the other side, the other side's attorney(s), your witnesses, your expert witnesses, the other side's witnesses and experts. That's a lot of balls in the air. But you should never lose sight of your expert witnesses -- they can make or break your case. Commit too many of the Seven Deadly Sins and you can sabotage your chances of getting the best results.

Court Rules Retention Of Draft Expert Reports Is Not Necessary

Although this information was originally posted in May 2007 at http://www.fulcruminquiry.com/Draft_Expert_Report_Retention.htm , I believe it can be instructive today.  What have you seen or done in your law or expert witness practices?  WSR

The obligation to retain and produce drafts of expert reports in discovery is becoming a common dispute area. Using current word processing technology, such drafts are often not reduced to paper. Typically, the party seeking additional discovery contends that the expert witness should produce emails and/or report drafts that were provided to employing counsel.

Integration can kill otherwise kill successful ERP implementations

Over half of silicon.com's CIO Jury panel believes integration issues are increasingly becoming a major obstacle to the successful implementation of complex ERP systems.

This comes after furniture chain MFI issued a profits warning after the botched rollout of an SAP-based supply chain system that led to customer orders being sent out incomplete; the problem will now cost £30m to correct.

Integration issues appear to have been the key to the problems, with SAP claiming there have been no issues with its software. We asked our CIO Jury if the complexity of integrating ERP systems is getting worse and hampering projects.

Internet Archive (archive.org) may provide inculpatory forensic evidence

In case now pending in the district court of Colorado, presided over by that court's embattled Chief Judge Edward Nottingham, the Internet Archive may prove to be a source of incriminating forensic evidence.

Briefly, the case arises from allegations that a resort's ski instructor raped a teenage girl. The girl and her family have sued the resort, noting that it gave assurances that any ski instructor working with children must have a "clean criminal record."  Read full story. The accused instructor, in fact, has a lenghty rap sheet.

In its response to the lawsuit, the resort contended that it never promised that criminal checks were performed on employees and supplied copies of its Web pages to support the contention.  However, the family's attorney said that the supplied offers-of-proof are phony, noting that a search of old Web pages on www.archive.org revealed that the resort had, in fact, made such representations since 2002.  Moreover, he said, the archive site contained no pages similar to the ones that the resort supplied. "As the record now stands before the court, it appears that [the resort's] affidavits are false and misleading, the alleged copy of [the resort's] Web site is fabricated and [the resort] has attempted to destroy evidence."

Posted by Sean Harrington on March 20, 2008 at 04:34 PM in Technology and the Law | Permalink | TrackBack (0)

Briefly, the case arises from allegations that a resort's ski instructor raped a teenage girl. The girl and her family have sued the resort, noting that it gave assurances that any ski instructor working with children must have a "clean criminal record."  Read full story. The accused instructor, in fact, has a lenghty rap sheet.

In its response to the lawsuit, the resort contended that it never promised that criminal checks were performed on employees and supplied copies of its Web pages to support the contention.  However, the family's attorney said that the supplied offers-of-proof are phony, noting that a search of old Web pages on www.archive.org revealed that the resort had, in fact, made such representations since 2002.  Moreover, he said, the archive site contained no pages similar to the ones that the resort supplied. "As the record now stands before the court, it appears that [the resort's] affidavits are false and misleading, the alleged copy of [the resort's] Web site is fabricated and [the resort] has attempted to destroy evidence."

IT failure at Heathrow T5: What really happened

April 7, 2008, by Michael Krigsman @ 7:48pm, See http://blogs.zdnet.com/projectfailures/?p=681

Anyone having the misfortune to pass recently through Heathrow’s new Terminal 5 knows the huge project debuted as a case study in full-blown systems failure. Most reports have focused on stranded customers, a crazed supermodel, and Queen Elizabeth’s grand opening speech, which called the terminal “a 21st Century gateway to Britain.”

Here’s my rundown of the major failures and why this debacle happened.

Why this blog? Why now? Why YOU?

“IT Projects: Expert Witness, CIO, In-House Counsel & Litigation Forum

... engaging IT best practices, turning around IT projects, & understanding IT litigation issues” http://blog.wsrcg.com

Despite great changes and/or advances during the last 20 years in the shape of the world (it’s flat again), science, medicine, publishing, distribution, communications, the price of gasoline, the world-wide web and 9/11, two related areas of technology have failed to keep pace: IT system project success and the IT Law that supports it.

Did you know that:

1. The success rate for software development/implementation projects has not exceeded 35% (per the Standish Group’s “Chaos Reports”) during that period?

2. Scrapped software projects accounted for $55 billion in the USA – just a few years ago (per the National Institute of Science & Technology)?

3. The promised cost, schedule and functionality benefits from outsourcing IT have not been realized in 50% of the North American & European companies that use it?

4. Lawsuits between many large software companies, their Fortune 500 customers, and the giant IT consulting/systems integrator firms have grown from virtually nothing into a steady stream of specialized litigation?

Is there nothing we have learned during the past 20 years to improve the odds of a successful implementation that meets functional, quality, cost & schedule requirements and ROI, tolerable risk levels & stakeholder expectations? 

Just One More Time, "Why Do Systems & Software Projects Fail?”

In this new millennium, it is still true that approximately 29% of all large-scale systems projects are successful, 53% are challenged (with average overruns of 84% in time, 56% in dollars and only providing 67% of the required functionality), and 18% are scrapped and written off altogether. Although these stats show a small improvement over the statistics from a decade ago, and even with all the reported advances in technology, methodology, and software development and implementation, this is a poor showing for the Information Technology Industry [Source: Standish Group “Chaos Reports”].

For the past 36 years I have been a computer systems consultant and computer crisis consultant, including 20 years as a large-scale systems project turnaround specialist and an expert witness in large-scale software and systems implementation failures in the United States, Canada, the Caribbean, Europe and Asia. If I have learned anything, it is the following:

1. Virtually all systems failures stem from the same handful of root causes and lack of “-abilities” (e.g., cap-ability, respons-ibility, suit-ability, etc.). And this is true everywhere in the world!
2. All parties in a large scale systems or software project failure or dispute typically share some of the blame, but with some bearing much more blame than others for causing the failure(s) to happen, allowing them to happen, or being unaware that they are happening – with each party contributing anywhere from 0%-100% in each failure category.
3. Many, if not most, of the problems (sand their causes) could have been avoided, mitigated, or managed if the parties followed a few simple, but not easy, rules.
4. Putting in proper project policies, procedures, resources, monitoring metrics, tools, and project team communications to address these root cause areas could have either: (1) allowed the project to be successful in the first place if they were implemented and used from the outset of the project, (2) been used to turn around a runaway project midway if not originally implemented.
   
   Alternatively, determining how and how much each party contributed to these root causes is extremely powerful in helping judges, juries, and arbitrators assess the comparative guilt of the parties in litigation or dispute resolution for failed systems.

I developed the chart below to summarize my findings regarding why systems and software projects fail. This chart has been published in several peer-reviewed scholarly journals with relatively few changes over the years because of the persistent applicability and relevance of these root cause failings through today.

Please send me your experiences and insights on Why Systems Fail -- and What to Do About it?

More Software Bugs: 2003 - 2005

Trading on a major Asian stock exchange brought to a halt in Nov. 2005, reportedly due to an error in a system software upgrade. The problem was rectified and trading resumed later the same day.

May 2005 newspaper article reported that a major hybrid car manufacturer had to install a software fix on 20,000 vehicles due to problems with invalid engine warning lights & occasional stalling. In the article, an automotive software specialist indicated that the automobile industry spends $2 billion to $3 billion per year fixing software problems.

Media reports in Jan. 2005 detailed severe problems with a $170 million high-profile U.S. government IT systems project. Software testing was one of the five major problem areas according to a report of the commission reviewing the project. In March 2005 it was decided to scrap the entire project.

July 2004 newspapers reported that a new government welfare management system in Canada costing several hundred million dollars was unable to handle a simple benefits rate increase after being put into live operation. Reportedly the original contract allowed for only 6 weeks of acceptance testing and the system was never tested for its ability to handle a rate increase.

Millions of bank accounts were impacted by errors due to installation of inadequately tested software code in the transaction processing system of a major North American bank, according to mid-2004 news reports. Articles about the incident stated that it took two weeks to fix all the resulting errors, that additional problems resulted when the incident drew a large number of e-mail phishing attacks against the bank's customers, and that the total cost of the incident could exceed $100 million.

Software Bugs Continue to Plague Systems (2006 & 2007)

Source:  A very good website:  http://www.softwareqatest.com/qatfaq1.html

"What are some recent major computer system failures caused by software bugs?

• News reports in December of 2007 indicated that significant software problems were continuing to occur in a new ERP payroll system for a large urban school system. It was believed that more than 1/3 of employees received incorrect paychecks at various times since the new system went live in January of that year, resulting in overpayments of $53 million, as well as underpayments. An employees' union brought a lawsuit against the school system, the cost of the ERP system was expected to rise by 40%, and the non-payroll part of the ERP system was delayed. Inadequate testing reportedly contributed to the problems.
• In November of 2007 a regional government reportedly brought a multi-million dollar lawsuit against a software services vendor, claiming that the vendor 'minimized quality' in delivering software for a large criminal justice information system & the system did not meet requirements. The vendor also sued its subcontractor...
• In June of 2007 news reports claimed that software flaws in a popular online stock-picking contest could be used to gain an unfair advantage in pursuit of the game's large cash prizes. Outside investigators were called in and in July the contest winner was announced. Reportedly the winner had previously been in 6th place, indicating that the top 5 contestants may have been disqualified.

New Millennium: New Lawsuits

Japanese bank sues IBM over ‘difficult’ computer system

March 6th, 2008 by Beth Pariseau

... I got a chuckle out of this story from Reuters UK today about a lawsuit filed against IBM:

A small Japanese bank has slapped International Business Machines Corp with a $107 million lawsuit, saying the technology giant failed to properly deliver on a computer deal.

Suruga Bank, based in Shizuoka Prefecture west of Tokyo, hired IBM in 2004 to help overhaul its computer system, but later baulked [sic] at the proposed changes.

“We are suing because we decided it would be difficult to implement the system they suggested,” a spokesman for the bank said.

Kind of a dangerous precedent ... if this suit is successful, don’t you think?
***************************

Well?  What do you think?

IT Project Jargon Mysteries Uncovered

Here's a set of definitions to help you understand what those Checkpoint Reports are really telling you ! [author(s) unknown]

Essentially complete
It's half done.
We predict...
We hope to God!
Risk is high, but within acceptable ranges of risk
100:1 odds, or with 10 times over budget using 10 times the people we said we'd employ.
Potential show stopper.
The team has updated their resumes.
Serious but not insurmountable problems.
It'll take a miracle...
Basic agreement has been reached.
The @##$%%'s won't even talk to us.
Results are being quantified.
We're massaging the numbers so they will agree with our conclusions.
Task force to review.
Seven people who are incompetent at their regular jobs have been loaned to the project
Not well defined at this time.
Nobody's even thought about it.
Still analysing the requirements.
See previous answer.
Not well understood.
Now that we've thought about it, we don't want to think about it anymore.
Requires further analysis and management attention.
Totally out of control!
Results are promising
Turned power on and no smoke detected -- this time...
Elements will be phased in gradually as the software interface matures
It's late!
Unacceptable stretching-out of the time scale
It's late!
Still in the early phase of the learning curve
New
The requirement was changed and the programme concluded
Cancelled
Experiencing transient malfunctions
Going wrong
Conceptually configured in several variations
Modified
A structured interface with the government on an inter-departmental basis
Money!

I hope this helps. Maybe you have some that we should add to the list. Tell us in your comments.