In his seminal work, Managing the Software Process, Watts Humphrey outlined what he called "Six Key Principles of Software Process Change" [2]. The first principle was "Start at the top." It is an axiom of process change in any discipline that, if the people running the business don't want it, it won't happen. In fact, if the people at the top don't really want it, it won't happen. Many of us in the business of software can point to initiatives where the commitment was not there and it didn't work. For obvious reasons, the times when process initiatives die on the vine tend to receive less overt publicity within companies than when they work. But we do have a number of examples where major initiatives have worked and worked well.
When Art Sundry, an executive at Motorola, declared at a management meeting in 1979 "...our quality stinks" he got the boss's attention [1]. Bob Galvin, the visionary CEO of Motorola, decided that quality was the most important thing for the company to focus on. And then he famously acted like it was. People throughout Motorola have stories about a time when they were conducting a quality briefing on their product and Galvin himself came in unannounced and sat down. Galvin actively participated in the process to assure himself that it was working and that people were truly engaged in the change. He would also attend presentations on product development, and excuse himself once the quality component was covered saying, in effect, I trust you to manage the rest.
This level of commitment is rare, but it seems to be one of the hallmarks of truly revolutionary change. We are actually quite good at working hard to provide the people who employ us with what those people want. That is, with what those people really want. We are also very efficient at filtering out the real needs from the rhetoric, and discarding or carefully de-prioritizing the politically correct statements emanating from the higher levels of businesses. When the boss says "quality is the most important thing" and then overrides the quality gates to force a shipment of a product to meet a deadline, we get it. Software developers are able to decode this situation quite correctly. We learn that what people say is what people say, but what people do is what is important to them.
One of my personal favorite ruses in process change is the "commitment" ploy. Without, hopefully, appearing too cynical I would describe the commitment ploy as follows. A senior executive makes a highly public statement about commitment to some facet of the business. It may be quality, customer focus, technology investment, appropriate resourcing of projects, or attention to the human needs of the work force. It may simply be whatever the current fad is, or the subject of the most popular business self-help book. This public statement is intended to generate enthusiasm on the part of those affected and who will be tasked to make, participate in, or endure the change. But it often has the reverse effect. Sometimes the statement is simply window dressing and nothing is done to implement it. Sometimes, the commitment does actually receive close attention and perhaps even its share of resources. That is, until fulfilling the commitment becomes difficult. Or expensive. Or a less popular fad. Or simply inconvenient. At this point, the commitment is shelved, or maybe just fades away, to be replaced by the next trendy initiative or the next fad. This is unfortunate, since the approach drains a company's commitment batteries faster than anything. It also demonstrates a lack of understanding about the nature of commitment.
Commitment is not doing what you want to do. Doing what you want to do is, well, doing what you want to do. Commitment is doing what you don't want to dobecause it is difficult, expensive, or inconvenient. In fact, the more you don't want to do something, but continue doing it because you believe it to be the right thing to do, the more you are committed to it. We could actually measure our commitment by the quantity of pain we are willing to endure while doing whatever we are committed to doing. If we really, really don't want to stick to our quality gate process because it is costly, it slows us down, it is difficult and tedious, or is simply inconvenient some of the time, but we continue doing it anyway, then we are really, really committed to it.
People are very good at detecting this and separating the committed wheat from the rhetorical chaff. Too much of the latter and people stop believing and investing in change initiatives of any sort. They adopt compliant behaviors and work on the window-dressing aspects while continuing to attempt to provide the organization with what they think it really wants as evidenced by its actions.
Some time ago, while conducting a seminar series on the nature of a software business, I asked the assembled executives: "...what is the ultimate goal of your business?" The almost universal response was "to make money." Now making money is a good thing; I am not against it in any way and candidly I wouldn't mind being a little better at it myself. However, if the core goal and purpose of a business is simply to make money, then the organization should be a bank or a casino. These are the only businesses where money is the business; all other enterprises have other reasons to exist. It is quite dangerous for companies to intentionally or accidentally get into this mode. When the focus of the executive management becomes directed entirely at the making of money they may completely abdicate the real purpose of the business, to the detriment of all.
When companies do this, the leadership may spend its time and energy buying and selling other businesses hoping to come out ahead financially. The company is gambling; it is playing the market and acting like a casino. Sometimes at the same time, the company may attempt to leverage its asset value by devices such as selling debt. This is, of course, a company acting like a bank. And these are just the legitimate businesseswe have seen recently that companies can also get into illegally "making money" by, say, cooking the books.
The fate of process change initiatives in companies behaving this way is dismal. This is not to say that process changes should not have a positive effect on the financial situation, or that initiatives should not be subject to scrutiny and justificationthey should. But equally, sometimes we should do things and be committed to things simply because we know they are the right things to do. Good leaders doing what are clearly the right things, consistently and with commitment, operate at a higher ethical level than those in the raw pursuit of more. People respond very positively to this demonstrated ethic and identify with and engage themselves in the success of the initiative.
If the core goal and purpose of a business is simply to make money, then the organization should be a bank or a casino.
So how does an organization truly demonstrate and operationalize this commitment? Bob Galvin achieved this at Motorola through his personal attention and time, but this is quite rare. Few CEOs seem to have the time available to commit to a small number of high-priority issues (apart from that "making money" one). Or perhaps there are so many pressing issues that it is difficult to focus on just one or two. One thing I have found essential to the success of (particularly) a software process change initiative is to assign an "operational executive sponsor." Watts Humphrey is right when he asserts that, unless the top people want it, it won't happen. But what if they do want it, but are unable or unwilling to give it their direct attention? To paraphrase T.S. Eliot: between the executive thought and the practitioner implementation, lies the shadow. There is a need for solid and relatively unequivocal communication from the leaders. There is a need for demonstrable and clear consistency and commitment. And there is also a need for a way to transfer that authority downward.
The mechanism that seems to work best is the assignment of an operational executive sponsor. This is someone in authority who is able to attend to the daily sponsorship needs of the initiative. It must be someone with sufficient authority to be able to rattle a cage or overcome an obstacle when the need arises. It cannot be someone too high up in the organization, if the span of control means that appropriate and continual attention cannot be paid to the process initiative. This person cannot be too low in the organization if that means he or she cannot exert sufficient authority when needed.
Assigned authority is important to the effectiveness of the operational sponsor. However, authority that is simply conferred by an organization may not be enough.
It is clear that, in software process change, a good idea only takes us so far. In fact, many organizations already know what they should be doing, they just don't do it. As a senior executive said to me recently (regarding improving project estimation): "I know it's a problem, I know we need to work on it, but I'm not gonna...".
To effectively implement process initiatives and improve the business of software we must also have good leadership. While, in most cases, this leadership must start at the top, the positional authority exercised by the boss needs to be complemented by an operational executive sponsor, who operates with the right leadership skills and capability at the right level within the organization.
1. Gupta, P. and Wiggenhorn, W.A. Six Sigma Business Scorecard: Creating a Comprehensive Corporate Performance Measurement System. McGraw-Hill Professional, 2003.
2. Humphrey, W.S. Managing the Software Process. SEI Series in Software Engineering, Addison Wesley, 1989, 19.
©2006 ACM 0001-0782/06/0300 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2006 ACM, Inc.
No entries found