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

Five reasons to kill IT projects

If I had input into this survey, I probably would have picked #4 for 1st place on the list.  In what other order might you have imagined this list to appear?   Marlene  

Previously appeared November 26, 2008

Author:a guest post from Michael Krigsman of TechRepublic’s sister site ZDNet

A recent study highlighted the top five reasons IT experts who killed a project gave for terminating projects prior to completion. Check out the five reasons.

http://blogs.techrepublic.com.com/tech-manager/?p=643&tag=nl.e053

 A survey of IT experts revealed 43 percent of their organizations had recently killed an IT project. The study, conducted by ISACA, an independent IT governance group, highlighted the top 5 reasons these organizations named for terminating projects prior to completion. Here’s the list, with my commentary on each issue:

1. Business needs changed: 30%

There are many conditions and situations where a business legitimately changes its requirements after starting a project. If the project no longer provides meaningful value, then it’s best to stop throwing good money after bad.

On the other hand, some organizations deliberately obscure a flawed project requirements process by claiming business needs evolved. Obviously, that’s unhealthy and a true sign of failure.

2. Did not deliver as promised: 23%

This is a typical expectation-setting problem: promise anything to get funding and worry about the consequences later. Shortsighted managers don’t realize that funding is less important than delivering substantive value. Failure is inevitable when managers don’t clearly identify and deliver business value.

In some cases, the project really did provide value, which the organization did not recognize due to communication problems. I recently blogged about one CIO seeking a publicist presumably to address this issue:

Many organizations take a CIO for granted when his IT department consistently delivers the goods without fanfare and attention; sadly, this human failing is all too common. In that case, PR might be a great idea, especially if the CIO isn’t a great communicator. Of course, the CIO should improve his communication skills, but that’s another story.

8 Ways To Save Your Next Project

How does everyone out there feel about taking a "start the project and see what you're up against" approach for IT projects?  And perhaps the comparison of a project to a turkey is an unconscious commentary on the rate of failed projects.

Has anyone out there ever referred to a failed IT project as a "turkey"  (not to be confused with "turnkey"). Any thoughts?      Marlene (Turkeys added for emphasis)

:http://www.baselinemag.com/c/a/Projects-Enterprise-Planning/8-Ways-To-Save-Your-Next-Project/1/
By Elizabeth Bennett 2007-12-17

With IT projects consistently running late and over budget, it's time to look at what technology leaders and project managers could do to step up their performances.    

Mumbai, IndiaTechnology projects bare a striking similarity to home renovations. Both are surrounded by wildly high hopes at the start and often end up causing financial and emotional heartache. There are some new numbers to back up the unfortunate reality that many projects simply don't deliver as expected. 49 percent of organizations have suffered from budget overruns on IT projects and 62 percent have experienced schedule delays, according to a new report by Tata Consultancy Services (TCS), an IT consulting firm based in Mumbai, India.

The study, which surveyed 800 organizations in theUnited States, Europe and Asia, also found that 47 percent of respondents have experienced higher-than-expected maintenance costs and 41 percent said IT projects failed to deliver the expected business value and ROI.

In short, IT projects are a chronic disappointment.

It's hardly news that technology projects are rarely on time and within budget, but the question remains: what more can be done? We thought it was worth taking a look at why projects are so likely to fall behind and where IT leaders and project managers could improve their performance—and therefore the likelihood of successfully completing a project with minimal cost and schedule delays.

Baseline created the list below with the help of Kent Crawford, CEO of PM Solutions, a project-management consulting firm based in Havertown. PA, Bob Laliberte, an analyst  with Milford,  Mass.-based Enterprise Strategy 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.

101 Ways To Know Your Software Project Is Doomed

I thought this was a pretty good list.  I picked my favorite ten, presented below from the full list -- and that was harder to do than I first envisioned.

1. Management has renamed its Waterfall process to Agile Waterfall
2. Allocated QA time is for Q and A why your crap is broken
3. All of your requirements are written on a used cocktail napkin
4. Progress is now measured by the number of fixed bugs and not completed features
5. Every bug is prioritized as Critical (or Every Bug Is Trivial)
6. Your spouse only gets to see you on a webcam
7. The sales team decreased your estimates because they believe you can work faster
8. Budget for testing exists as “if we have time”
9. The client will only talk about the requirements after they receive a fixed estimation
10. Broken unit tests are deleted because they are obviously out of date

Taken from http://www.codesqueeze.com/101-ways-to-know-your-software-project-is-doomed/

Your part:  What favorites do you have that are not on this list or which ones on the lsit do you disagree with?   Warren (Note: Click below to see the full list.)

Be Mindful Of IT Workers' Age Groups

In most companies, the policies and practices used to motivate the workforce were established with older generations, the traditionalists and baby boomers, in mind. However, the mind-sets of the younger generations, Generation Xers and millennials, are markedly different. IT leaders need to craft the cultures of their organizations to ensure that all technology workers have the highest motivation levels.

Traditionalists, born between 1900 and 1945, are comfortable with a command-and-control managerial style primarily because they believe it was effective in World War II.

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.

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.

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.

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.

Murphy's Laws of Computing: Share you own "laws" with us!

Every successful industry has them  — Murphy's Laws of Computing (Source Unknown).
Do these resonate with you?  Which new ones would you like to add?

1. When computing, whatever happens, behave as though you meant it to happen.
2. When you get to the point where you really understand your computer, it's probably obsolete.
3. The first place to look for information is in the section of the manual where you least expect to find it.
4. When the going gets tough, upgrade.
5. For every action, there is an equal and opposite malfunction.
6. To err is human... to blame your computer for your mistakes is even more human, it is downright natural.
7. He who laughs last probably made a back-up.
8. If at first you do not succeed, blame your computer.
9. A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.
10. The number one cause of computer problems is computer solutions.
11. A computer program will always do what you tell it to do, but rarely what you want to do.

Do these resonate with you?  Which new ones would you like to add? Send them to me and we will select the best and most original ones and create our own bloglist with  your name ascribed to your winning entry!