I recently worked with a company that would like its technology professionals to become better partners with its internal business clients. A great objective, but several of the participants in the workshop I was running noted that they needed partnership training, that it wasn't so easy to just become better partners.

In my last Advisor (see "Collaborative Leadership Basics, Part 4: Keys to the Boat -- Generating Positive Interdependence in Groups," 5 October 2006), I offered four keys you can use to get people feeling and acting like they are in the same boat together.

The year 2007 portends to be a very contentious one for US corporate governance, which may have implications around the world. Both Congressman Paul Sarbanes, a Democrat from Maryland, and Congressman Michael Oxley, Republican from Ohio, are retiring from the US Congress this year.

The offshoring conventional wisdom at hand is that the first wave concentrated on cost reductions. The second wave will concern itself with core competencies; those business processes that contribute to a distinctive advantage in the marketplace are core competencies that organizations would do well to keep in house. Those processes that are not central to company business or that the organizations do not perform well are candidates for offshoring. This statement is far too broad to take at face value.

Enterprise architecture, as with many other approaches or methodologies, is sometimes perceived as yet another buzzword or promise of paradise for managers, although not for operational workers for whom it may frequently be something abstract, incomprehensible, remote, and perhaps potentially dangerous. Among the few companies that have begun their struggle with EA implementation, only a minority can be described as really successful.

Practically every client we work for admits, sheepishly, that they do not examine the business impact of projects after implementation. There's no post-implementation audit, apparently. They're too busy doing new projects. Given that companies spend a lot of money and attention on IT projects, this seems strange. Shouldn't we be assessing the actually realized return-on-investments (ROI) for projects?

Well, sure. But what's the point?

Engineers and technical people should attend budget and other business meetings. Five years ago I wouldn't have entertained that thought. Now I believe it strongly. Without the technical knowledge, I have seen people make decisions that no one would think possible.

After we've done a risk assessment, we should begin to develop management plans for the highest-priority risks. There are four general approaches that can be used to manage any particular risk.

De facto, this is what you do if you do not do anything else. It is appropriate for low-impact risks that are not worth actively managing. And for some very high-impact risks, it may be the only available course of action.

In February, I discussed the convergence of the "two BPMs": business PROCESS management (BPM) and business PERFORMANCE management (see "Merging the Two BPMs: Opportunities Abound," 21 February 2006).

When people ask me when I first became interested in enterprise architecture (EA), I tell them that I've always been interested in really large systems problems, but it was probably when I first began to work on Data Warehousing that I came to understand the essence of EA. My reading of data warehousing history is that the discipline goes back to some IBMers working in Europe in the early/mid-1980s.

In my last Advisor on agile cultures (see "Agile Integration -- Culture," 12 October 2006), I touched on the concept of open information and wanted to expand on that -- especially the difference in looking at information as an "excuse" versus an "early warning." There is an old project management axiom that states, "Bad news gets worse with age," which admonishes project leaders and others on a project team to surface bad news early so that management (in conjunction with the team, we hope) can decide on

Homeland security focuses on preventing catastrophic terrorist attacks and responding to major disasters -- and reaches out to the private sector for partnership in securing the economic enterprise. Yet the ability of companies to be effective in helping to manage high-end events depends, in large measure, on the agility, flexibility, and resilience with which they are able to deal with more probable and far less catastrophic business disruptions.

One of my insurance industry clients decided to leverage a global sourcing model in building its new billing system. The CIO instructed her direct reports to focus on three major elements of the model: (a) collaboration across the extended enterprise to promote seamless interaction among internal and external resources, (b) optimize return on existing investments and the cost of ownership, and (c) deliver quantifiable business results each time and every time.

In October, OASIS (Organization for the Advancement of Structured Information Systems) approved the Reference Model for Service Oriented Architecture V1.0. A lot of people have been asking what it is, what to do with it, and how it will impact their SOA initiative.

The reference model document itself states:

In parts one and two of this series (see "Evaluating the External Technological Environment," 26 July 2006, and "Evaluating the External Technological Environment, Part 2: Digging Deeper into the Competitive Landscape," 30 August 2006), I suggested that there are three aspects to the external technological envi

IT-enabled business transformations occur when technology is used to fundamentally alter the way business is conducted in an industry. The organization that successfully implements the industry-altering technology can gain a competitive advantage so profound that others in the industry can no longer compete and either go out of business or, upon implementing "me too" technologies, find regaining customers to be extremely difficult.

By far the biggest news out of the Oracle OpenWorld Conference was Oracle's announcement that it will "support" Red Hat Linux. Just in case you missed this bombshell, the new "Oracle Unbreakable Linux" will be almost exactly like the open source operating system (OS) distributed by Red Hat. The main differences are that Oracle will strip the Red Hat trademarks from the software and Oracle will offer support services for about half of what Red Hat charges. Oracle also says it will support older versions of the OS.

It's hardly news to anyone that innovation in software represents a competitive necessity for vendors and a source of performance improvement and even competitive advantage for the organizations that invest in it. Open Source software development models are grabbing the attention of managers from both populations, as these arrangements can accelerate both innovation and performance improvements; Open Source might represent the single most fascinating trend in enterprise software going forward.

Where are we going and why? These are simple questions that should be answered at the start of every project and are, at least in theory, answered by the stakeholders and sponsors rather than by the project team itself. A problem arises when the team doesn't own the mission and the goal -- then what gets delivered never matches the desired result.

All big failures look alike.

-- Ken Orr

In the first part of this Advisor (see "Who Says IT Staff Can't Manage Outsourcing Deals? Key Skills for Outsourcing Professionals, Part 1"), I asserted that relationship management skills, such as skills for negotiation, collaboration, and communication, are an outsourcing professional's cornerstone skills. Yet these types of skills are typically underdeveloped among functional professionals.

There's been a lot of talk lately about Web 2.0 and Enterprise 2.0. There's been even more talk around why the heck there's so much talk -- as both terms have achieved overhyped buzzword status. But underneath all the hype there is some fundamental value.

In this Advisor, I relate my experience of two situations in which I observed that the effective use of earned value management (EVM) can make a difference in business-IT alignments.

In a perfect world, the process of software development should consist of a series of appropriately selected steps, each of which clarifies some aspect of the system as we proceed from inception to deployment. Done properly, there should be no "and then a miracle happens" steps along the way, as can occur when we dive right into the code after throwing together some concepts on the back of an envelope.