Thursday, August 15, 2013

Who's to Blame for Failed Projects, IT or the Business?

 IT and businesses should share the blame and glory by working as a whole.

There is a lot of empirical evidence saying that inadequate or flawed requirements contribute to the majority of project failures, as it’s an easy target but the failures could come much earlier than that, with more subtle root causes in many cases. The cause to failure may also depend on how exactly the project "failed" -- did it blow the budget out of the water (due to scope creep, perhaps)? Did it not get done in time to meet a critical date? Did it never get implemented or pushed into production? Did it fail to meet the user/customer's expectations?  Who’s to blame for failed project, IT or business? Indeed, a failed project, make business as a whole including IT, HR, Finance, Operations all look bad and lose the valuable resource. So the real question should be: What can business and IT  work together in improving project success rate.

  1. Cross-Functional Communication: Communication plays a vital role in change management. However, just because tools for communication are available it does not mean that things will improve. Actual communication is required and personal communication will always win over impersonal communication. And this is everything from requirements gathering to feedback cycles during the project. This applies to all, at all levels. Clear communication is essential. Spend the time to improve the language gap between IT and non-IT.  
  1. Planning & Change Management. Poor analysis, poor change management and lack of availability to provide input from Stakeholders are usual suspects to failures. It is not a case of blaming each other, but asking the question if Business and IT use enough time to plan, and a critical component of that planning partnership should be a change management strategy. Accountability and responsibility for project functions are well assigned -clearly understand who is responsible (doer) and accountable (owner) for each project function, from signing off, requirements/ expectations to testing, releasing etc. If either side sees an issue during this phase of the project, they can determine who should actually be doing this function, and who is going to take responsibility if it doesn't happen. And take action or escalate before it’s too late. 
  1. Requirement: Both business and IT are equally responsible for project failure: Business for missing fine print in stated requirements and the business also has the responsibility to listen and cooperate when IT has to keep asking clarifying questions long after everyone is sick of answering and refining. While IT organization for lack of business knowledge and their inability to gather the requirements granularly within the stated timeframe by business. IT also has the responsibility to not tackle a project that is not clearly defined (and to help the business users refine those requirements) 
  1. Leadership: True leaders can't abdicate responsibility. If you're going to take the glory for the successes you have to take the blame for the failures. And more importantly learn why it failed, and then take corrective action to prevent the same failures repeated in the future. As projects typical have a number of stakeholders across the wide business and should be in the interest of all for project successes. CIO, as a IT leader,  must be seen actively pushing the "thing" in the right direction and sell the outcome to the business. 
  1. Balance: What does "Failure" mean? In the current global state of speed, balance is the challenge. Meeting the demand, getting the details and having the knowledge and technology of the trendy tools to make it happen. The other issue about balance is whether the same resources have to juggle between the project demands and production support.  Further, balance the standard and flexibility. It is too easy to think strict adherence to some methodology will make things easier. It does not. Flexibility must be an integral part of any approach. Of course, flexibility requires decisive management. All you can do under the circumstances is to learn how to play the game without compromising your principles and not beat yourself up when things go awry for circumstances beyond your control. 
Success has mostly been measured from the outcome rather than just basic accounting and specs. Regardless of how the failure determination is made, once lack of success has been determined, there must be lessons learned, adjustments made, and accountability taken, in a mature and professional organization, the learning process kicks-in and do some fact finding, to ensure that All people learn, change and become a stronger organization. This process might find a few areas for improvement (moral, low capability, lack of key skills, poor sponsorship), which should not be put in a light of BLAME, as otherwise, an organization will never learn with its mistakes. Hence, share the blame and glory by working as a whole.


Post a Comment