This past weekend, I presented Continuous Integration with Hudson and NAnt at the Twin Cities Code Camp. Thanks to everyone who attended!
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?
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.
“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.
Earlier this month, Jeff Ello over at Computerworld wrote an excellent piece on the Unspoken Truth About Managing Geeks. I think he very elegantly described some of the disconnects that often exist between technical staff and technical leadership.
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.
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 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.