It takes a lot of work to do charge-out of any kind. From our perspective, a simple corporate cost center, one not allocated at the end of the year to business units, is surely easier than any alternative. This means that business units and IT never argue about allocation formulas or usage. It also means that budget negotiations each year are simple, involving only the corporate budget process.

Although text-mining technology has been available for years, its use has been relegated mainly to government agencies (e.g., intelligence services) and companies whose business largely has to do with handling or processing textual information (e.g., news organizations, wire services). The major roadblock standing in the way of more mainstream business use of text mining technology has been the high degree of expertise and specialized skills required to build and use applications.

A rookie baseball player on a single-A farm team bobbles the ball and allows two runners to score. "He's learning the true finesse of the game," we contend, willing to forgive and forget. After all, it's not the major leagues. But management fires him. A multimillion-dollar star for the Washington Nationals bobbles the ball and allows two runners to score. We shout, "Fire the bum! I can't believe he's even getting paid for this!" It's just a game, and yet our reactions and behaviors are radically different. Does management "fire the bum?" No.

Thanks to 900-pound retail gorillas like Wal-Mart, suppliers large and small have had to relentlessly streamline and automate their operations. One such mandated business process is the Advance Ship Notice (ASN). This is a requirement for suppliers to provide their customers with electronic notification in advance of shipping their products. There are two main reasons for insisting on these ASNs:

1. In case of missed shipments, customers might want to execute alternate purchasing plans.

Sometimes, when I talk to managers in Germany, Austria, or Switzerland about agile, I get a reply like, "Well, this sounds very American, I doubt that it works in Central Europe." As a matter of fact, there is a growing list of successful agile projects in Central Europe, so the doubt obviously doesn't hold water. Nonetheless, the doubters have deserved more attention than this brisk reply. So I'd like to dig into agile and business culture in this Advisor. I'll discuss German business culture first, before generalizing.

In my previous Advisor ("Smart Sourcing: Where Do We Start?," 20 September 2006), I shared with you a simple yet very useful checklist for deciding who, what, when, and how to source your projects.

In my previous Advisor (see "Doing SOA Right Today, Part 1: Making Sure We're on the Right Track" 27 September 2006), I urged all fellow practitioners in the field not to embark upon SOA initiatives just because everyone else you know is pursuing the transformation of their existing business applications to Web ser

collaboration = innovation

Whenever the performance of a project falls outside nominal values, it will be judged to be a project in distress and likely to fail unless some intervention strategy brings it back under control. How it got to that state is certainly a question that needs answering. But more important is how it can be returned to a state of normalcy -- if at all. A distressed project will have one or more of the following characteristics:

Oracle Corporation announced it bought data integration vendor Sunopis SA for an undisclosed amount. But Oracle already has a pretty good data integration toolset: Oracle Warehouse Builder (OWB). So why is Oracle buying Sunopsis?

Recently I argued with some colleagues that the real changes in technology over the past few years have more to do with what no longer matters than anything else. Before I say anything more, this is not an endorsement of Nicholas Carr's now way too famous "IT Doesn't Matter" argument. For the record, I have consistently maintained that operational technology matters a little less than it did but that strategic technology matters more than ever. That said, let's look at what no longer matters operationally and even strategically.

This is the last Advisor, for a while at least, in my series on agile integration. In writing this series over the last few months, I've done a little revision to the categories -- folding compliance into the governance category and creating a performance category. The six categories of agile integration are now: organization, process, performance, alignment, governance, and culture. This Advisor addresses the last of these: culture.

In my last Advisor (see "Foreseeability: Planning for Risk, Part 1," 21 September 2006), we explored a new way of conceiving project risk; how foreseeable is it? To the academics who studied project execution patterns in a dozen plus companies, they concluded that project elements occupy space within four categories of foreseeability risk. The least dangerous and most visible risks, examined in the last Advisor, fall into the categories of variation and foreseen uncertainty.

Although many organizations have successfully outsourced various IT functions for years, reports of outsourcing "failures" (like early termination, significant renegotiation, and unrealized value) still abound. Fortunately, both buyers and providers are getting more adept at diagnosing and addressing their outsourcing problems.

In February, I wrote about service component architecture (SCA) and service data objects (SDO) (see "Service Component Architecture," 1 February 2006, and "Service Data Objects," 15 February 2006), which are emerging specifications for how services can be written and assembled in an industry-standard way. At that time, eight companies had joined together to create and support these specifications. Let's see how this effort is progressing.

In February, I wrote about service component architecture (SCA) and service data objects (SDO) (see "Service Component Architecture," 1 February 2006, and "Service Data Objects," 15 February 2006), which are emerging specifications for how services can be written and assembled in an industry-standard way. At that time, eight companies had joined together to create and support these specifications. Let's see how this effort is progressing.

This Advisor is about my adventure in getting to a creative solution for a tough problem. My recent work has been to architect, design, and code in Java an extremely fast, very high-speed data structure to represent complex networks. There have been many different designs and data structures for software implementations over the years and trying to beat the state of the art can seem unattainable.

The recently published Association for Project Management Body of Knowledge (5th edition) features 52 topics required for the successful management of projects. The last of these topics describes the area of "professionalism and ethics." The inclusion leads to an obvious question: namely, should we as project managers care about being professional?

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!

I've been hearing more and more about companies establishing "BI centers of excellence" (COEs; also sometimes referred to as "BI competency centers") in order to provide advice and experience with implementing BI techniques, applications, and products throughout their organizations. Several issues are fueling this trend, including corporate BI tools standardization initiatives as well as the move to distribute analytic capabilities across the organization to different classes of end users.

Each time IT explores a new domain or business area, it is inevitable that we have to develop a new set of tools to support that methodology. For example, relational database development spurred the development of entity-relational diagrams (ERDs) and object-oriented design spurred the development of object-class diagrams. Each of these environments required the development of new tools appropriate to the job at hand. But while new domains ultimately require new tools, our first instinct is to reuse existing tools and adapt them for the new domain.

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.