In the rush of sourcing issues that threaten to pull you under like a riptide, it is worthwhile sometimes to step back and recalibrate your perspective to better understand the current sourcing environment as a necessary step in planning for the future. This might represent an ideal time for this. We're just weeks away from the end of summer -- and after Labor Day, the starting gun goes off for those remaining projects in the planning queue before the end of the fiscal year.

The release of software under an open source license has two key business implications: (1) the possibility of reduced cost and increased value for software users and (2) the potential emergence of peer production networks.

Over the past few years, it seems more disasters and emergencies have impacted businesses around the world than in any other time in history. Natural disasters, terrorist activities, and criminal actions are affecting organizations of all sizes. Organizations should know that they must be prepared to address a wide range of emergencies and disasters to keep their business going.

Back in January, I discussed Hewlett-Packard's (HP's) entry into the data warehousing and BI market with its new Neoview offering that combines data warehouse software, hardware, and services (see "Hewlett-Packard's Data Warehousing Gamble," 23 January 2007).

People never notice the most important things in an advanced society until those things stop working or they disappear. This is true of electricity or water or other forms of infrastructure, like roads and bridges. We count on these things for transportation and recreation and commerce, but it is only when they're gone that we begin to understand their value.

A recent Cutter Consortium survey indicates that project duration was 35% shorter on successful Agile projects (19 weeks) than on challenged Agile projects (29 weeks) (see Question 1). Does this finding play into the hands of the "Agile doesn't scale to large projects" crowd?

The increasing attention being garnered by the Web 2.0 phenomenon is reminiscent of the buzz and excitement of the dot-com days. In December 1999, Time Magazine named dot-com pioneer Jeff Bezos the Person of the Year. In December 2006, the magazine put "you" on the cover. The picture was the console of the YouTube player with a mirror instead of the screen.

In Parts 1 and 2 of this series of Advisors (see "Winning Project Office Techniques, Part 1," 2 May 2007, and "Winning Project Office Techniques, Part 2," 6 June 2007), I discussed a couple of advanced project office techniques that not everyone considers bu

Apparently, former US President Dwight D. Eisenhower once said, "In preparing for battle, I have always found that plans are useless, but planning is indispensable." Like many popular quotes, it is not clear whether he actually said this, but it is interesting to run into a situation where the expressed wisdom holds true.

Everything has been said and written about the role of pressure in software development; there's no need to reiterate that all over again. At least, that's what I thought until recently, when an executive called me in for one of those "let's talk frankly" chats. She had hired me to help her deal with the organization's disastrous bug rate, which had started to threaten its market position.

The software-as-a-service (SaaS) model really began to shake up the corporate computing world in 2006.

In the entire history of the buying and selling of consumers' personal information, I can't think of one scenario in which the consumer regularly took part in the transaction and thereby profited by it. In this billion-dollar marketplace, the consumer has been treated as an externality; an obstacle to overcome in the category-four-rapids flow of money between buyer and seller. Perhaps until now.

When I talk to people about agile project management and development, one of the things I hear consistently about is the lack of good release planning. Teams seem caught up in iteration-at-a-time plus backlog building and not planning for an entire release or project.

Last week, a couple of enterprise reputation risks items that I have previously written about hit the news once again.

I've had the opportunity to work with architects in a fair number of companies in diverse industries. Whether we were architecting individual applications or grappling with the complexities of an enterprise, the goal has always been to tease out the salient aspects of a problem and organize them in a way that speaks to a robust and flexible solution.

I have been involved with the IT industry for more than 20 years. I cut my teeth in the US Air Force programming big iron, using punch cards and an occasional turn at the green CRT. Over the years, I have seen many innovations in hardware and software -- from advanced programming languages and development environments to larger and larger amounts of memory fitting in smaller and smaller spaces.

In last week's Advisor (see "Even in a Flat World, Quality and Schedule Matter," 25 July 2007), we looked at The World Is Flat author Thomas Friedman's description of how a "connected" world has made it possible to do al

IT has been a critical part of the production of running a business since the early days of the IBM 360. IT supports every aspect of the business from human resources to operations -- yet it has primarily been perceived to be a part of the backstage crew.

In enterprise architecture, we're constantly challenged to overcome perceptions that we're in an "ivory tower" or being impractical or even irrelevant. In response, we should be looking for opportunities to provide value within the enterprise. Luckily, we're well suited with skills and well positioned organizationally to do so if we search out the right opportunities.

A reader asked me to name the major goals and benefits that organizations should seek to obtain by implementing business performance management initiatives. I've recorded my thoughts in this Advisor.

In my last Advisor (see "Summer Reading: Blink, Mirror Neurons, Antonio Damasio, David Gelernter, and Real Intelligence," 5 July 2007), I talked about Malcolm Gladwell's book Blink and how it got me thinking about how experts often know something is wrong in an instant, like when a big project is probably

In this Advisor, I'll tell you about integrity as a key to partnering. You can read about exchange and expansion in previous Advisors.

In the first part of this Advisor (see "A Stake on the Grill? Part 1: A Look at Drawing Information Out of the Right Stakeholders in the Risk Process," 19 July 2007), I traced the evolution of the stakeholder and stakeholder management. Stakeholder management is a critical component of risk management.

If you're heard of UML, then you've probably heard comments that it is big, unruly, and complicated, and that things are even worse with UML 2.0. Although I don't necessarily agree with the sentiment, I can understand where it's coming from. UML is a general-purpose modeling language, directed at IT systems. Well, IT systems are a big topic area.

We have been working with clients on establishing the project management office (PMO) function and pointing the PMO in the right direction. We have also been making presentations at conferences and at companies on this subject. Two questions often are asked: is the PMO important to achieving business value with projects, and what exactly is the charter for the PMO? Our answers are simple: the PMO is on the front lines of business value, and it plays a critical role in its achievement.