Even after five years and many papers, the Agile Manifesto principle of "Working software over comprehensive documentation" is misunderstood. What any organization strives for is understanding, not documentation, and that understanding comes from a transfer of knowledge. Furthermore, knowledge transfer occurs within a context; a context that is often complex.

What would it take to shut down your project intentionally? What state of nature would be required to actually drive you to formally terminate it? The unfortunate thing is that most project managers don't have an answer for that question, and the organizations that support them don't have the information either. All too often, we don't have a clear definition of an approach, terms, and process to shut down projects, which puts the organization at risk for continuing projects that are no longer profitable or that no longer serve their original intent.

What would it take to shut down your project intentionally? What state of nature would be required to actually drive you to formally terminate it? The unfortunate thing is that most project managers don't have an answer for that question, and the organizations that support them don't have the information either. All too often, we don't have a clear definition of an approach, terms, and process to shut down projects, which puts the organization at risk for continuing projects that are no longer profitable or that no longer serve their original intent.

A service-oriented approach helps in comparing and evaluating alternative implementations of the same service and choosing the best one. The organization is decoupled from vendor lock-in. This leads to much better control of the provider relationship, with consequent business benefits. These benefits often center on cost reduction.

In my last Advisor (see "OASIS SOA Reference Model," 1 November 2006), I described the OASIS Reference Model for SOA as a set of fundamental concepts about services and service orientation. The Reference Model document talks about these concepts being the basis for a "reference architecture." To add fuel to the fire, Accenture recently announced the Accenture SOA Reference Architecture and other consulting organizations are expected to follow suit.

A friend of mine was recently hired as a CIO by an association representing trade union members in the northeastern US. One of the most astonishing discoveries he made in becoming acquainted with the organization was the certainly obscene amounts of money paid to consultants for all sorts of menial tasks. He soon figured out why this situation existed and it reminds us what is the right and wrong culture in which to cultivate and manage a disciplined IT organization.

While wrapping up the semester's work, one of my executive MBA students challenged me: "Sure, all of this technology stuff is good -- and powerful -- and might even contribute to the business, but when all's said and done, politics determines what gets funded and what gets killed, what the company does and what it doesn't do. Good arguments are nice, but they usually fall on deaf ears.... I'd rather play golf with the boss than work my tail off writing the 'perfect' business case."

Does politics explain what happens -- and what doesn't?

You'll notice that I've shamelessly put the term "SOA" right at the beginning of the title of this Advisor. I'm as eager to attract attention as the next guy, and these days SOA is a near-irresistible little acronym. Any conference, organization, Web site, or product line that promises help in getting up to speed on "service-oriented architecture" is guaranteed an avid audience.

In our survey covering the use of open source software for data warehousing and BI, conducted last April, I noted that 14% of end-user organizations surveyed indicated that at that time they were using open-source databases for (target) data warehousing and data mart databases. Another 7% said they planned to do so within the next 6-12 months.

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