New Technology for Problem Solving

For some time starting in the mid-nineties, you could hardly pick up a book or article on IT project management that didn’t reference the Standish Group’s CHAOS Manifesto. It was almost as if an entire industry had a feeling that something was wrong, but no one could put their finger on it. And then there was the CHAOS Manifesto, which put a name to our pain. It told us that on average, nearly 85 percent of all IT projects fail, and it told us why. And everyone said “I knew it! Everyone else really does suck!” Year after year the Standish Group published the CHAOS Manifesto and year after year nothing changed. Book after book was written, each one describing exactly what the problems were and how to solve them. There were books on risk management, software development methodologies, project management techniques, Eastern religion (not kidding: Zen and the Art of Systems Analysis) — you name it. Project managers blamed insufficient project management controls, inadequate techniques, inexperienced and insufficiently skilled project managers, and insufficiently skilled team members. Business analysts blamed poorly defined requirements, clients who didn’t know what they wanted, and developers who ignored requirements or who were not skilled enough to properly translate them into software. Business people complained about how their internal IT organizations and consultants were under-skilled, didn’t understand the nuances of the business, didn’t listen, and took forever to get anything done. Developers complained about incomplete requirements, business analysts who couldn’t define requirements that could be translated to design, and business customers who were clueless. Generally, the most common reasons for project failure could be boiled down to insufficiently skilled practitioners, inadequate processes and controls, poorly defined and incomplete requirements, inadequate executive support, insufficient testing, and the rapid pace of change in both technology and the business environment in general. Prescribed solutions ran the gamut: more controls, fewer controls, more rigorous processes, less rigorous processes, more sophisticated contractual arrangements and fee structures, better, smarter, faster people. In the 20 years since The Chaos Manifesto was first published, what was once all the buzz, hardly anyone remembers. A whole generation of leaders has been replaced by a new class. Absolutely nothing has changed, except to get somewhat worse, if that’s possible. Everyone still complains about the same problems, but it seems as if the current state of dysfunction has simply become the expectation. Sadly, for at least the last decade, the popular focus of IT leadership has been almost exclusively on reducing cost per hour, the least important of all factors related to performance. Worse, this obsession with cost per hour has had the unintended and largely unacknowledged side effect of dramatically eroding the most important factor of all: productivity. Many of the standard “best” practices that we continue to apply, particularly in the area of project management, are left over from an era when productivity depended entirely on leveraging labor — managing tasks and time. But in our modern economy, the creation of value depends primarily on creativity and innovation. We aren’t shoveling sand. We are inventing new things. Knowledge-based activities suffer at the hands of traditional, linear, command and control project management. Equally troubling and less obvious are the patterns of behavior that consistently torpedo our efforts. They are insidious and deeply entrenched, not only in the way we approach IT projects, but also in the way we approach leadership, management, and interpersonal relationships in the business context. Big advances have been made in systems implementation methodologies, tools, and techniques, and they have certainly been of tremendous value. There is always room for improvement when it comes to the mechanics of systems implementation, but by and large, they do nothing to change behaviors. While the behaviors remain the same, the results will not change. When we manage to change these behaviors and turn our attention to productivity, the results are remarkable. It turns out that complex systems implementation efforts are not required to be chaotic, painful, contentious, and draining. They are not required to have a high probability of failure. We are not required to chew through people, use them up, and burn them out. It is not necessary to operate in a continuous state of crisis. It is not required that businesses suffer enormous economic loss in the process. When all factors come together into that magical combination where everything clicks, this work is highly successful and deeply rewarding.