Wednesday, July 18, 2007

Key Learnings: Business driven runaway projects

A scenario where cash rich LOB continues to invest and drive projects with no foreseeable return on investment.

Typically in all major corporation there is at least one major Line of Business that is cash rich, i.e. this business unit tends to exceed their revenue forecast and is looking for ways to spend money during the last two weeks of quarter/financial year.

Best Practices:
  • LOB should invest on Projects that is beneficial to both their business unit as well as the Enterprise
  • The "IT-Board of Directors", which includes the cash rich LOB - decides which projects get funded
  • Business and IT need to jointly develop an ROI before embarking on any large projects
  • LOB-IT should make technology decisions in collaboration with the CIO-Staff and the EA teams
  • Engage Business Consultants or Systems Integrator to provide business and technical advice/best practices

Symptoms:

Following are some of the symptoms of a potential runaway project.

  • LOB sponsors the project but not willing to wait for other LOBs which may be swamped implementing a strategic project themselves or overhauling their business process/organization
  • LOB determines it knows what is best of the enterprise and starts investing in what it terms as Enterprise wide project, even though there is no buy-in from the other LOBs, CIO or the Enterprise Architecture team
  • LOB is a huge proponent on the divisional LOB-IT
  • LOB is very critical of the CIO and/or the IT as a whole
  • LOB-IT uses technology what it understands the best, without consulting the EA team. Examples: Leverage EAI tool to move huge volumes of data instead of using an ETL tool, developing data quality tools in-house instead of using appropriate tools, etc.
  • Attempts to resolve Business Processes at their end, instead of working with other LOB
  • LOB-IT leadership attempting to make progress in their career paths by transferring to the LOB
  • The targeted end-user community is very small

Project Approach:

  • Such a project typically begins with LOB initially coming to IT stating that they would like to start a project ASAP to conduct a feasibility study for looking at one of the major business process withing an enterprise.
  • As IT projects are planned at the beginning of the year - IT agrees to bring in an SI to run this project (with PMO Oversight).
  • Based on the feasibility study - the SI (rightly) identifies the potential issues with the business process and recommends that this be resolved at an enterprise level - presents a phased approach - PMO, Enterprise Architecture team and CIO agree to this.
  • Implementation phase begins - but other LOBs are not ready to participate and redefine the end-to-end business process.
  • EA recommends to both SI and LOBs that they wait until the other LOB are ready to engage (this is where the organization dynamics begins :) ).
  • In order to start generating revenue SI pushes for project to begin and fix some of sub-business process later (as-if this will really work)
  • The Business project manger - in order to gain executive visibility agrees with the proposal
  • The other LOB teams feel sidelined and stops participating
  • To avoid having a difficult conversation with the LOB, The LOB-IT agrees with the LOB and SI, against the advise to the Enterprise Architecture team and the PMO

Recommended Course of Action:

  • The best course of action for the PMO and the Enterprise Architecture team is to support the project as best as they can
  • Continue to ask the LOB to define the objective and ROI for every phase
  • The most noticeable aspect is the objective of the project is redefined - "To understand the issues with the business process" - instead of having a real objective or ROI
  • The overall cost of the project is no longer published - instead only the SI cost is published
  • The projects moves through the life cycle phase - even though it never meets the predefine and agreed upon exit criteria with the PMO

On completing a couple of phases of the project, it would be abundantly clear to the CIO (provided of course the PMO does its job) whether the project is a failure or a success. Based on this data - the CIO has enough data to push for stopping the runaway project.

In short - "Support the project the best you can and let it run its course. If it was bad idea from the start - it will eventually fail and someone" (but do not expect anyone to be held accountable :) ).

This fictitious scenario is based on multiple conversation with my peers in the industry.

Next Topic:

Key Learning's: IT driven runaway projects

Post a Comment

Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!

A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...