IT Project Failures

Recently Read – 02/17/2010

Posted on 17. Feb, 2010
Categories: Book Reviews, IT Project Failures, IT Projects, Social Media

1

Microsoft, social networking, the IT-Business chasm, and Google Wave are just a few highlights from the blogosphere this week. I also have to recommend an incredible book about tennis.

Extremes in Risk Tolerance

Posted on 28. Jan, 2010
Categories: Consulting, Culture, IT Project Failures, Project Management

4

I have been giving quite a bit of thought lately to the topic of enterprise risk management. In large part, this stems from the fact that I recently completed a project in which my client’s risk tolerance was off the charts. I mean crazy. In this post, I discuss three types of organizations with respect to risk tolerance.

Continue Reading

Technology Today #11: Mitigating IT Project Risk with Craig Stephens

Posted on 25. Jan, 2010
Categories: IT Project Failures, IT Projects, Software, Technology Today

0

A few months ago, ERP software vendor Epicor announced an interesting program designed to help its clients avoid IT project failure. The “Shared Benefits” program takes an innovative approach to addressing problems endemic to many IT projects. In this podcast, Craig Stephens (VP of Servies at Epicor) discusses the impetus and mechanics of the program.

Continue Reading

Disposable Workers, Newton’s Third Law, and The Lock Down

Posted on 11. Jan, 2010
Categories: Consulting, IT Project Failures, IT Projects, Recession

4

What are the often overlooked risks facing organizations that rely on non-employees? If an organization’s goal is to minimize short-term cost savings, then it’s hard for me to argue against using consultants. Cost aside, contractors and temps have no employment contracts and we’re generally not covered by US labor laws.

Continue Reading

Always Be Closing

Posted on 17. Sep, 2009
Categories: IT Project Failures, Vendors

1

In my experience, many salespeople act as if they’re in another one of my favorite movies, Glengarry Glen Ross. As personified by Alec Baldwin’s Blake, many salespeople lamentably still adhere to an “Always Be Closing” mentality.

Continue Reading

Google and Failure-Tolerant Cultures

Posted on 08. Sep, 2009
Categories: Culture, IT Project Failures

0

If adopted, methodologies like Agile software development should decrease failure rates. Of course, people will ultimately determine whether these projects fail much more than any methodology or technology.

Continue Reading

Five reasons to fire your system integrator

Posted on 07. Aug, 2009
Categories: Consulting, Enterprise Systems, Guest Posts, IT Project Failures, Project Management

0

While it’s tempting to blame the system integrator for all project hassles and differences of opinion, introspection is also worthwhile. Before pulling the plug, evaluate your own role in creating the problems you experience. The more accurately you understand each party’s contribution to the negative situation, the better you can solve the problem.

Continue Reading

Changing System Integrators: A Baseball Analogy

Posted on 06. Aug, 2009
Categories: Consulting, Enterprise Systems, IT Project Failures

1

For a variety of reasons, organizations in the midst of a project often consider replacing their system integrator (SIs). The project may be the implementation of a new system, an upgrade, or an “add on” type of engagement in which new functionality is enabled. (The latter typically takes place after initial system activation.)

Continue Reading

The Role of the Project Manager on a Failing IT Project

Posted on 30. Jul, 2009
Categories: Enterprise Systems, IT Project Failures, Project Management

2

I tend to view PMs are important but not omnipotent. They are certainly not the most critical factor in a project’s success. The buy-in of senior management, the architecture chosen, and the resources committed to a project are (among others) higher up on the list of reasons for a project’s success or failure.

Continue Reading

The Need to Publicize System Failures

Posted on 21. Jul, 2009
Categories: Enterprise Systems, IT Project Failures

0

When the results of failed IT projects do become public, key players often attempt to minimize the damage for obvious reasons. Software vendors are less likely to sell new licenses and services if word gets out that their applications do not work as advertised or require heavy customization. SIs face similar concerns from discerning clients.

Continue Reading

Systems Breakdown Case Study: A Square Peg and a Round Hole

Posted on 01. Jun, 2009
Categories: Articles, Cutter, Enterprise Systems, IT Project Failures, Project Management

0

Every organization uses software applications to support its business processes. Some organizations buy, some build, and some rent software as a service (SaaS). Buying and integrating proprietary applications are sometimes complicated by M&A activity. Acquired or merged organizations often use different applications and systems than their new owners.

Continue Reading

The Burnt Hand Teaches Best: Financial Firms Turn the Corner on New Systems

Posted on 01. Apr, 2009
Categories: Articles, Enterprise Systems, IT Project Failures

0

While there is no secret sauce to building and implementing client-facing systems, financial firms tend to minimize failure rates by utilizing ISVs and extensively documenting business requirements. Seasoned ISVs allow firms to quickly create and roll out custom applications that can increase firm revenue, profitability, and ROI. With respect to enterprise and back office systems, however, financial firms should not try to build from scratch. They realize no competitive advantage from payroll vendors or employees. In this sense, financial firms tend to have many of the same issues as the rest of the corporate world.

Continue Reading

Trying to Practice What I Preach

Posted on 13. Jan, 2009
Categories: Consulting, Enterprise Systems, IT Project Failures

0

Usually, system functionality is not a binary; systems have levels of functionality. Features can be enabled at different points. If a module or significant feature of a system does not make the cut for Phase I because of delays, budgets, or lack of successful testing, then the organization should revisit it in Phase II.