Apps optimize

IDC Directions09: Analyst perspectives on IT failure

While attending the Directions09 conference in Boston, ZDNet blogger Michael Krigsman talked to two IDC analysts to get their take on why IT projects fail. Find out what they identify as the major causes of failure.

This is a guest post from Michael Krigsman of TechRepublic's sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

While attending the Directions09 conference in Boston today, I explored why IT projects fail in conversations with two IDC analysts.

During a discussion with Vice President for Services and Technology Research, Sébastien Ruest, we touched on key reasons why projects are late, over-budget, or don't achieve expected results. Sébastien commented:

There is still not enough governance. Projects fail because companies do not apply sufficient real-time governance to their implementations.

I agree that too many organizations allow projects to run without sufficient review and control. As a result, potentially minor disturbances eventually escalate into large, full-blown problems. In the heat of battle, I suppose many managers forget that preventive maintenance really does save time and money.

Sébastien also pointed out an overlooked implication of IT failure:

Failures erode business confidence in the CIO and can cause business stakeholders to reject the CIO's downstream plans. After failures occur, the CIO may face difficulty justifying new projects.

I also met separately with Melinda Ballou, Program Director for Application Life-cycle Management at IDC. Melinda emphasized that many projects fail when poor communication interferes with collaboration among project participant groups:

Although it's common wisdom, poor collaboration and communication between key business stakeholders and IT remains a serious issue. Also, keep in mind that redundant projects, where the organization discovers it is running duplicate projects unnecessarily, is another form of failure arising from lack of communication.

Melinda suggests that Agile development can be an excellent mechanism to improve collaboration, especially on software development projects.

My take. The big causes of failure remain governance, communication, and collaboration breakdowns. As with all people-related obstacles, these issues are difficult to control, let alone eradicate completely. In the end, failure improves when an organization becomes serious about encouraging IT and business stakeholders to work together more closely. As failure statistics demonstrate, that goal remains elusive for most organizations.
9 comments
manuel.bulatao
manuel.bulatao

being a practitioner since 1964, my conclusion is that failures is due to several reasons: 1. the academic training is too technology RICH but application POOR. 2. fragmented applications since most CIO's cannot even manage or dictate a proper integrated data structure. This results to recon issues. 3. the systems analysts is only as good as the user or person defining specs. ergo, a user can demand various reports and these techy guys are at their mercy even if the demand is irrelevant. 4. Loss of competence by the users. Before the era of computers, accountants are the best systems analysts. Now they do not even know where the tables of original entry resides. they need the programmer. 5. Users are not trained to define and demand knowledge of the data structure. SAP for example have as much as 15,000 tables which is a mystery to users. 6. Conspiracy of Fear exists. Packages is the solutions since Internal IT manage gave up on the internal capability to build applications. Board also feels the same. And the triumphant vendor benefits. please visit my blog at itirritant.wordpress.com and get solutions to these issues.

sheralgraham
sheralgraham

I am in TOTAL agreement! Quite often....the "IT" project has little to do with IT, and everything to do with the people and business culture.

bill.folger
bill.folger

Matthew gives a great explanation. I'm the IT caught in a project that when it does finally fail will result in a $275k loss to my local unit. It is a joint powers RFP with twenty eight members. The administrators of the project, the manager, and the director of the joint powers agreement have engaged this project like they were following Mathews check list. Firstly the decision to move forward with this software was made before I arrived, and the discussion makers are all gone. With that, there was and still is no one on my end that would ever take ownership of the new software. I'm IT, I'm not going to be using the software, nor do I know or need to know the what is the best practice for the tasks this software involves. The Go Live date for the software was December 2007, and the contract was renegotiated in 2008. There are three members designated as pilots and right now the software vendor still has not delivered working software to these pilots. The Software vendor has also said that they will not meet all the business requirements, and the renegotiated contract is open ended on this point. I now continue to have a moving target for my conversion and implementation. That has recently been moved from January to March, then to June and now this week moved to July. At what point would you pull the plug? The leaders of the Joint Powers have finally agreed to a full user-group meeting where we can have a vote on continuing, but have not set a date for the meeting, and are still delaying. It's delay after delay after delay. So the point I add to Matthews list is incompetent Project Leadership/Management. IT can do anything, you can have it fast, you can have quality, or you can have it cheap. Pick any two.

IS Researcher
IS Researcher

While it is always useful to repeat important things...is this idea that IT projects (which are almost always really technology-enabled organizational change efforts) most often fail because of governance, communication, and coordination problems? (This is sort of like saying that projects succeed when they are managed well and fail when they are not managed well. -- useful for a beginner, not very enlightening for anyone with any real experience)

TooOldToRemember
TooOldToRemember

We have very few IT projects at my company. But we have a lot of supply chain, accounting, engineering, etc. projects with an IT component. Although my team has the largest number of trained project managers we work very hard to make sure the project is viewed not as an IT project but a business project. Yes, sometimes it is a software implementation or upgrade, but to focus on that aspect of it without the involvement of functional departments affected by it would be to ignore the collaboration and communication needs identified in the article. The result is that over the past seven years the success rate of projects has dramatically increased.

Steve Romero
Steve Romero

This is awesome to hear! I look forward to the day when you don't have ANY IT Projects. I argue that all projects are business projects (and almost all of these have a technology component). The greatest reason we still have "IT Projects" is because organizations can't accurately translate technology to services that enable and support specific business processes and functions. Instead of going to be the business and asking for funds to "upgrade the IT infrastructure", we should be doing the following: "Mr. or Mrs. Business Customer, here is our current Service Level Agreement. This is the situation with the infrastructure that provides the service. If YOU don't invest in an upgrade to that infrastructure, we will need to modify the SLA (either charging more for the service, or lowering the level of service). So, if you want to maintain the current service level, you need to invest in this BUSINESS project. Few IT organizations can take this approach because they don't have an acute understanding of the relationship between the technology they provide, the services they enable, the constituents they serve - and the value they deliver. Steve Romero, IT Governance Evangelist http://community.ca.com/blogs/theitgovernanceevangelist/

andre
andre

You are absolutely right, time and time again I can see projects that are run in isolation, with obvious results. The problem is that, especially junior or intermediate project managers do not have enough power and/or skills to engage business side. Project sponsorship is critical here.

Matthew S
Matthew S

I agree you can say communication, collaboration and governance are root cause issues - but these very ideas can also cause failure if address with the same thinking that caused them. You need to be more specific. My watch list and talk-points for project success are: Enablement As a general rule, no IT project in-of-itself is the desired outcome the business is pursuing. The message must always be that the project will ?enable? the business to achieve what it wants. This means the business remembers that there is effort required on their part to achieve the results. Engagement Building on enablement, is engagement. I normally talk about the ?black-box? syndrome. This is when IT is identified has a major part of the project, so the business expects IT to go away, and come back X months later with a miracle cure to the issues at hand. The leadership & the people on the ground must be engaged (i.e. mentally, passionately, etc can be used here) in the whole process of defining through to sustaining a solution. Ownership Typically only a small amount of a project is actually pure IT. The rest is about business decisions. Ownership of any non-IT decisions, including those made with IT?s counsel or recommendation, must be owned by the business (and at the appropriate level). Be it budget, timeline, design, quality, scope, etc. System Thinking A project is the result of 1,000?s of individual actions and decisions, be it small ones or big ones. These must be made by the right people, at the right time, at the right place to create and maintain progress and success. You mentioned governance, which I think can be a contributing factor to failure, especially when it is poorly done and with a command and control approach. Providing a project with foundational truths and thou shall not?s in combination with guiding principles on how options should be weighed, and decisions evaluated will empower the project participants to act quickly and successfully without length delays in, or avoidance of, decision processes. This must also help avoid selection of the easy or low risk (as in, avoiding accountability) options selected (just because something is hard to do does not make it the wrong answer). These principles can also cover when things should be escalated for more senior review. Command-and-Control Governance should be reserved for check-and-balance processes (e.g. SoX, funding, etc) Collaboration and communication are big factors in all of the above considerations ? and pages can be written to better explain each of the above. However collaboration and communication alone cannot achieve success. Water is a major part of a living organism?s structure, but water alone will not create life. A key point missing too I think is who is defining ?success? or ?failure?. I think sometimes we in the IT fraternity consider things a success, which our business partners would not ? which I think means it wasn?t, because at the end of the day, the ?consumer? defines success ? but too often this is a symptom of the black box syndrome. I missed culture in the above list, but I think it is a major factor on how much of a success or failure a project will prove to be. All of the above can be utilized to neutralize negative components of a business? culture, and leverage the good parts. Any project manager worth their salt, will have a strong sense of the culture in the business scope they will be working in when starting a project. An understanding of the culture plus a sense of the level of engagement and ownership that will be demonstrated down the org chart will give you a good leading indicator on the execution problem areas and post delivery problem areas plus the areas that will go well, so will need less attention.

Steve Romero
Steve Romero

Everything you list is addressed by good governance, collaboration and communication. The only time any of those factors "cause failures" is when they are not understood - and subsequently, not implemented and used properly. I argue, daily, that IT Governance is one of the most misunderstood disciplines in Enterprises today, second only to Process Management. If you read Michael's past posts, I think you will find the "specificity" you found lacking in this post. I can't speak for him, but I think he was simply noting that two prominent researchers share the same conclusions as Michael and many of us, that governance, collaboration and communication are the key challenges in project success. Steve Romero, IT Governance Evangelist http://community.ca.com/blogs/theitgovernanceevangelist/