In-Depth

Careers: Combating Business-Process Change Overload

Compromise may be possible—even within the most control-oriented of corporate cultures

• By Stephen Swoyer
• 02/08/2005

Like many of your colleagues, you’re probably feeling a little overwhelmed by all of the process-centric initiatives coming your way these days. First there was ISO 9000, which was followed inevitably by ISO 9001, which—more recently—has given way to Six Sigma.

That’s just the beginning, however. If you’re a programmer in a software development shop, you might be dealing with a Capability Maturity Model Index (CMMI) initiative, which, in many organizations, all but prescribes precise process definitions—and lots of accompanying documentation. Then there's the spate of new regulatory requirements, such as the Sarbanes-Oxley Act of 2002, which invariably lead to changes in existing business processes, along with the identification and codification of new processes as well.

It’s enough to make some grizzled IT vets think about throwing in the towel. “I have worked for [a prominent networking solutions company], for about 19 years,” confirms one programmer, who—frustrated with his employer’s suffocating management philosophy and proposed process reengineering initiatives—admits that he’s now “looking to get out of programming.”

The problem, this developer says, is that his company’s business executives employ a risk-averse management philosophy that emphasizes process over people. “[My company] is very steeped in bureaucracy, and there is a chasm that exists between upper management and those on the ‘line,’” he explains. “Neither end knows what the other is doing or why. The ‘line’ workers are viewed as resources and a major risk factor to the business, and therefore management likes to do things that bring the associated costs under control.”

One upshot of this, at least from management’s perspective, is that IT workers come to seem like replaceable cogs in a process-driven machine. “So [management] looks to outsource—we are interchangeable anyway, right?—and takes up things like CMMI, which promises to get those line workers under control for their own good,” he notes.

This programmer isn’t alone. Another IT professional, a programmer with a prominent technology services company, says that he, too, is mulling a job change. The reason: His firm has a contractual agreement with the client to which he’s currently assigned to increase the quality of its software development to CMMI Level-3 standards. From this programmer’s perspective, both the client—a major telecommunications provider—and his own company are pursuing CMMI achievement because, in theory, it makes him more replaceable.

“The theory is that [CMMI achievement] leads to repeatability, because you have these definite processes, and they’re all documented, and anybody who comes in after you will also be working off the same framework,” he says. “What they really think is they can let anyone go at any time and have someone new come in and pick right up from where [the previous employee] left off.”

In practice, this programmer says, that’s far from the case. “I’ve had to go back on several of these projects and say, ‘I have no idea what they were talking about,’” he says, referring to programmers who were let go when several years ago when the telecom giant laid off 80 percent of its IT staff. “The guy who wrote them was long gone, and he made a lot of assumptions that he shouldn’t have. Assumptions are something you document in each of these intervals, and he didn’t document them. Any pertinent information that’s in a developer’s notebook at some point better be transferred into [a document], and that wasn’t done.”

Neither of these situations is unique, agrees Michael Spayd, a principal with Cogility Consulting Solutions and a former CMM process assessor. (The CMM framework serves as the basis for what is now called the CMMI.) In many cases, Spayd says, CMMI and other process-centric initiatives can be misused by a company as part of a misguided attempt to manage risk.

“CMMI works most easily and grew out of a control-culture orientation, where people are trying to minimize discrepancies, or variations, or change, or whatever, and trying to stay in control of things,” he explains, noting that CMMI, like the ISO 900x standards, got its start in the government and defense sectors.

These days, Spayd is a proponent of agile programming and project management methods, which are about as different from traditional, process-driven, documentation-intensive management techniques as is possible. In this respect, he says, he knows what it feels like to suffocate under the twin pressures of bureaucracy and business process craziness. Even so, Spayd urges, IT professionals shouldn’t necessarily throw in the towel.

“Look, there are some cultures where you’re just not going to be able to get them to compromise. They’re just too oppressive. The people are too narrow-minded,” he agrees. “On the other hand, you have to start with mutual respect, which means you have to start with respect on your side—not on their side. You have to show them that you respect where they’re coming from in terms of their control-culture orientation.”

Adds Spayd: “If you have a boss with a very different [personality] type than you, if you devalue the way that they need to assimilate information and their style, you’re going to have a really hard time working for that person.”

In some cases, he suggests, it may also be possible to reach a compromise—even within the framework of a control-oriented corporate culture. “The idea is to define the minimum amount of involvement [from management],” he says. “Let’s say you’ll define a two-week iteration for a software project, and they’ll see the software at the end of that.” It’s a not unreasonable request, he points out, and it’s also a good way to build trust between two largely dissimilar management styles. “You basically say, ‘You trust us at the beginning, and if it doesn’t work, we’ll do it your way. But when they see the results, they’ll become a lot more responsive [to your concerns.] You could do that in a lot of control cultures.”

This is the approach the veteran programmer introduced above plans to pursue. He’s managed to implement several not-officially-supported programming practices that, he says, have resulted in quality-of-life improvements for him and his fellow developers.

“These simple practices are quite contrary to our current processes which are heavy on up front work and documentation,” he says. “My manager has no objection to my bypassing of the official process since the results have been good.”