Attached is the presentation, build scripts, and hudson jobs demonstrated. Hit me back with any questions.

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?

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

“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.

Unlike in many industries, the fight in most IT groups is in how to get things done, not how to avoid work. IT pros will self-organize, disrupt and subvert in the name of accomplishing work.

The challenge opportunity for IT leadership is to empower (trust and respect) the talented people in their department to focus on getting work done – and less on the absurdities of day-to-day bureaucracy.

TOGAF 9

Carsten Molgaard over at the Rasmussen Report has an excellent overview of the newly released TOGAF 9 framework. I have never dived in depth with the TOGAF Framework, as most of my references have been back to Gartner. Carsten makes an excellent point to not focus too much on the “framework”. Use TOGAF as a collection of content and process templates.

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.

What does Google get for this?

Google pioneered a new form of search advertising that is more effective at driving conversions (customers buying something) than any other method of advertising. It is effective because when a user conducts a search, unlike watching TV or even viewing a webpage, the user has provided intent to discover a product or service.

When I’m watching Hero’s, have I shown intent to buy a new car?

When I’m reading the newspaper, have I shown intent to buy groceries?

When I search Google for appliances in Minneapolis, I have shown intent to find (and perhaps buy) appliances in a specific city.

Last week, I, along with my study group, prepared a delivered a presentation on this topic to the Management of Technology program at the University of Minnesota. Below are my slides from that presentations. Enjoy!

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

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!

More generally, IT organizations need to recognize the importance of people in our architectures. What good is a password if people will write it down? What good is a workflow if people are still printing and signing forms? What good is an ERP system if the numbers are still manipulated by hand?

Every project should include not only a technical understanding of what is being implemented, but also an understanding of the business processes and people that will operate in the system — both users and administrators.