Chapter 1. Introduction

When designed properly, process programs can drive the business forward by operationalizing the mission and goals of the organization. It can serve to articulate—through structured expectations—the organization’s goals, placing importance on processes that help the organization achieve these goals.

—John Cline, CEO of eTrials, Inc.
Data management for clinical drug trials

A few years back I was consulting with a company called Impetus^[1] in a northwest suburb of Atlanta. Impetus produced asset management software for manufacturers in capital-intensive industries: oil refineries, power plants, pulp and paper mills, and so on. I was brought in to help establish a process management program based on CMMI. The company was having a hard time getting its software releases out the door on time and intact. As a consequence, its market position was suffering. Management thought the introduction of internal workflow controls might help. CMMI looked like it might hold some keys.

^[1] The case studies presented in this chapter are accurate; names of companies and people have been changed.

When I came into the company, the first two operational areas I began to look at were Project Planning and Project Monitoring & Control, two core CMMI Process Areas. I figured that whatever the release problems might be, they would probably at least evidence themselves in one of these two realms.

As part of my initial investigation, I interviewed the software group’s project managers, including a bright, energetic guy named Brick Weathers. Brick had been with the company about three years and was managing the 5.5 release, one of the releases that appeared to be going well. I thought if I could find out what his secret was, maybe we could institutionalize that for the other teams.

Brick did not hesitate to tell me what his secret was—once I confirmed that I’d keep the source confidential. Right off the bat, he admitted it was not an intuitive aptitude for dealing with people. And it was not a heightened attention to administrative detail. Here was his secret to success:

Always maintain three versions of the project schedule.

Make sure the one you give to management says everything’s on track. Make sure the one you give to your project team says everything’s off track, so pick up the pace. And the third one, well, make sure that one’s real because that’s the one you manage by.

So that was Brick’s methodology for managing project schedules. However, it was not one I was going to propose we set up as company policy.

As it turned out, the 5.5 release was in just as much trouble as all the others. Brick’s approach simply forestalled attention to the release until it had reached a crisis pitch. Then his team got every resource the company could muster.

In fact, that was the way everyone at Impetus managed projects. Brick’s secret actually had been institutionalized; it was just a secret institutionalization. The philosophy was this: Avoid pressure, negotiation, and accountability by avoiding the spotlight; then once the whole company was in the same boat as you, plea for patriotic support.

Another case comes to mind. Two years ago I was contracted by a commercial software development shop called SoftMil. SoftMil was owned by a much larger corporation called SystemAmerica (SA), which dealt a lot with U.S. Department of Defense agencies. SA wanted SoftMil to achieve CMMI Maturity Level 3 so that SA could bid on lucrative defense contracts. My job was to get the program in place, exercise it across a series of internal projects, and then arrange for a formal company-wide appraisal.

Beginning pretty much from scratch, we were able to build the program over a series of months, and a pretty good program at that. But when it came time to begin using it, I began to get conflicting messages from the project management office. This office was directed by a fellow named Mike McScottle, a guy with “PMP” stamped prominently on his business card. Mike administered the assignment of project managers and facilitated that reporting chain up through executive management. The point of contention was that Mike’s project managers were not deploying the process program to new projects. I went to see him about this. Had we misdesigned things? No. Were the right assets not ready? No. Well, then what?

Mike said it was simply a timing issue. He explained that he assigned particular project managers to particular customer projects with the right personality mix in mind, with sensitivity to the project manager’s individual approach. To mess with that now by introducing new methods and procedures would jeopardize project equilibrium. He wanted to wait for the right time to roll the program out, a time when the right “client-culture mix” came along.

Now, I am not sure I know exactly what a client-culture mix is, but at the time it didn’t sound like “we’ll do it” to me. Needless to say, the Level 3 program stalled in the hands of people who did not want to learn it or use it. Last I heard, SoftMil had abandoned its process initiative altogether and the company, having lost most of its project business, supported itself mainly through staff augmentation. SA shifted its CMMI directive to another internal division.

In the field of technology development, an organization’s ability to successfully manage its project work is an indication of its overall ability to successfully manage itself. Today we have the skilled resources and tools we need to develop and deploy the most sophisticated of technology systems. Technical innovation and complexity are no longer the impediments to achievement they once were. More and more, the emerging differentiator is management: management at the strategic level, at the program level, and perhaps most essentially, at the project level.

When you look at it in a pure light, almost all organizational success comes from project success—because almost all organizational work is organized into project initiatives. That’s true for just about all of corporate America, not just technology shops. But this trait has a tendency to carry more and more weight in technology shops because today’s technology projects carry the full weight of the business mission on their shoulders.

And so it’s important today for technology shops to embrace the proper form and function of project management, to view it as an essential component to a responsive and accountable management program, and to ensure that competent project management skills and practices are in place in the shop.

That brings us to the topic of process. The terms process, process improvement, and process management are being tossed around a lot these days in discussions of management and organizational efficiencies. But many times the rhetoric has little push behind it. Many of the executives and managers I know have an intuitive appreciation for process and its relationship to sound operations, but their practical understandings—and often their practical experiences—bring out concerns of overhead, inflexibility, and uncertain investment. Process seems by default to be heavy to them. That’s an improper perception, and it’s one I deal with continually in my practice as a process consultant.

The important point is that process does not have to be heavy, and it does not have to stiffen an organization. It need not require a large investment (although it will require some kind of investment), and it need not add a layer of overhead to a company’s layout.

That’s what process does not have to be. What it should be is a carrier of corporate values.