Loading
Newsletters
Digital Tools
CIO Blog
Virtualization RSS Feeds
Managed Services Webcast
Service Oriented Architecture Podcast

Rolling Out a Data Leakage Prevention Program

Case Study of a Leading Financial Services Conglomerate from India

When Projects Fail

27 December 2010 07:20 am , Daya Prakash

Should the CIO own the responsibility of an IT project failure? There is no straight answer to the question. Very few CIOs will accept any kind of defeat upfront. But theoretically, a true CIO or business leader is the one who accepts the ownership of the IT organisation and the projects deployed and run by it. At that stage it doesn’t matter whether the project was initiated by IT or the business.

Under all circumstances, the CIO is the one who owns the responsibility of every IT project. A lot depends on a CIO’s ability, experience and wisdom, how s/he identifies the glitches in the early stages of the project to prevent catastrophes.

In practice, the ownership of an IT project can vary from being totally in the hands of the CIO to one where the CIO organisation is merely doing the bidding of the business enterprise. In the frst case, clearly, the buck stops with the CIO, in the second, perhaps one can see a failure as a joint one at best.

An IT project can fail due to different reasons, including poor need-identifcation and mismatch between stakeholders' expectations and the action taken on the project. Issues such as scope defnition, cost estimates and ROI calculations – each one of these too has a role to play in either derailment or failure of a project.

I would say that the cost, stakeholder expectation mapping and the risk assess-ment of any IT project fall directly in the CIO’s domain and in case of a project failure the CIO has to bear the brunt. But in the second scenario where CIO is just an enabler, s/he can’t be held responsible for any sort of failure clearly because he is just one link. It may be a classifed as a joint failure of CIO and the business.

To save the projects from meeting an ill fate, it is very essential for a CIO to assess the risks associated with that project. S/he has to ensure a thorough and continuous communication within and outside the team so that the issues can be identifed in the early stages of a project. But even after all of this, if the project fails, it is good to accept the failure rather than keep the stakeholders in the dark. We all learn from failures. This is how we evolve and improve.

Collective Responsibility
Not doing this presents various stakehold-ers with the undesirable opportunity to play the blame game. A CIO, however people-friendly s/he is, needs to set some rules of the game. Every role, responsibility and function has to be defned and explained to its bearer. Before even taking the frst step, it is essential to have everyone commit to the success and/or failure of the project. You may have seen how the critical space missions work. Everyone knows what role they have to play. But if the project meets a disaster, there is no one person singled out in the team. It is considered as a collective failure and that’s the best way to accept defeat and rebuild the whole thing to make it successful.

Similarly, in IT, it is imperative for the CIO to lead from the front and keep the team informed about the scope and implementation road map. In my personal experience, the majority of these issues crop up because of the sense of insecurity. Everyone is scared that if anything goes wrong, they will be blamed. That thought needs to go. Going back my example of space missions, everybody knows about his/her role. S/he performs that role and similarly others also do their job. In those cases, not only the project failures are minimised but also there’s always a sense of collective responsibility. An organisational matrix plays a big role in this.

Don't Look for Losers
No CIO starts a project to have it fail. In almost all instances, when an ambitious project starts, it is assumed that it will be successful. When a project fails, even those who played their part very diligently become part of an unsuccessful project team. Do we really call them losers? The answer is no. A project may have failed but to put the onus on one person or to single out one member of the team will be a little immature. Yes, I agree that the team members may need counseling or guidance or may be hand who played their part very diligently become holding too and that’s where a CIO needs to be playing the role adequately but certainly not single out anyone to put the entire blame of the failure.

Even with external partners, the intent is not to highlight that mistake and reprimand someone even if he is an external partner. I will reiterate my point that a CIO should work more on identifying the risk early on so that every possible casualty is avoided. The risk should be mitigated to the extent that even if something happens, it doesn’t bring the project to a standstill. Yes, you do tell your partners about things which could have been better. Even the partner needs to be forthcoming in accepting the mistake and move ahead with a positive attitude.

If you have convinced the team on a project and that team is committed to taking on the job, you have won half the battle. This very team will ensure that it keeps failure out of the radar screen. It all depends on how much a CIO involves himself with the team to keep the morale high. A lot depends on those kind of soft skills of a CIO.

—Daya Prakash
Head-IT, LG Electronics


Related Content
Readers Feedback



Big Data, Big Hype?


While vendors are aggressively pushing Big Data solutions, do you actually need them?

What has changed in OWASP TOP Ten 2010?

It’s Top 10 Risks, not just Vulnerabilities!

The Case for Automating Case Management Workflows

In today’s challenging economy, organisations must be more agile and work smarter in order to crea