If you start with agile management, you will hit a point of frustration eventually: the more reliable your planning process becomes, the more frustrating are its results. You will find that your real velocity is way beyond what you would like it to be -- and probably beyond what you promised to your stakeholders.

I recently spent some time on hold with -- and occasionally actually speaking with -- "technical support" representatives.

The expectations for our leaders have never been larger. More than ever before, the essentials of leadership include the courageous use of human experience and the individual desire to create a difference and succeed in a world of rising complexity.

IT can be the facilitator of efficiency and sustainability within a corporation. By driving sustainable practices from the bottom up, IT can help build a better, greener company around itself. There are some simple policy modifications that can be taken immediately to reduce the environmental impact of IT's use in the company, and then there are some cultural changes that take longer to enact.

In the education business, there is a recognized theory of cognitive development that is based on the work of Swiss psychologist Jean Piaget and his study of children. Piaget identified four stages of development. Each represents the understanding of reality during that stage, but the last is an inadequate approximation of reality.

I have met many engineers, programmers, administrators, and others who have great imagination (I used to be one of them; sometimes I stray back into that fold). Ideas come to them, and they try those ideas. Sometimes, some of those brilliant ideas work right now in the system we are building. Often, however, that isn't the case. Poor odds don't deter these imaginative people. Close oversight is necessary; well, maybe not necessary, as there are other choices.

IT can be the facilitator of efficiency and sustainability within a corporation. By driving sustainable practices from the bottom up, IT can help build a better, greener company around itself. There are some simple policy modifications that can be taken immediately to reduce the environmental impact of IT's use in the company, and then there are some cultural changes that take longer to enact.

The majority of organizations plan to increase spending on business performance management in 2008. This finding comes from a Cutter Consortium survey conducted in January 2008 of 101 end-user organizations based worldwide.

Entrenched political infrastructures will not fall in line easily around the idea of tackling the governance issue. To the contrary, business units and IT spend most of their time working around the concept of governance because no one believes that it can change. This fact is clearly visible in most organizations.

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).