In my last Advisor ("Collaborative Leadership Basics, Part 3: Get in the Same Boat Together," 31 August 2006), I suggested that "outcome interdependence," or the feeling of being in the same boat together, is the number-one predictor of successful collaboration and teamwork.

In retrospectives on corporate failures, not surprisingly, strategic failure typically outranks operational failure as the primary cause -- often by a factor of two to one. Business history is littered with corporate carcasses marking a company's inability to deal with changes in its markets. As enlightening as corporate strategic failures are -- as engineering professor Henry Petroski notes, we learn to succeed by understanding our failures -- corporate strategic successes are also sources of useful lessons learned. Here is a short story of one of them.

So, you want to avoid the offshoring lay off axe? Then become the person who manages all the offshoring initiatives in your organization.

So, you want to avoid the offshoring lay off axe? Then become the person who manages all the offshoring initiatives in your organization.

In May, I wrote an Advisor titled "The Convergence of BPM and SOA Continues" (3 May 2006). Little did I know that it was only the beginning. The pace of consolidation has increased significantly in recent months in the SOA, BPM, and combined markets. Let's take a look at some of the highlights.

A client recently asked how to assess the effectiveness of their IT organization. We immediately responded: does the IT organization add value to the business? Of course that's the right question -- but exactly how does one go about getting the answer?

American football teams spend many hours reviewing films of their own games, as well as those of their opponents. They analyze what worked and what didn't, who made mistakes and who performed well. They incorporate that analysis into their preparation for the coming game.

The other morning, over coffee, I was talking with several folks about the predicament that the big US automotive manufacturers General Motors and Ford now find themselves in. Simply put, GM and Ford are in trouble because sales of their SUVs, pickups, and other large vehicles have declined considerably. Some defined it as a forecasting problem. Others said it was faulty data analysis, and asked me why Ford and GM's BI folks failed to predict the shift in consumer sentiment to smaller, more gas economical cars.

Back in 2003, I wrote about the use of intelligent video systems for adding automated, real-time threat detection, identification and alarming capabilities to closed circuit television cameras for security applications (See "Intelligent Video Surveillance for Security Applications," 30 September 2003). Since then, there have been a number of new developments regarding intelligent video systems.

Business process management (BPM) is a category of software application sweating from the heat generated by the spotlight of attention. No surprise when you consider the importance of managing, refining, and reengineering the very business processes that multimillion-dollar enterprise software automates. As BPM software evolves, the best of this class of application is likely to blossom into multiple points of functionality. Stay focused on the following functional modules as the bare minimum needed to constitute BPM software that offers any real value:

"Time after time" goes the song by Cyndi Lauper. Scheduled time has been a pervasive theme in software development projects and, in fact, for all projects. But what time are we really talking about? What defines late? Is time the most important control measure? This Advisor will explore three distinctly different "time" perspectives: planned versus actual, elapsed, and schedule performance. Each of these places a different perspective on "time." So our song might be "time after time after time."

As I wrote several weeks ago (see "Losing Your Reputation," 27 July 2006), Airbus announced a second major delay in its delivery of the Airbus A380 super jumbo. This past week, Airbus announced yet another delay, which, to say the least, hasn't pleased its customers. Instead of delivering 25 Airbus A380s in 2007, Airbus may be lucky to deliver just 4.

When you came to work today, did you encounter a big surprise? A reall-lly BIG surprise with a major program initiative? If not today, did it happen yesterday, or last week, or last month? Is it one that may cost significant time, effort, and money to resolve? Anyone who has worked on major IT programs for any length of time in their career has experienced, or will encounter, that inevitable day when their best-laid plans have gone awry!

Back in 2002, when I wrote the Executive Report "Transitioning Business Application Components to Web Services" for Cutter Consortium's Enterprise Architecture advisory service, I described service-oriented architecture (SOA) as a next big thing.

This is the first in what will be a series of Advisors on elements of working together that we can think about systematically and productively. I'm indebted to other members of the new Cutter Innovation Practice: Rob Austin, Shannon O'Donnell, and Erin Sullivan for all sorts of help.

Several years ago, a company whose software was used by other companies in the semiconductor industry to design complex integrated circuits scheduled its annual strategic business planning offsite retreat. The company was one of two dominate players in the industry and, by itself, accounted for more than one-third of integrated circuit design software sales. Its main competitor had a slightly larger share of the market, with the remainder of industry sales being shared by a host of smaller, niche market competitors.

Over the past year, I've seen a lot in business technology discipline (or not). I spent a day at a large enterprise where they explained how they had implemented 11 ERP systems and multiple instances of them. When I got up off the floor and promised them huge savings by reducing the variation in their back-office environment, they told me that they really weren't interested in the savings because they would require too many meetings, too many arguments, and -- well -- just too much discipline.

The other morning, over coffee, I was talking with several folks about the predicament that the big US automotive manufacturers General Motors and Ford now find themselves in. Simply put, GM and Ford are in trouble because sales of their SUVs, pickups, and other large vehicles have declined considerably. Some defined it as a forecasting problem. Others said it was faulty data analysis, and asked me why Ford and GM's BI folks failed to predict the shift in consumer sentiment to smaller, more gas economical cars.

In my last couple of Advisors (see "Working Around the Delete Key, Part 1," 24 August 2006 and "Working Around the Delete Key, Part 2: What Are Our Users Really Doing?," 7 September 2006), I've commented on how inventive human beings become when working around perceived problems with their systems.

"We would like to do agile but we cannot go because we need documentation for the FDA/SOX/..." is one of the statements I frequently hear after talks, panels, or in client conversations. This is a popular misconception about agile, which I'd like to clarify in this Advisor.

The concept of uncertainty is another way of defining project risk (including IT), insofar as risk is defined as those uncertain factors that can measurably and negatively impact project performance and undermine the outcomes sought. Historically, uncertainty has been identified and analyzed by its source: technical, people, financial, and so on. A completely alternative approach exists in thinking about uncertainty as the central characteristic of risk, an approach involving the foreseeability of risks.

Most IT practitioners today are well acquainted with the concepts, benefits, and pitfalls of offshore outsourcing. Furthermore, most companies, IT or non-IT, have used some form of sourcing since the early days of the information age.

A recent development that should help accelerate the adoption of service-oriented architectures (SOA) is the introduction of repositories and registries for cataloging and managing services and their associated artifacts. Over the past few months, several vendors have announced such offerings, including IBM, BEA Systems, and WebMethods.

Team captains in sports arise from natural leadership skills that key players use to bring the entire team up to a new level of play. A team captain is not necessarily the quarterback and is certainly not the coach or the general manager. The captain rallies the team in tough times. During some particularly tough times at Pages Software, Bruce Henderson, one of the senior developers, roamed the halls, wise-cracking and generally encouraging the rest of the team.

In the first two parts of this Advisor series (see "Errors, Mistakes, and Awareness, Part 1: Errors and Mistakes," 16 August 2006 and "Errors, Mistakes, and Awareness, Part 2: The Cost of Failures," 30 August 2006), I defined terms to clearly distinguish the causes and effects of human error in creating software. In this part, I shall examine how and when we notice errors.