October 21, 2007

Circumventing the CIO—What’s the Harm?

One of the most difficult challenges we face as enterprise architects is when end-users don’t ask permission, but instead ask forgiveness.

The typical scenario is that a division or unit or group of end-users decides to go out and purchase some new IT widget, gadget, or system without going through the CIO shop. (I know this shouldn’t happen if the CIO controls the IT funding, but even then someone always finds some money squirreled away and decides to use it for something they weren’t supposed to or in some cases even bypasses the money channels altogether, getting a freebie from a eager vendor looking to build or test some new capabilities to sell later to other customers).

Well, where’s the harm?

Oh my G-d, where should I start…

Innovation from the field and operators is great, but bypassing the CIO shop circumvents the structured processes and good governance that is in place to ensure projects succeed. Without these mechanisms, IT project can be at tremendous risk:

  1. Business Case—Without a business case, the justification for the IT project was never made, return on investment not calculated, alternatives not considered, and the best course ahead not properly laid.
  2. Investment Review Board—Without IRB vetting, the senior-level sponsorship has not been solidified, the project has not been authorized, and its priority has not been set with respect to other, maybe more critical, projects that the enterprise needs; further, the project may not have adequate life cycle funding; additionally, the project is likely not being ongoingly monitored and managed by leadership and enterprise subject matter experts for cost, schedule, and performance.
  3. Enterprise Architecture Review—Without an EA technical review, the IT project may align with the target architecture and transition plan, may not be interoperable with other systems, may not meet enterprise technical standards, may overload or be incompatible with existing infrastructure, may be duplicative of other investments, may not be the best or most cost-effective technical solution, may not meet various legal, regulatory, and other compliance requirements.
  4. System Development Life Cycle—Without following a defined, repeatable, and measureable SDLC process, the project risks failure by not having adequate and documented planning and requirements, design, development, testing, implementation, training, operation and maintenance, and disposition.
  5. Project Management Plan—Without a project management plan, projects are at risks for being mismanaged, having cost-overruns, schedule delays, and quality problems.
  6. IT Security Plan—Without an IT security plan, the project is at risk in terms of the confidentiality, integrity, availability, and privacy of the information.

No question, from an end-users perspective, there are quite a few hurdles to go through in implementing a new IT project. An if we’re honest with ourselves, the process can be onerous. Therefore, the CIO and his staff needs to work to streamline the processes, integrate them, provide the users with job aids and excellent customer support. Additionally, there should be a quick pass process for getting those “emergency” (must have now) projects through quickly (although not any less comprehensively).

The key is to balance the needs of the enterprise (ensuring mission execution and sound stewardship of enterprise resources), end-users (supporting innovation and operators ability to do their jobs successfully and safely), and customers or citizens (bringing new products or services to market quickly, reliably, and at high quality levels). To do this we have to balance the necessary processes and governance to ensure IT projects’ success with the imperative to foster innovation and deliver quality and speedily to market.

So as an enterprise architect, what do you do when a end-user asks forgiveness, instead of permission?


Share/Save/Bookmark

No comments: