Michael Krigsman Talks Project Failure and Downtime

We had the opportunity to catch up with ZDNet’s Michael Krisgman on project failures, the cause of failure, and examples of companies that have handled project failure well (and not so well).

Michael is a noted expert on IT failures and is CEO of Asuret, Inc., a software and consulting company dedicated to reducing software implementation failures. Asuret’s suite of software tools improve the success rate of enterprise software deployments by quantifying and measuring the non-technical risks and complexity that cause most implementation failures. Michael led the research effort underlying Asuret’s model of risk factors that contribute to project failures.

Michael also answered some questions via podcast, which are available for download below.

StackSafe: What do you see as the biggest cause of IT project failures?

Michael Krigsman: IT failures typically arise from organizational, cultural, political and other non-technical causes. It’s rare for a project to fail because the database doesn’t work, for example. Technology problems happen all the time — that’s a fact of life — but careful management of those issues is key.

StackSafe: What can companies and IT Operations teams do to set their IT projects up for success?

Michael Krigsman: Careful planning and proper management are essential. Before the project ever begins, ensure the business case has been established, seek out and obtain real executive sponsorship, engage end-users and other stakeholders, and so on. These are the nuts and bolts components of substantive project planning.

StackSafe: How do you measure the success or failure of an IT project?

Michael Krisgman: To begin, we can determine whether the project achieves its goals. For example, does the software being deployed solve the business problem it was meant to address? Evaluate whether users have incorporated the new software into their daily routines; if so, then most likely the project has achieved at least part of the goal.

At the same time, success or failure can be determined on the basis of budget, schedule and scope. It’s usually pretty easy to determine whether the project has gone beyond schedule or over-budget. Reducing project scope to stay within time and budget is also a good indicator something has gone wrong.

StackSafe: What do you see as the greatest cause of downtime and availability for IT services? Any good examples?

Michael Krigsman: There are many technical reasons for web and SaaS downtime, and no company is immune. Google, Amazon, Salesforce.com, Twitter, and many other well-known companies have faced this problem. The real issue is how the service providers handle downtime. When downtime occurs, users want transparency and up to date information. Cute cartoons don’t cut it when users are unhappy. Solid, accurate, timely, honest information is the way to go when downtime happens.

StackSafe: Often we talk about the failures. Any good examples of companies, organizations or leaders that show a strong path for success?

Michael Krisgman: Statistics show that 30% - 70% of IT projects fail in some important dimension, so failure remains a common problem across the industry. Successful organizations have a built-in bias toward repeatable process and strong cultural honesty. Denial is a strong component of many IT failures, which is why honesty is so important. When a project has trouble, it’s best to recognize the issues and address them head-on.

Sweeping unpleasant information under the carpet doesn’t solve anything; it only delays the inevitable uncovering. Usually, when problems have been hidden they emerge more serious than they were. Time has this nasty habit of making ongoing failures worse rather than better.

To determine whether an IT organization is successful, examine how they handle failed projects. Since no IT shop is immune to failure, or organization’s ability to interrupt the failure cycle, and then learn lessons from it, becomes all important.

StackSafe: What are the implications of downtime when projects fail? What does it mean to a big company (Blackberry) vs. a small company (Twitter)?

Michael’s response - listen here.

StackSafe: Government institutions and businesses have different drivers for embracing technology for mission critical applications vs. profit. How do you think their views differ on downtime and how they handle it?

Michael’s response - listen here.

StackSafe: Give an example of a company that has handled a troubled project well, and one that hasn’t.

Michael’s response - listen here.

Popularity: 11% [?]

Filed Under: Downtime, IT Operations, ITIL, Interviews, Interviews-Analysts, Interviews-Bloggers, Testing, Virtualization