Many managers use the mantra, "do more with less." At the recent Agile 2010 conference, Pat Reed from GAP, who copresented with me, shortened this mantra to "do less." The theme of our presentation was value optimization or, as Pat likes to say, "value imagineering" -- determining the highest-valued chunks of functionality to implement next, whether those chunks are project

In the previous Advisor (see "Seeking Out Systemic Risk," 12 August 2010), I discussed the US Congress's establishment of a Financial Stability Council (FSC), one of the main purposes of which is to put an end to, or at least minimize, the effects of firms considered "too big to fail.

In the previous Advisor (see "Seeking Out Systemic Risk," 12 August 2010), I discussed the US Congress's establishment of a Financial Stability Council (FSC), one of the main purposes of which is to put an end to, or at least minimize, the effects of firms considered "too big to fail.

I have the highest regard for Apple CEO Steve Jobs. He is, without doubt, the greatest "industrial designer" of the computer age. No one in the last 30 years has had anywhere near the kind of vision for "personal computers" that Jobs has had. Indeed, the ability to bring that vision off in such a dramatic fashion has been the hallmark of Jobs's entire career.

I have the highest regard for Apple CEO Steve Jobs. He is, without doubt, the greatest "industrial designer" of the computer age. No one in the last 30 years has had anywhere near the kind of vision for "personal computers" that Jobs has had. Indeed, the ability to bring that vision off in such a dramatic fashion has been the hallmark of Jobs's entire career.

Outsourcing firms tend to market themselves as partners in innovation, and firms consider adopting an outsourcing strategy as a way to attain competitive edge. While outsourcing is a promising approach, it can also be a risky endeavor, as it may deter the firm's inherent ability to bring innovative products to market.

Outsourcing firms tend to market themselves as partners in innovation, and firms consider adopting an outsourcing strategy as a way to attain competitive edge. While outsourcing is a promising approach, it can also be a risky endeavor, as it may deter the firm's inherent ability to bring innovative products to market.

Outsourcing firms tend to market themselves as partners in innovation, and firms consider adopting an outsourcing strategy as a way to attain competitive edge. While outsourcing is a promising approach, it can also be a risky endeavor, as it may deter the firm's inherent ability to bring innovative products to market.

In my previous Advisor (see "Enterprise Semantics: Speed-Reading Your Enterprise Data Architecture, Part I," 11 August 2010), I explained that the skills needed for doing enterprise data architecture differed from data modeling or data warehousing. In addition, I pointed out that one of the most significant differences is that of scale.

If you want to be a leader, how successful you are will depend greatly on the culture where you work. "But wait," you might say. "Doesn't it matter more that you have the ability to lead? That you have the traits that make a leader?" Perhaps, but if the culture you work in doesn't allow you to practice those traits -- or worse still, discourages those traits -- they become irrelevant.

In my previous Advisor (see "Enterprise Semantics: Speed-Reading Your Enterprise Data Architecture, Part I," 11 August 2010), I explained that the skills needed for doing enterprise data architecture differed from data modeling or data warehousing.

An ever-increasing number of firms, both large and small, must deal with the challenges created by a distributed, virtualized workforce. This situation emerges for many reasons, such as the globalization of the firm's activities and points of presence, a mobilized sales force, the need to outsource various corporate functions, and the need for noncolocated teams to collaborate.

An ever-increasing number of firms, both large and small, must deal with the challenges created by a distributed, virtualized workforce. This situation emerges for many reasons, such as the globalization of the firm's activities and points of presence, a mobilized sales force, the need to outsource various corporate functions, and the need for noncolocated teams to collaborate.

I've been checking out a new book, Lean Integration: An Integration Factory Approach to Business Agility.

User-developed applications (UDAs) are nothing new for the IT environment. They have been an issue for years as undocumented spreadsheets and Microsoft Access databases. They have often presented management challenges due to questions familiar to developers, such as who has ownership, who (if anyone) is responsible for upgrades, and who is responsible for verification of results.

Building trust lies at the heart of success with agile approaches to software development. The agile philosophy depends on people rather than process to maintain order and quality. We lighten up the development process and dispense with many of the artifacts traditionally used to orchestrate project activities. We bridge the gap with increased collaboration and teamwork.

You may think it obvious to the point of being trite to say that change is "not an option" or "the only constant is change" [1]. Yet, with churn in the global economy catching businesses off guard, and a slurry of such books as Subject to Change, Change by Design, and A Sense of Urgency [2], there's also a sense that change is not only imperative but something we need to become good at. We need to be not only reactive, adapting to a changing world, but proactive -- changing the world, before it changes us. Why?

IT is sort of caught in the middle of a debate. In one corner stands a group of researchers and enthusiasts who look at the marvels of how the human mind can make quick, accurate judgments and decisions. This group tends to look optimistically at the capabilities of the human mind to work effectively in the environment.

Lately, I’ve been curling up at night with a fascinating read. The 2009 Shift Index is from Deloitte’s Center for the Edge and written by John Hagel III, John Seely Brown, and Land Davison.

Lately, I’ve been curling up at night with a fascinating read. The 2009 Shift Index is from Deloitte’s Center for the Edge and written by John Hagel III, John Seely Brown, and Land Davison.

Lately, I’ve been curling up at night with a fascinating read. The 2009 Shift Index is from Deloitte’s Center for the Edge and written by John Hagel III, John Seely Brown, and Land Davison.

The primary goals of this Reining in Technical Debt webinar are to give you a preliminary understanding how quality can be assessed through technical debt techniques, to familiarize you with state of the art tools for measuring technical debt and to demonstrate how value delivery is affected when the technical debt is not "paid back" promptly. Israel and John will also introduce you to a governance framework that ensures you can rigorously manage your software development process from a business perspective.

The primary goals of this Reining in Technical Debt webinar are to give you a preliminary understanding how quality can be assessed through technical debt techniques, to familiarize you with state of the art tools for measuring technical debt and to demonstrate how value delivery is affected when the technical debt is not "paid back" promptly.

In my last Advisor ("Understanding the Master Data Management Challenge," 4 August 2010), I discussed the demands of Master Data Management (MDM), particularly the difficulties of combining data from multiple sources.

In client consulting engagements, I frequently find that the root cause of a lot of frustration among managers, team members, and executives stems from the inability (or unwillingness) to choose what's most important. I had the interesting experience of trying to build a value-based priorities model with a client, and had the following exchange: