Imagine a perfect world where everything works just fine -- all goes as planned and nothing goes off track. For a CIO attempting to deliver business solutions in today's IT world, there is no such thing as a perfect world. Most CIOs and other practitioners involved in making business decisions willingly agree on one thing: change is the only constant fact in their world.

Let's anticipate where we'll all be in 10 years and then try to figure out how to get there. As more technology becomes commoditized and continues to deliver reliable, secure, and "always on" services, the role it plays in the early 21st century will continue to change dramatically. Twenty years ago, we said it was all going to be about the data; 20 years from now, it's all going to be about information, knowledge, and the intelligence they enable.

It does us no good to look for enemies in software development, or even victims to be protected from the enemies. When we presume there is a Them that is somehow set against an Us, we are already subtly creating a barrier that creates Them. We are alienating people, which is rarely helpful. We may not realize we are doing it, but the damage (and missed opportunity) is still real. Unfortunately, the early years of the agile movement have been divisive -- full of battle lines of one kind or another. Many of us have artificially divided software development into "agile" and "not agile" -- as if agility were somehow binary.

It has sometimes been said of the US and UK that they are two nations separated by a common language. In some respects, the same can be said about Canada and the US. Upon crossing the border, miles turn to kilometers, gallons to liters, and a dollar (although still called a dollar) buys more or less, depending on which direction one is headed.

It has sometimes been said of the US and UK that they are two nations separated by a common language. In some respects, the same can be said about Canada and the US. Upon crossing the border, miles turn to kilometers, gallons to liters, and a dollar (although still called a dollar) buys more or less, depending on which direction one is headed.

Theoretically speaking, there is nothing in business that cannot be outsourced. This extreme view sees an infinite, irreversible trend of more and more business activities being outsourced, from as early as when power supply was outsourced to specialist power plants, which most companies of the world now take for granted. In the context of IT, the ever-increasing scope of outsourcing remains controversial. The focal point of this controversy lies within business process outsourcing (BPO).

Theoretically speaking, there is nothing in business that cannot be outsourced. This extreme view sees an infinite, irreversible trend of more and more business activities being outsourced, from as early as when power supply was outsourced to specialist power plants, which most companies of the world now take for granted. In the context of IT, the ever-increasing scope of outsourcing remains controversial. The focal point of this controversy lies within business process outsourcing (BPO).

Some of the big technologies, the ones with the deepest impact on the everyday work lives of people, prove to be some of the least complex to learn and use. Think e-mail and the word processor. After having mastered these tools, you stand back and ask the question every meaningful innovation begs: why didn't someone invent these sooner? So too will users demand an answer to this question: couldn't someone have invented the corporate wiki years ago, when I could have first used it?

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.

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.

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.

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.

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.