The Nokia Test is a quick assessment of practices to determine whether your Scrum implementation is up to snuff, based on how it is done at Nokia. Let's take it apart to see whether there are any user-serviceable parts inside. The first few elements identify whether or not you are really iterative.

As I wrote recently (see "The First Thing We Do, Let's Kill All the Risk Managers -- Again," 31 January 2008), the management of Swiss bank UBS admitted in January that, even after writing off US $13.4 billion from the bank's books in the fourth quarter in response to its holdings in subprime mortgages, "We cannot, at this ti

I was talking to someone recently who had used a requirements approach about which I was skeptical.

"How many times have you worked on a project that used this approach?" I asked.

"I'd guess 25 or 26," he replied.

"Did it work?" I asked.

"It didn't," he replied.

In this Advisor, Cutter Consortium Fellow Steve Andriole offers his expert advice as to the type of business technology education today's undergraduates should be receiving. These students will be your future IT employees. What do you think these students should be learning from their coursework?

In my last Advisor (see "Principles of Planning: Managing Stakeholder Expectations," 12 March 2008), I described the importance of actively managing stakeholder expectations.

The things you have to be careful about in architecture are those everybody knows but are not true. I was working recently with a friend trying to sketch out a migration plan for an organization whose IT systems were not too great.

What if someone established a blog whose sole purpose was to engage disgruntled consumers in a running commentary about how lousy your company's customer service is and to tell people to "do themselves a favor" and avoid buying, banking, renting, etc., from your business? Or what about a video on YouTube that slams your company's product?

Several weeks ago, I discussed the need for tools that can mine social media sites like MySpace, YouTube, Facebook, LinkedIn, and others (see "Mining Internet Social Media: Tomorrow's Tools Needed Today," 18 March 2008).

The time between an action and the feedback on that action is critical.

-- Scott Ambler, Senior Consultant, Cutter Consortium

The title of this Advisor is very specific: "chartering agile projects," not "developing an agile charter." In the latter, "charter" is a noun; in the former, a verb (taking some liberties with the English language).

As is the case with many technology innovations compared to existing solutions, the market price starts high and the benefits taken in the context of the costs involved start low. Price and benefits move toward each other until joining at that inflection point of value where the innovation presents an affordable alternative to the existing technology. We might be quickly approaching the affordability inflection point in solid-state storage.

Looking to the future, we see a new revolution looming. The Industrial Revolution transformed life in the developed economies and is beginning to do the same for the rest of the world. However, the Industrial Revolution depends on limitless amounts of energy and supplies -- which we're (finally!) discovering that we don't have.

In this Advisor, I pick up on our conversation on the "Experience Analysis and Design" (EAD) methodology (see "EAD: The Architecture of the Customer Experience, Part 1," 2 January 2008, "EAD: The Architecture of the Customer Experience, Part 2," 23 January

A little over a year ago, I wrote an Advisor called "Should Your Architect Write Code?" (29 November 2006). In it, I gave the typical consultant's answer: "it depends." Each organization is different, and each has more or less different requirements for their architects.

The key to implement agile efforts is to recognize that when you introduce new software development methods requiring involvement from other functional areas, methodology automatically becomes an organizational change initiative. It becomes an initiative all about changing how the organization works.

Many organizations continue to underestimate end-user training requirements for their business performance management efforts. This finding comes from a recent Cutter Consortium survey conducted in January 2008 of 101 end-user organizations (based worldwide).

I recall a conference presentation titled "Software engineering? An Oxymoron?" that I attended about five years ago. The speaker was pushing the idea that the software development practice had to borrow concepts from the engineering domain, where the formal approach in design and build was a common practice consolidated over 2,000 years.

A US healthcare company CIO and his core IT team have been using an agile development approach in their projects for just about a year now. When I came across this company last year, the CIO and most of his key team members were getting ready to support the rollout of 10 large-scale systems-integration projects across the enterprise.

While teaching a class recently, I had a few minutes to chat with a corporate VP about his forays into risk management. His name is Ira Brackman, and he passed along a copy of an article he wrote almost 11 years ago for a short-lived publication called Year 2000 (focusing on the computer world's Year 2000 crisis).

At a conference recently, a group of approximately 100 people had just witnessed an impressive demo of a mature application development environment. At the end of the session, there was a question-and-answer session. At one point, a fellow at the back of the room asked, "Isn't that like a CASE tool?" I was acting as the moderator, and I wasn't sure how to respond.

A year ago I argued in an Advisor that sourcing was about to get more strategic (see "Sourcing Is Getting More Strategic," 7 March 2007). That is, going forward, organizations would source more strategic business processes other than just IT service functions. I have concluded that even this definition is too limiting. Strategic sourcing can mean the sourcing of such functions as R&D, product development, or supply chain, but really should mean far more.

We've gotten very interested in the issues that led to project development success or failure. A simple Google search on "why do projects fail" leads to many hundreds of sites that offer advice about what leads to failure and what to do about it. Presumably, this leads to project success.

Last September, I discussed the latest Web 2.0-related development to make its way into the corporate world: mashups, which (as defined by Wikipedia) are Web applications that can combine data from more than one source into an "integrated experience." The aim of using mashups is similar to other Web

Enterprise IT leaders who seek customer value from a master data management (MDM) project [1] can find themselves in a Catch 22. They can't put all development on hold while they wait for a full enterprise data model to be developed and approved, yet they know anything that is developed in the interim will be subject to a costly, lengthy, and, quite possibly, ugly remediation when the new standard is available.

A debate is going on as to what actually constitutes "business performance management" and how it differs from so-called "traditional" BI. Because a number of readers have contacted me regarding this subject, I've decided to make it the topic of this week's Advisor.