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

FAA Outage Due to ‘Fix-on-Fail’ Policy

And we used to get upset about delays of more than a half-hour.  Don't bother to fasten your seat belts folks, to paraphrase a famous line from "All  About Eve" , because we may not be taking the ride we have planned - bumpy or not!  Anybody caught in that mess last week? Anyone have travel tales of woe to share with us?  We would like to hear from you.      Marlene

Posted by Michael Krigsman
September 2nd, 2008
http://blogs.zdnet.com/projectfailures/?p=1004

Last week’s technology failure at a major FAA facility caused air traffic delays throughout the country and highlighted the agency’s poor computing practices. Unlike major corporations and utilities, the FAA operates its air traffic control system with minimal redundancy using a “fix-on-fail” policy.

Redundancy is the foundation concept behind business continuity planning (BCP), which involves creating logistical and operating plans designed to take effect after a major disaster or critical infrastructure disruption. According to the Associated Press, the FAA maintains less redundancy than water or power utilities:

Redundancy is so critical for power and water utilities that they can be fined hundreds of thousands of dollars a day if they’re found insufficiently prepared — and $1 million per day if they’re found to be willfully negligent.

“If this (FAA outage) happened at a power plant,” [according to security researcher, Jason Larsen,] “I’d be telling them to open up their checkbook and expect to be fined.”

The Associated Press article points out pitfalls of the fix-on-fail policy:

“[I]t’s the whole `don’t fix it if it ain’t broke’ thing,” said Branden Williams, director of a unit of VeriSign Inc. that assesses the security of retailers’ payment systems. “It’s unfortunate because it’s very reactive, and it typically winds up costing you more. If you do fix-on-fail, it usually costs you more.”

The AltuisIT blog discusses this same issue:

To reduce their total cost of ownership, industry-leading organizations know that IT systems need to be properly managed and maintained. The “Fix on Fail” approach to systems management results in employee frustration, missed deadlines, increased costs, and lower levels of customer service.

E-voting vendor: Programming errors caused dropped votes

I thought Every Vote Counted! Not if major electronic voting systems lose votes! Not if it is caused by undetected source code logic errors. Given how close the last few presidential elections have been, hundreds of vote can make a big difference. According to Kevin Costner's new movie "Swing Vote" even 1 vote can change the whole future.  In any event, let us have your thoughts on this article and your thoughts on software testing, error detection, bug fixing,  etc. is as good as it gets, or some programmers and testers and project managers till just don't get it!! Also, let us know or any new tools that are working for you (or not) and what you or your company has done to improve its latent defect errors metrics.   Warren S. Reid

Written & originally posted By Grant Gross , IDG News Service , 08/22/2008 at: http://www.networkworld.com/news/2008/082208-e-voting-vendor-programming-errors-caused.html

A major electronic voting system vendor has changed its story in an attempt to explain how its machines dropped hundreds of votes in Ohio's March primary elections, saying it was a programming error, not the fault of antivirus software.

E-voting machines from Premier Election Solutions, formerly called Diebold Election Systems, dropped hundreds of votes in 11 Ohio counties during the primary election, as the machine's memory cards uploaded to vote-counting servers. Premier originally blamed conflicts caused by antivirus software from McAfee, but the company this week said a logic error in the machines' GEMS source code was responsible for the problem.

"We now have reason to believe that the logic error in the GEMS code can cause this event when no such antivirus program is installed on the server," Premier President Dave Byrd wrote in a Tuesday letter to Ohio Secretary of State Jennifer Brunner. "We are indeed distressed that our previous analysis of this issue was in error."

New IT Project Failure Metrics: Is Standish Wrong?

Posted by Michael Krigsman - December 7th, 2007

http://blogs.zdnet.com/projectfailures/?p=513&tag

How many of you out there have quoted the Standish Group's Chaos Report for lo these many years?  Right! What importance might this new report hold, and does this information fall into the category of the experts being right - at one time - but the times they are a'changing? (Just tossing in a reference for all you music lovers out there).  Let us know what your take is on this new outlook and  information.   Marlene Palmer, WSRcg LLC, Consultant

The Standish Group’s Chaos Report describes two-thirds of IT projects as being “challenged.” Now, three academics have published a report suggesting these numbers are flawed, and that only one-third of IT projects actually fail. If this new report is accurate, it represents a significant departure from common perceptions of IT project risk and failure. The research was conducted by Chris Sauer, Andrew Gemino, and Blaize Horner Reich who described their results in an article titled, The impact of size and volatility on IT project performance.

EXECUTIVE CONCLUSIONS

The following table outlines management recommendations made by the authors on the basis of their research:

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.

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.

Seven Key Lessons to Keep in Mind When Communicating an IT Failure

Posted March 4th, 2008 by Jonah Paransky
ttp://www.stacksafe.com/blog/2008/03/04/seven-key-lessons-to-keep-in-mind-when-communicating-an-it-failure/

IT Failures Happen.

While business and customers often expect 100% uptime, they don’t always receive it.

When failures happen, often the quality of the communication process does not match the technical resources brought to bear to solve the problem.

Here are seven key lessons to keep in mind when communicating an IT failure.

1. Have a communication plan in place and ready to go

All IT service delivery teams should maintain an active business continuity or disaster recovery plan. The time to develop your communications plan is not during the outage or service failure when the entire organization if focused on dealing with the problem at hand. Any credible continuity planning process should include the development of canned messages and a communications playbook that can be used during the failure. Does yours? If not, start the process of updating it as soon as possible.

2. Direct Communication with your customers is the number one concern

Customers would much rather hear about a problem directly from you, rather than from the media or discovering the problem themselves. If you are experiencing a major service failure, let your customer base know ASAP.

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?