Archive for the ‘IT Governance’ Category

The Cost of Making Decisions

September 25, 2009 Comments off

How much does a decision cost to make? Do we know? Do we care? The time and money spent analyzing options must be considered against the overall risk of the decision. Failure to understand the risk and cost will result in less value realized for each decision.

For example, consider an investment decision of $50,000. In justifying this amount, how many hours of time should be consumed in analysis? If we assume $50/hour cost of time (for easy math), 1,000 man hours matches the entire risk of the decision. It would have been less expensive for the decision to be made blindly!

How much should we spend? I suggest a general rule as 10% of the risk. For the above example, this would be no more than 100 hours. After which it should be put to a Go/No Go decision. This reduces the true total investment to $55,000 rather than $100,000 in the example.

This practice is often described as analysis paralysis for projects and new products. But this is also important, but far less visible, in the day to day decisions in a business. How much time money do we spend talking about decisions and when should we just commit?

Categories: IT Governance, Leadership Tags: , ,

Knowledge and Documentation

September 24, 2009 Comments off

A few days ago, I presented the Lessons-Learned and Risks for a completed project. I made a point that because I was the lone developer on this release, that there significant risk of knowledge loss in the organization.

“So you’re saying the system was not well documented?” asked a senior manager.

CLIPART_OF_17601_SM_2“The system is documented appropriately,” I responded, and attempted to articulate the difference between explicit and tacit knowledge. In any complex system, software or otherwise, documentation and manuals are no substitute for true experience with its operation.

Explicit knowledge is everything that can be written down and understood on its own merit. Things like system architectures, class diagrams, and error codes are all examples of this. And I don’t mean to minimize their importance. Any supportable system should include well written documentation at the hands of those who support it.

But there is a significant mass of system knowledge that cannot be explicit – it can only be learned through experience. This is tacit knowledge, and it is a major challenge for many organizations, including my own.

I do not yet know how to solve this problem, but the first step is clearly to educate others that it exists.

Bookmark and Share

Guaranteed Mediocrity

April 27, 2009 Comments off
I have long been an advocate of replacing large, complex IT processes with many small flexible ones. A colleague of mine shared this video with me from Barry Schwartz at the TED conference, discussing how processes and incentives are “put in place to protect against failure, but only guarantees mediocrity.”

While watching this video, think of the people in your IT organization that go through Change Management, Product Development, or Project Management processes, and ask yourself if they are as morally wise as Mike the Janitor.

Bookmark and Share

Build for Competitive Advantage; Buy for Competitive Parity

February 20, 2009 Comments off

This  is a well-known business mantra. If WalMart competes based on its supply chain, then it shouldn’t outsource its supply chain to FedEx. Alternatively, Family Dollar, or other companies in the retain industry, may have a reason to outsource logistics if that is not how they intend to compete.

This philosophy is not always properly reflected in the world of IT. IT architecture and priority decisions must follow the strategy of the company:

  • Build applications that enhance or automate a process that is a competitive advantage for the firm.
  • Buy applications that only need to provide competitive parity for the firm.

For example, Walmart should (and probably does) build their own logistics tracking and forecasting applications, while they probably purchase their HR management tools.

For every IT project, this distinction should be clear.

Bookmark and Share

US Government Spending on IT Services

February 16, 2009 Comments off

I recently conducted an extensive case study of the US Federal Government’s spending on IT services as a part of my graduate studies. It includes a summary of the market, how it is segmented, and opportunities for expansion. Here is a snippet from the report:

Market Overview
The market for IT services in the US Federal Government is over $68 billion in 2009 and continues to grow at 5% annually. IT demand from the government is segmented between two very different concerns:

  • Defense information and intelligence systems
  • Line-of-Business application deployments

These concerns, and the skills required to deliver them, segment this market as shown in the figure below. Defense suppliers specialize in the design and deployment of the advanced custom systems market segment, which is over $32 billion in revenue annually. The handful of suppliers competing for a single buyer of services creates a monopsony and significant cooperation between the suppliers.

US Government IT Market Segmentation

US Government IT Market Segmentation

The commercial IT market for Line-of-Business applications, which primarily serves the civilian agencies of the government, has a far larger customer base that includes companies around the globe. This creates intense competition on cost and efficiency in the delivery of these standard services.

I am offering up the report free for non-commercial use to anyone who finds this interesting or valuable. If you find inaccuracies in the report, or if you would like to discuss this topic further, please leave a comment!

You can download the full report here. Enjoy!

Bookmark and Share

Building an IT Standards Framework – Part 1

August 19, 2008 Comments off

When we set out on the journey towards an Enterprise Architecture two years ago, we had very few documented “Standards” in the organization.  We saw this as one of our key issues to reduce the complexity of our IT operations and simplify the enterprise architecture.

What is a Standard? For every 3 experts we asked, we got 4 opinions.  We chose to define a standard as the top level record for any information regarding the process, practice, implementation, or use of a technology.  Specifically, a standard would fall under one of the following types:

Technology Standard
Defines the use case, capabilities, and implementation constraints of a particular technology

Process Standard
Defines a business or IT process flow, checkpoints, inputs, and outputs.  This is technology independent.

Design Principle
High level principle that guides the use, implementation, and design of processes and technologies.

Target Architecture
The desired target state of an architecture.  This involves both the technology and process aspects of the architecture, and governs the direction that changes will occur in those systems.

How do we create, approve, and govern standards? To begin defining and documenting standards in the organization, we created the Architecture Standards Council (ASC).  The ASC was composed of eight representatives from the relevant technology and business backgrounds and was responsible for the review and approval of standards.

The creation of these standards was left to individual teams or projects when the need arose or was forced upon them.

Governing the use of standards was left to Enterprise Architecture.  Each project architecture was reviewed and measured based on its compliance with the documented standards.  If no such standard existed, or one was violated, EA would refer the project to the ASC for approval.

This process has been running for a year at this point and has been received with moderate success, but we have room to grow.

What lessons did we learn?

  • [GOOD] Putting the control of standards (and their deviation) outside the boundaries of Enterprise Architecture was a good decision as it increases the feeling of inclusion for the rest of the organization.  It also prevents Enterprise Architecture from being perceived as an “Ivory Tower”.
  • [GOOD] Creating a single organization and process for review, approval, and governance of all standards across the organization leads to better communication between groups.
  • [BAD] ASC does not have the time commitment to define and flesh out new standards, leaving that role up to projects.  This slows down the execution of projects, forcing them through extra beaurocracy.  We need to have a process to submit a request for a new standard to be defined outside of the restrictions of a current project.
  • [BAD] Standards were not analyzed on the ROI of their compliance, nor were they reviewed by the IT Management team.  This led to the creation of unfunded mandates from the ASC, expensive tasks for projects and teams with no funding to execute them.

What’s next? I am currently defining “ASCv2” to address these problems.  In the next post I will outline the next iteration of my Standards Framework for the organization.  Stay Tuned!

Bookmark and Share

Categories: IT Governance Tags: , ,

Government of IT Governance

July 29, 2008 Comments off

Effective IT Governance is critically important to the success of an Enterprise Architecture Program.  Governance provides the mechanism to align the delivery of IT projects to the enterprise strategy defined through EA.

In modeling the IT Governance process in my current organization, we looked for inspiration from middle school Civics, the US Government Model.  We separated the duties of IT Governance into Legislative, Executive, and Judicial.

Civic Governance Model

Civic Governance Model

The Legislative portion of IT Governance includes our representatives with the business units to determine the business’s requirements and priorities.  The “lower house” is the Standards Council to set the detailed technology standards used for delivery.  This has been very good for us in putting the standards approval body outside of Enterprise Architecture, it removes the “Ivory Tower” perception that often comes with an EA team.

The Executive branch is responsible for the delivery of solutions that meet the business priorities and technology standards.  This consists of the approval bodies in Change and Project Management.  This puts the burden of enforcement away from Enterprise Architecture into existing and established governance bodies.

The Judicial branch in this model is the Enterprise Architecture Board itself which reviews the architecture of all solutions to guarantee alignment with the strategy and standards of the organization.  It acts as the “conscience” of the organization to do the right thing the first time.

There are also a number of checks and balances between the three branches, such as EA Chairing the Standards Council.

I am spending quite a bit of my time in this space lately, working to mature the IT Governance processes.  So far the government model has worked quite well for us as both a guide for the process structure and as a convenient way to communicate the process out into the organization.

Have any other Enterprise Architecture programs implemented a different take on the governmental model?

Bookmark and Share