In my previous Advisors in this series (see "The Mythical Business Case -- Part 1: The Limits of Rational Decisions," 8 March 2006 and "The Mythical Business Case -- Part 2," 12 April 2006), I put forward a hypothesis that the growth of uncertainty in modern business changes the rationale of IT investment decisions from a thorough business case analysis to simplifying heuristics such as "flocking

Despite our best efforts and advances in technology, we still have user manuals, and it seems that the vast majority are still poor. I am dismayed because some 20 years ago, I learned a way to write good user manuals. It is possible to have high-quality user manuals and user documentation and the benefits that come with them.

Visioning allows organizations to make statements about the future as they would like to see it. Visioning became popular about 25 years ago and was codified in a technique called "visioning and mastery." It remains a powerful tool for leaders. Two oft-quoted exemplary vision statements are John F.

In a recent Business Intelligence Executive Update (see "BI + Search = Discovery Reporting," Vol. 6, No. 8), I discussed the benefits and enhanced functionality that combining BI and search engine technology brings to BI. I also examined the initial products Information Builders Inc. (IBI) and Cognos introduced that integrate their BI platforms with the search capabilities of the Google Search Appliance and other search engines.

Every year at this time, I find it hard to concentrate. After the Cutter Summit conference, which usually happens early in May, I have so many ideas spinning around in my head, I have trouble sleeping. Too much of a good thing, I guess. The great thing about the Summit is that after a couple of years, you know that you're going to meet someone you didn't know who has some really good idea, or you find someone you've known for a long time but you haven't talked to for a while has been working on a really cool idea.

The art of risk management is the art of clairvoyance. Risk management is the ability to both foretell the future and to do something about it. Risk management has long been analyzed in the context of business financials, organizational behavior, project breakdowns, and individual perspectives and attitudes. In each instance, it has largely been focused on the risks of a given point in time and a given set of circumstances based solely on today's knowledge.

Experienced members of project teams are familiar with the concept of lessons learned, or project "post mortems." These are the discussions that occur near the end or after the end of the project when everyone is ready to move on to something else, but decide to get together to compile a list of things they wished they would have done differently or things they found out during the project. The theory is that these lessons would be recorded for future project teams to read, study, and integrate into their projects.

Despite the rapid growth of the Software-as-a-Service (SaaS) market, many enterprise decision-makers and application architects are still trying to figure out whether this new software solution model is viable and fits into their existing environments. This point was brought home during a Roundtable discussion during Cutter Consortium's recent Summit conference.

Last week I attended Cutter Consortium's 2006 Summit in Boston, Massachusetts, USA. As always, it was an interesting collection of people and presentations, which combined to create a thought- provoking atmosphere. The format of the Summit is unique, at least in my experience with IT conferences. Each topic is covered in a keynote presentation, which is followed by a panel of experts who discuss and debate the keynote and topic.

Successful projects have several common characteristics, including an active sponsor, engaged users, and an effective project manager. (Some projects might have these and still fail for other reasons, but I have never seen a successful IT project that didn't have these characteristics.) The most challenging criterion to fulfill is a sponsor -- and this is where many content management system (CMS) projects create the conditions for failure.

What is "best practice" for an engineering process? How good is your current set of development, maintenance, and service processes? How can we decide exactly which processes we are going to adopt in our organization, for example, in a CMMI implementation?

As the IT applications development business grows, the frequency of projects requiring multiple teams for their execution will also grow. In fact, with the added need for globalization affecting nearly every application, most, if not all, IT development projects will involve more than one team.

The recent revelation that the ultra-secret US National Security Administration (NSA) has amassed a gigantic database (some say it is the "biggest database in the world") covering "every call made in the USA" raises several privacy issues that are pertinent both to government and to industry.

How much do senior (nontechnology) executives know about IT? Not much, I would argue, and here's the worst part: they seem to know less and less over time. In fact, I believe that senior executives know less about IT today than they did 20 years ago.

In Part 1 of this Advisor (see "Organizational IT Asset Management Framework, Part 1," 4 May 2006), we wrote about the operational risk management framework for IT asset management (ITAM), which consists of a policy, standards, and processes. We conclude our discussion in this Advisor.

In the first in this series of Advisors (see "LoTech -- HiFi: The Evolution of Story Cards and User Stories," 23 March 2006), I stated that capturing stories in a malleable form is paramount to building a strong product backlog. I also discussed the use of a story wall as a simple way to see the project, along with various tools that can be used for organizing and tracking/planning with stories.

"If you want higher quality, build less stuff." That, in essence, is what Cutter Business Technology Council Fellow Tom DeMarco once said about a daring strategy for quality improvement: reduce quantity. Tom went on to say, "Whatever it is that your organization makes, make less of it. Make less, and choose much more carefully what you make" [1].

The good news is, Tom's advice is something that can be done immediately to reduce defects. Talk about being agile! Quality is inversely proportional to quantity -- simple as that.

As any software customer knows, it is extraordinarily important to spell out all of its rights in the license or development contract. The customer's ability to withhold payment, take possession of source code, or even terminate the contract, among other important terms, are usually spelled out in black and white.

One of the reasons that it is so hard to find enterprise data architects (EDAs) these days is that most of the training on database (or data warehouse design) is focused far too much on technique and far too little on basic concepts. And since most EDAs are taken from the ranks of DBAs, database models, or data warehousing experts, that means that the folks with experience haven't learned the basics.

In a recent Enterprise Architecture E-Mail Advisor ("EA Maturity Models," 15 March 2006), I introduced a variety of different models that are being used to evaluate enterprise architecture programs. Just like many EA programs that unfortunately go down the "EA for EA sake" path, we often take a "maturity for maturity sake" approach, forgetting that the maturity model is there for a purpose.

I'm hearing increasing talk (again) about how organizations need to extend BI capabilities to their rank-and-file employees. To date, however, most companies have found this "BI for the masses" movement difficult to carry out. True, the growing popularity of digital dashboards and scorecards have helped extend -- in somewhat limited fashion -- BI capabilities across the enterprise.

Just when I was beginning to think that the market's view of Google is far too optimistic, the company does something really smart: this time Google bought a company called @Last Software, which makes a product called SketchUp. This is quite a coincidence, since for the past five or six months, I've been telling all my friends that they really need to look at SketchUp because it is one of the slickest products I've seen for a long, long time with one of the most inventive user interfaces I've ever seen.

This Advisor is the fourth in a series on agile integration and the first on process (see Agile Integration -- Assembling a Team, 13 April 2006, Agile Integration -- Making Agile Work in Organizations, 2 March 2006, and Agile Integration -- Organization and Empowered Teams, 6 April 2006).

Many organizations have a policy for fixed assets; however, this policy is driven usually from an accounting perspective, not from the perspective of the operational risks associated with these assets. Controlling the organization's IT assets requires an operational framework that complements the accounting-based, fixed-asset policy.