New Technology for Problem Solving: Three Disciplines for Systematic Innovation in Business Information Technology

AuthorHouse™

1663 Liberty Drive

Bloomington, IN 47403

www.authorhouse.com

Phone: 1 (800) 839-8640

© 2016 Scott Wilger. All rights reserved.

No part of this book may be reproduced, stored in a retrieval system, or transmitted by any means without the written permission of the author.

Published by AuthorHouse    12/18/2015

ISBN: 978-1-5049-3300-1 (sc)

ISBN: 978-1-5049-3299-8 (e)

Library of Congress Control Number: 2015913511

Any people depicted in stock imagery provided by Thinkstock are models, and such images are being used for illustrative purposes only.

Certain stock imagery © Thinkstock.

Because of the dynamic nature of the Internet, any web addresses or links contained in this book may have changed since publication and may no longer be valid. The views expressed in this work are solely those of the author and do not necessarily reflect the views of the publisher, and the publisher hereby disclaims any responsibility for them.

CONTENTS

THE BACK STORY

OPENING THOUGHTS

PART 1:    THE DISCIPLINE OF TRUST

THE PROFESSIONAL PARADOX

THE ENEMIES OF TRUST

BUILDING AN OPERATIONAL TRUST

PART 2:    THE DISCIPLINE OF CLARITY

ACQUIRING A SHARED UNDERSTANDING

MODEL-DRIVEN REQUIREMENTS ANALYSIS

ADOPTING A MODEL-DRIVEN DISCIPLINE

BATTLING SELF-DECEPTION

PART 3:    THE DISCIPLINE OF PROCESS

PRINCIPLES OF GOOD PROCESS

A PROCESS DISCIPLINE

PARTING THOUGHTS

BIBLIOGRAPHY

ACKNOWLEDGMENTS

1.

THE BACK STORY

F or 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 a chronic 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 current knowledge-based economy,¹ the creation of value depends primarily on creativity and innovation. We aren’t shoveling sand. We are inventing new things.

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.

The productivity gains are even more remarkable. My team and I have been doing this kind of work, together and separately, for quite some time. By comparing our own results over time, comparing our results to other teams on similar work (and in two instances on the same work), and by comparing the results of new team members before and after they have adopted our disciplines, we are finding that we are at least two to four times more productive than our peers.

Think about that: on comparable work, a team of three of our people can do the work of 6 to 12 people. On large projects, we consistently outpace the rest of the project team by months, even when our portions of the projects are enormously complex. The projects or portions of projects that we control are almost always successful, even when the rest of the project is deeply troubled. Since productivity and quality go hand-in-hand, the solutions we build are of very high quality. We experience fewer defects, fewer missed requirements, and fewer misinterpreted requirements. Our solutions are highly maintainable and enhanceable for years to come. Most importantly, they consistently achieve their stated objectives, adding real value to our customers’ businesses.

Not surprisingly, our customers are very happy. We tend to build very strong and lasting relationships with them. Many have become friends. We often work together for years. From a consulting perspective, the work is more fun, less stressful, and far more rewarding.

These kinds of results are not achieved by chance. They come at a price, and that price is relentless, uncompromising discipline. The fact is that it is hard. Everything we do to achieve these results is interconnected and mutually reinforcing. This means that it’s not an option to choose to do just a little. You either do this, or you don’t. There is no in-between.

Does this mean that we have become immune to failure? Unfortunately, no. On any given project, only so many factors fall within our scope of control and influence. No amount of sophistication at executing IT projects will overcome systemic organizational weaknesses such as fundamental leadership issues, lack of vision, or paralyzing politics. But what we can do, and in fact are obligated to do, is to learn to be more successful within our scope of control and influence. As we experience more success, our scope of control will expand, and over time, we can have an ever-larger impact on success overall. An important common denominator is like-minded people: people who are devoted to something larger than themselves, who are hungry for a better way, who are open to trying something new, and who are fearless in the pursuit. We are looking for those people.

Notes

1.    Drucker, Peter F. Post-Capitalist Society. New York: Routledge, 2011. iBooks. https://itun.es/us/LRBnH.l. p. 14.

2.

OPENING THOUGHTS

New Technology for Problem Solving: The component technologies, or disciplines, required to successfully accomplish complex transformations of business systems.

Technology: If a learning organization were an engineering innovation, such as the airplane or the personal computer, the components would be referred to as technologies. For an innovation in human behavior, the components need to be seen as disciplines.

PETER M. SENGE ¹

Discipline: …a body of theory and technique that must be studied and mastered to be put into practice.

PETER M. SENGE ²

A dvances in technology continue to present companies with new opportunities for growth as well as new competitive threats. For example, internet and mobile technologies introduced vast new possibilities for companies to engage and serve their customers in entirely new ways, as well as to develop entirely new products and services, in other words, to dramatically change and enhance their value propositions to their customers. The advancements in technology and the possibilities that have emerged as a result, have compelled companies to transform their value chain processes in order to avail themselves of these possibilities as well as to respond to new competitive threats. These might be modest transformations, but very often, they are significant.

For example, a large retailer whose value chain is traditionally geared toward physical retail locations faces a significant effort to extend its shopping experience online to its customers. The online storefront itself is only moderately complex technically. The real complexity is more subtle, and arises as the company attempts to extend its brand and shopping experience to an entirely new medium. Behind the scenes, the supply chain is very different, placing new demands on inventory management, supplier relationships, and order fulfillment. If the company has any uniqueness in its value chain that provides it with a distinct competitive advantage, this uniqueness must be respected and extended to the new channel. These are serious challenges. How does the company extend its value proposition in ways that enhance and complement what the company already is, that which is already compelling to its customers and provides it with a defendable market position? ³

It’s not the same as implementing a new accounting system or email system, that’s for sure. Implementing the technology itself is not that difficult. Pure technology endeavors, such as implementing complex networks or other infrastructure efforts, are much like constructing buildings. They involve detail complexity, with lots of steps and moving parts, and they are well suited to traditional project management and oversight. It’s not to say that they are always easy, or that they don’t have their problems. However, they are largely successful, and we rarely hear of projects of this nature failing. I never once saw a headline that read Company Fails Miserably at Implementing Word Processing on its Desktops! Where we tend to fail is at executing complex transformational efforts.

Transformational efforts are different. They involve not only detail complexity, but dynamic complexity. Peter Senge describes dynamic complexity as situations where cause and effect are subtle, and where the effects over time of interventions are not obvious. Problems are dynamically complex when the same action has dramatically different effects in the short run and the long, and when an action has one set of consequences locally and a very different set of consequences in another part of the system.⁴ Transformational efforts