Section 2.2. The Conscious Organization

2.2. The Conscious Organization

All organizations use process. Many times they are not well defined. Many times they are just embedded in the culture. Often they are the wrong processes. Management may not even be aware of what they really are. But if you look closely to see what these processes are, you can learn a lot about what's important to a company.

Process reveals an organization's values, priorities, and preferences. They naturally emerge from the actions an organization employs to see its work through.

I once worked with a software company that regularly, always around release time, scheduled marathon testing and defect-correction sessions: 12-hour days, weekends included. It was an all-hands-on-deck routine. The company's values, priorities, and preferences were just about all focused on market perception and competitive position. But not so much on planning. And less so on its people.

One of the early benefits of implementing a formal process program is that these values begin to visibly emerge. In the example above, management probably would have balked had it been asked to document the marathon sessions as a matter of company policy. I think if they were asked to consciously commit such descriptions to paper, they would have naturally realized that such routines are not very commendable. Weak management can hide behind a lack of formalized process. But when a company is committed to growthcommitted to catalyzing its own growththe visibility of formal process becomes a welcome opportunity.

Many, maybe even most, IT shops are what I would call unconscious. They are not concretely aware of how they do things. They can't describe their mode of operations. They're not conscious of the processes at work within their groups, the procedures that drive them to be who they are. And so, they are not adept at learning from their performances. The organization has no viewpoint from which to watch itself. It has no outer perspective. That makes things tough on management and line workers alike. Environments of this kind tend to be reactive. They tend to be driven by heroes: people who can thrive in chaos. There is a lot of firefighting going on, a lot of backtracking. And there's a dearth of hard information as to how things really are proceeding at the micro level. There's little consensus of status.

This is not only a tough way of doing business, it's an expensive one. This tenuous grasp on consistency and predictability carries with it major drawbacks and risks. Here are some recent numbers:

• Seventy percent of all corporate software solutions were delivered late.

• Fifty-four percent of major, business-critical projects came in over budget, many by as much as 222 percent.

• Sixty-six percent of what IT delivered was considered unsuccessful when the systems were installed.

• Thirty percent of projects were simply cancelled.

Those numbers come from a 2004 study by the Standish Group, in an extension of their now famous 1994 Chaos Study. Standish studied the performance of Fortune 500 IT shopsthe big boysand those are the figures they came out with.

In the 1994 report, the numbers were eye-opening. The 2004 report showed some improvement, but the overall performance indicators shed light on a still-present problem. Corporate IT is wrestling with its ability to manage technology development and deployment in a consistent and predictable fashion.

Here's another number: a 2002 ANSI report puts the cost of American IT failure for the year at just under $60 billion.

What might it be in 2008?

Of course, all these numbers are not the problem; they are symptoms. And we need to acknowledge that IT is not the lone contributor to these results. Here are some other likely contributors:

• Lack of adequate funding for IT

• Limited IT resources

• Shifting executive mandates

• Conflicting objectives between marketing and IT

• Competing customer demands

• Unrealistic turnaround expectations

• Complex architectural and system constraints

Very little of those factors are under the direct control of IT. Yet they have enormous potential to impact IT performance.

But if we recognize the above factors to be true, doesn't that promote the case for process even more? If we recognize that we are indeed in a business that's going to be pressured often by changing or unrealistic demands, shouldn't we respond in part by getting internal operations running as well as we can?

I'm not trying to paint all corporate IT departments as underperformers. They are not. As mentioned above, American technology, and the reign business has on technology development and management, is unparalleled. The industry can deliver, and it does deliver.

But still there is that $60 billion. It's not missing money. It didn't vanish. Nobody dropped it. It went mainly to people who had to do things over. They had to go back to the customers and ask them what it was they really wanted. They had to add in new design components or redesign existing components. They had to reprogram things they thought they had programmed just fine in the first place. They had to retest, retrain, and reinstall. They had to buy the kinds of parts they should have bought when they first went shopping. They had to replan and recoordinate, bump new things out of the way, renegotiate and revisit. And somewhere in here came the big change: the shop went from balancing to juggling.

Process won't solve all of IT's problems. No one should promote that line. But it can help almost all IT shops in three very distinct ways:

• Provide tools to proactively plan, manage, and integrate work.

• Set into place methods and controls to maximize internal efficiencies.

• Establish mechanisms to regularly assess, report on, and improve performance.

And with those abilities in place, the organization can better anticipate risks and constraints, and so can manage their impacts; it can plan for and coordinate the effective uses of its resources; and it can better manage its position in the overall environment to better meet its goals and objectives. And those are all marks of a conscious entity.

2.2.1. The Business of Technology Is Business

This is a book about process improvement, about the benefits of process improvement, about techniques for process management, and about the structures of three of the industry's leading process management programs. The premise of this book is that American IT needs process, that it should embrace process more because as a whole it has not embraced it enough.

There are pockets of stellar performances out there, companies that know how to use process to make their business practices stronger and more profitable. Divisions in organizations like GE, Lockheed Martin, Honeywell, and Texas Instruments could show us enough about process management to convince even the most hesitant adopters.

In this chapter, I want to begin to build the business case for process improvement, to identify why process can be used in small IT shops as well as large IT shops to conduct and manage business along predictable, successful, and profitable lines. The financial numbers above tell a story, but I'm not chalking those figures up solely to illustrate the lack of process. There are other dynamics certainly at play: shifting management roles, evolving market conditions, internal politics.

But we do know that most of the IT shops that drive corporate America do not operate under any kind of distinct or managed process program. They depend on the talent of their people. They rely on the individual processes at work. Many of these shops are either unfamiliar with the rudiments of process application, unexposed to the purpose of process improvement, or adverse to the disciplines of quality management. Whatever the case, these organizations may be heading in the directions they want to move, getting to their goals, but at what cost? How much time might they spend traveling off course before they are able to veer back on?

Calvin Coolidge is famous for his saying in the 1920s, "The business of America is business." The same could be said today about American IT. The business of technology is business. Technology is not analogous to a game. It is not a different spin on war. It is not an adventure. It's a business, and it should probably be run like a business.

And so a good way to begin the case for process improvement is to begin by addressing it in the same way a business would.