Users are not interested in programs. If they are, it is our fault. What users want is systems that produce needed outputs with the minimum of additional input and with the maximum of integration (or the ability to integrate) with other systems with which they share data.

There are many reasons that a company decides to outsource -- from the need to increase productivity and improve service quality to provide a faster response and focus on its core business -- making the transformation from a tech-focused IT organization to an area deeply involved in the business decision-making process and contributing to meeting the business objectives at the same time. Other reasons include labor tactics that consider the staff size, training, and the cost of human resources for organizations.

According to a recent Cutter Consortium survey (see Cutter Benchmark Review, Vol. 8, No. 2), executive management teams are not all that happy with what they are getting from their IT investments. This dissatisfaction appears to be a result of several things:

In the first article in this series (see "How to Talk to Architects, Part I: The Enterprise," 28 May 2008), we discussed the issues involved in communicating with architects. Although it doesn't always seem so, architects are not that different from anyone else.

If you've ever tried to prepare and serve a beloved family recipe for a large group -- say 25 people or more -- you've experienced the fundamental problem of system scalability. Processes and facilities that work fine at one level break down totally when the quantities are multiplied by 5 or 10 times. Ingredients don't mix properly, your pans or oven may be too small, cook times vary, and even if all goes well in the kitchen, the dish may be cold by the time it is served to most of the guests.

Last week (see "And the Best Data Integration Technique Is ..." 10 June 2008), I said that the debate about which data integration technique is best for BI is irrelevant, because most midsize and larger organizations are going to require a variety of data integration methods to support their BI and other decision support needs.

"Many project managers (PMs) still find the complexity of planning and delivering projects in a constantly changing environment often requires competencies that their formal training has not equipped them with," notes guest editor Rob Thomsett, in the May 2008 issue of Cutter IT Journal's call for papers.

Last year, I started introducing agile development to a highly innovative company. They are world-market leaders in their domain, and it's basically their technical expertise they hold responsible for their position.

Almost every organization has data problems. These problems can be grouped into two categories. One type of problem is having redundant, inconsistent, and often plain-wrong data. The other type is not having easy access to the data. From the inception of the data warehouse (DW), the objective of building a DW has been to solve both types of problems.

A recent Cutter Consortium survey focused on a very important and timely topic: enterprise agility. Enterprise agility calls for structuring the unstructured, for institutionalizing improvisation. It requires that the organization become adept at reacting with speed and precision to changes in the competitive environment, customer needs, and any other change of significant magnitude.

There is an evolving field of consulting expertise built around guiding other consultants in how much they should charge for their services. At once known as "value-based billing," "value-based fees," or some other meme that will likely include the word "value," the thinking around this consulting domain has grown sophisticated enough that some of its principles are highly applicable to IT organizations and the posture they present to their organizations.

Many others and I have written about the necessity for enterprise architecture (EA) to be business-driven. When EA is not firmly grounded in the nature and shape of the business that it is to serve, it is common for a lot of time and resources to be spent on efforts that don't ultimately advance the goals of the business.

"Dwayne, you're good at taking an existing project and executing it. Jim is good at creating projects. I feel it is the best thing to team the two of you."

This is what a senior-level manager named Patrick told me late one afternoon several years ago. I am sure he meant this as a compliment -- something to inspire me on a new job. I felt crippled and left the job within a month.

Where did we disconnect? What happened? What can we learn from this?

There seems to be an ongoing debate as to which data integration technique is best for BI: traditional data warehouse, "dynamic" (i.e., real-time) data warehouse, customer data store, enterprise information integration (EII), or real-time data broker. And the answer is: all of the above. In other words, this debate is pretty much irrelevant.

The most popular Web 2.0 technologies used by organizations to support their business performance management initiatives are wikis and social networks. This finding comes from a January 2008 Cutter Consortium survey of 101 end-user organizations worldwide, which was designed to measure the extent that organizations are implementing business performance management technologies and techniques.

One big difference between traditional and agile project management is the one between a focus on value and a focus on scope. Value is an outcome. Scope is a characteristic that may help produce value, or may not. Neither a requirement nor a story is valuable unless put to use.

There was a report in the Wall Street Journal a few weeks back (see "Analysts Again Are Too Optimistic") about the Standard & Poor's (S&P) 500-stock quarterly earnings index, which missed analysts' expectations for the third quarter in a row.

My friend and colleague on the Cutter Business Technology Council, Lou Mazzucchelli, recently sent around an article that was posted on Ars Technica titled "The promise of Google Apps includes a shrinking IT staff," by Nate Anderson. Anderson writes:

The services area is about both saving money and making money. The key message here is about variety. Whereas just a decade ago there was a limited set of well-understood service packages -- help desk support, data center management, and customer service centers -- today, there's a complete range of services provided by a large number of skilled vendors.

In my last Advisor (see "EAD: The Architecture of the Customer Experience, Part 5," 7 May 2008), I explained how customer interviews, observations, and surveys could help firms understand which parts of the customer experience are in need of repair.

I really love maps. I'm something of a map freak. When I was a kid, my folks got me an encyclopedia that had a volume called "Places and People," and I spent whole summers browsing the maps and pictures, trying to get the relationships of those maps and the rest of the globe clear in my mind.

Getting a group of people to move together toward a common objective is never easy. As a project manager dealing with teams of people, each of whom represents different constituents, comes from a different point of view, and is trying to pursue a different set of interests, your task is formidable indeed. Project managers often focus more on task management than on leadership and on keeping track of deliverables and milestones rather than on building relationships and negotiating with their team members.

Organizations are applying a range of analytic techniques to support their business performance management initiatives, according to a January 2008 Cutter Consortium survey of 101 end-user organizations worldwide, which was designed to measure the extent that organizations are implementing business performance management technologies and techniques.

Every company needs to establish policies to provide the necessary governance for legal, financial, security, and basic operational reasons. For the most part, employees do their best to follow these rules, or they try to work through "the system" to change them if necessary.

One of agile development's touted benefits is better early information on project problems and issues. This early detection enables management -- project and otherwise -- to take adaptive actions. However, early problem detection comes with its own problem: discomfort with early information.