Section 2.4. Six Common Myths

2.4. Six Common Myths

The way to manage technology business more effectively is to define what it is the business does. Once you have defined that, you can begin to operate the business based on that definition. And once you begin to move down that path, you begin to know the path, and you can start to refine the shape of the path. That is the basis for nearly all process improvement initiatives. It seems logical, even intuitive. So why is it that management will often steer away from implanting process, from adopting process improvement as a goal?

The reason could be that management is often not educated as to what process is about. Or they may have been exposed to only poor examples of the discipline in the past. They may have preconceived notions of what process demands or what process requires, and these may not match up well with what it's really all about. Dealing with this, I've noticed six myths that are pretty common to the field of process improvement. They are often identified as reasons why people don't want to bother with process.

Let's take a brief look at the six.

2.4.1. Myth 1: Everything's Fine

There's a company in South Carolina that is one of the nation's largest processors of Medicare health claims. I'll call them MetaCare. Annually, they pay out about $20 billion. They have an impressive corporate campus, a solid service reputation, andfor these daysan amazingly low staff turnover rate.

They also serve a very mature and stabilized industry. The management and processing of Medicare claims depends more on compliance with established regulations than on innovation. The company contacted me about helping them develop an internal process program for their IT groups. But what I noticed when I got there was that they already had a program. It just wasn't highly visible to them. The program was embedded in the contracts they won from Centralized Medicare Services. These contracts dictated how projects would be run, what service levels were expected, how changes would be managed, what communication channels would be honored, who could do this, who could do that. You can probably understand that. A federal agency that is going to hand you the combination to $20-something billion in tax funds is wise to attach some strings.

In my mind, they didn't need another process program. They were doing pretty well.

How many MetaCares are out there? No doubt a few. But in the field of information technology, market stability, fixed revenue streams, and heavy structural dictates are not the norm. The opposite is more often the case.

I spent a few years in the late 1990s consulting with MCI WorldCom. I was with their Local Number Portability group. I was helping them set up a project management team to roll out a new service that would let customers come into the MCI family while keeping their old phone numbers.

Naturally this service hit a lot of MCI's networking systems. The project management teams were going to need a pretty solid methodology to run projects in and out of this new technological infrastructure. When I proposed setting some fixed processes into place, the director of the group balked. Actually it was probably less than a balk. She simply dismissed the idea as if it were one among a full series of possible choices. The culture at MCI, at the time I was there, was not one based on procedural guidelines or well-defined roles and responsibilities. People did whatever they had to do to get the job done. Speed-to-market took precedence over all else. The phrase, "We'll fix it in production" was routinely expressed. In the director's mind, and the minds of most of the people around her, the organization did not need a process program. All it needed was way to move a BellSouth TN into MCI's TN database. Quickly. So that MCI could quickly begin to bill.

From my experience, that's the way many IT shops can be primed to think. "We don't need a process program," may not echo in heads of most CIOs, but I bet that's because the phrase hasn't been invited inside.

Today's technology businesses operate in a hectic environment. Demand is up; users are savvy. And now that technology has become so capital-intensive, it has also become political. Technical solutions are constantly changing; innovation has displaced stability. Maybe it's no wonder that technology management has a hard time focusing on the big picture. There's so much happening at the detail level it can be difficult to pull away.

If yours is a tiny start-up, struggling to simply define and build a product, maybe the organization really isn't ready for process. Or if yours is a mature company, operating in a solidly stable environment, maybe you're already there. But chances are that's not the way it is.

Chances are, the IT organization at hand is moving to the currents of technological flux and change. And part of the reason that this flux and change is pulling management down to the detail is that the organization, in the absence of process, lacks a predictive way of dealing with dynamics.

Process can be viewed in this light as a viewing tool. Once in place, it reflects the way the company operates at both a strategic level as well as a tactical level. This feature may be what causes many executives to avoid the topic. Because to implement a process program, you have to work to define not only who your organization is, but what you want it to become. And that takes work. It takes leadership. It takes a certain amount of vision. Perhaps in such a dynamic industry, those requirements are hard to meet. Perhaps the more expedient route is to simply back up the position that this organizationour organizationdoes not need process.

Views from the Top

BUSINESS OBJECTIVES DRIVE PROCESS VALUE

"The focus of process in technology management should be no different from any other business program. It's important to remember that IT processes are business processes in the same way that accounting processes are business processes.

"The key to implementing effective processin any environmentis to shape the activities so they address the business needs of the organization. When you do this, the 'Value Proposition' of process becomes clear. Your people will more readily embrace the program because they can see its visible link to business objectives, and therefore to their jobs. Also, you end up with a benchmark to measure how well the processes are working to help achieve the objectives."

Linda Butler, Director IT, Corporate Services CIO, BellSouth Telecommunications

"Key to realizing the benefits of a process program is the ability to tie the program's design to the business objectives of the broader organization. In order to do this effectively, you must implement the tools that trace and measure the performance of the program across your enterprise. For example, at an executive level an organization may set a broad goal to 'reduce the cost of IT.' This can be supported at the mid-level by the introduction of a quality and process program designed to 'reduce re-work.' This can be further decomposed to the front line IT employees where individual goals are focused at 'reducing the number of production defects.' Using this approach, you introduce tangible objectives that can be measured at the varied levels to assess the overall success of the program and drive accountability down to the employees.

"This method of tying process design to business goals clearly moves forward the agenda of the enterprise and lets people at all levels in the organization understand the purpose and value of the process program."

Guy Bevente, AVP, Information Technology National Data, SBC

2.4.2. Myth 2: What We Do Is Too Unique for Process

The "We don't need process" idea is, fortunately, an idea on the wane. In recent yearsdue in no insignificant part to the dot-com bubble burstthe industry is more and more turning on to the ideas of accountability and discipline. More and more, companies are hearing about process, about programs like ISO 9001, the Capability Maturity Model, and Six Sigma. About Sarbanes-Oxley.

Initiatives are under way across corporate America to introduce, at least at some level, some degree of recognized best practices. In fact, it's almost become fashionable now to tout the benefits of process improvement, to show that the concepts are appreciated and the benefits understood. And to herald that overall it's a good thing for the IT world. But when you get this level of constrained enthusiasm, it's not uncommon to hear it followed by, "Yes, but it's not for us. What we do is too unique." I'd almost rather hear the we-don't-need-it line.

I know plenty of managers who say they don't want anything to do with process. They believe it, too. And I know managers who sincerely feel that they aren't in a position to focus on process. But whenever I hear that what an organization does is too unique for process, there's always something in the voice that says, "And that's my final word." I think it's a defensive response. In fact, it's rhetorically backward. If what an organization does really is so unique, I would say that there is even a greater need for process, to formally define that tricky thing it does.

Then there is the Rule of Averages, the maxim that says there's very little that is really uniquely displaced in the technology enterprise. No matter what our product focus is or how we direct our services, we share more in common than those elements that set us apart. We all have to deal with customer requirements in one form or another. We have to work against schedules and within budgets. We need estimates and plans. We need to produce documents and work products, and they need to be controlled. We need to keep track of our project teams and the work they are doing. We have to keep our customers informed as to how we are doing. We need to keep management up-to-date. And we need to gather regular metrics to know where we stand at various steps of the way.

Is there any technology organization that doesn't need to do any of those things? You can even remove the concept of technology, and the activities still retain their integrity. They represent basic business fundamentals.

The people who say that what they do is too unique for process are probably trying to skirt the issue. They may prefer to do business in a hectic, reactive environment, one that's dynamic and unpredictable. Many people find that that's a fun way to work. I can see it as being fun, too. As long as there's not too much at stake.

But if people are building products that other people rely on to be rightmaybe the people in marketing, the shipping clerks, the sales force, or the facilities management folksthen maybe there is an obligation to work under some structure.

If they're dealing with stockholder monies and impacting the future value of a company, then perhaps they have a fiduciary responsibility to operate under some form of process. If they are building something that they want the marketplace to embrace en masse, then what's their obligation to the public?

Usually the "too unique" phrase is a mask for a preference to operate on the fly. Business is easier when you don't have to plan, or forecast, or track, or inform. But then it becomes less like business and more like play. I think all technology businesses need process: the more unique, the stronger the recommendation. When people play at businesswhen they play at technology developmentthey usually prove before too long that they don't play very well.

2.4.3. Myth 3: Process Will Cramp Our Style

People in technology tend to understand and appreciate concepts of flexibility and adaptability. That's the nature of our business. When you work in technology for a time, you might begin to think that the people who really make things happen are, among others, the cowboys and the gunslingers. It's cool to see someone shoot from the hip and hit the target dead-on. In an environment of cowboys and gunslingers, firefighters and artistes, individuals and lone wolves, gurus and magicians, the idea of process might be a bit threatening.

People who don't work in process-centric environments can easily perceive process as a series of roadblocks. They might think that process will constrain them to the point of immobility. That it will rob them of their freedom of expression, of their unique approaches to problem solving. Of the imprint of their personal identity.

Is that the goal of process? Of course not. Process well-defined, well-considered, and geared to driving business objectives is not a roadblock. It's a fence line. If you run the fence line, you're free to move in and out. But as long as you keep the fence line in view, you'll always know where you are and where you're going.

On the other hand, there are certainly circumstances in which process will cramp style, and thank goodness for that. I have been in shops where I would have liked nothing better than to see a heavy dose of process descend from on high and cramp as much runaway style as possible. In fact, the best example I can think of is a company I once ran.

In the mid-90s, I owned a software company called Public Health Software Systems. We developed and deployed software that helped public health departments track and manage the delivery of immunizations to young children. We were a young bunch, energetic and enthusiastic, and we liked the idea of our niche. The problem we faced turned out to be success. In those years, President Bill Clinton was working on his own immunization initiative, and he was pumping hundreds of millions of dollars into the public health sectors, providing funding for health departments to better manage their immunization programs. With this funding influx, health departments could now afford to automate their record-keeping systems. Counties from all across the nation came to our door, ready to buy our product. Thing was, we weren't exactly ready for broad market appeal. We had no real business identify. My partner and I were known simply as the "two guys who do computers."

Actually, we were 19 people with energy and knowledge but no business approach, no insight into market expectations. And no real approach to product engineering. We had a good base product, but in hindsight, there's nothing more I would have liked to have had than a good dose of development process. We were so loose, we needed boundaries. Fortunately, a much larger corporation wanted in on the immunization trend, and they purchased our company, folding it under an anonymous corporate umbrella.

However, the better view to take might be that process, properly applied, does not cramp style. It liberates style. In a process managed environment, people don't have to figure out how to do the routine jobs. That figuring out has been done already. People don't have to feel their way through business flows. That map has been drawn. They don't have to invent how to integrate or how to verify or how to report. When they are freed from that routine, they are then free to innovate, to create, to think, and to apply their technical skills in innovative and focused ways.

2.4.4. Myth 4: We Can't Afford the Overhead

When people are working full steam to get a product out, or when they are trying to marshal the troops to get an organization organized, there can be a tendency to want to cut out everything seen as superfluous. To get down to core essence, back to basics. And when people aren't versed in process or maybe have little background in organizational design, they can tend to see lots of things as being superfluous.

I once advised management at a software company in Atlanta that was going through rough times. Their product had slipped from a competitive position in the marketplace. Management was scrambling to get back on track. They brought in a host of new contract programmers to crank out new code. They had their testers working 12-hour shifts, seven days a week. And here's another smart thing they did: they cancelled the plant-watering service. They decided they couldn't afford the overhead of watering the plants.

The advice they were looking to get from me was how to sequence these hectic activities into some semblance of a production line. I mapped out a very light framework of milestone definitions, team goals, communication avenues, and peer reviews. I wasn't entirely satisfied with it. It didn't seem accountable enough. And for the amount of money that was going into this scramble, I didn't like to see so many potential side-door openings. But it was, I thought, a beginning.

Management, however, was not going to buy it. They thought I was going to recommend some kind of automated tool set, something they could plug in and turn on. When they saw I wanted to change the way work was being done, they balked. They told me they didn't have time to reorder the group dynamics. They needed these people to go after the problem full bore. The overhead of process was simply too much. So the process recommendation died first. And then the plants. The company was not far behind. It didn't die, but its parent sold it for a quick price to another player and got quietly out of that particular industry.

Process, early on, will indeed add some overhead. After all, you have to introduce something new into the organization. You are attempting to change the organization. This will require a degree of people, resources, energy, and investment. But the focus of well-done process is to reduce inefficiencies, to minimize waste. And when a process program is built that way, overhead should fall. It is when the organization is unguided and unfocused that the lines between product cost and overhead blur. It may even appear that overhead is thin because product costs have crept into an area in which they do not belong. Process has taken over funding that should have been reserved for other priorities.

Like the plants.

2.4.5. Myth 5: Process Is Heavy

This may be the biggest myth surrounding process improvement: that any process program is by necessity heavy, that it will weigh down or confuse the organization, that it can have no real organic place in the daily life of a company.

I have heard this even from CEOs and CIOs who believe in process. Their mark of wisdom is to advocate selective use of programs like ISO 9001:2000, CMMI, and Six Sigma. They recommend borrowing those elements that fit your specific needs.

By and large, that's good advice. I offer it up, too. It is a good idea to use the established models and frameworks as sources of best-practice advice. But the implication here is a little misleading. The subtext says, use the pieces because the full sets are too much. They are too heavy.

Throughout this book, I'll be stating and then reinforcing the difference between light process and heavy process. Process is not by nature heavy. If you choose to implement ISO 9001:2000, you can implement it in a light way. If you elect to achieve CMMI Maturity Level 3maybe 21 Process Areasyou can do so in a light way. If you want to use Six Sigma with a deep set of statistics, you can do so in a light way. The reason that people think process is a heavy thing is because people often turn it into a heavy thing.

When people begin to develop processes for their organizations (and I'm assuming here that they are qualified and have been prepped to do it properly), they soon discover that they can map out basic activities very efficiently. And then they discern that they can take that a step deeper, and so they do. And then they discover more activities that can be logically supported by process, and so they take on those. The heaviness that ensues is not a product of process. It's a product of people's success with process. It represents the enthusiasm of a solution discovered to be readily applicable. But maybe premature.

The need is simply for discipline, for a definition in direction so that just the right amount of process is applied. Lay it on light. Use it in that form until it is habit in the group. Then expand it to further serve the organization.

But avoid the trap that process is heavy. If you print out the core essence of the ISO 9001 Standard, or the goals of CMMI, or the DMAIC framework of Six Sigma, each would tip the scales at less than four ounces.

That's about as heavy as process starts. Where you take it from there is up to you and the needs of your people.

2.4.6. Myth 6: That's Just Another Flavor of the Month

There's not a lot about the discipline of process improvement that I take personally anymore. Twelve years ago I was a novice. Ten years ago I was an enthusiast. A little later I was an evangelist. Now, after a dozen years of working process in corporate America, I have moved to the position of being an observer.

I like helping companies design and implement process programs. I like seeing them succeed in this arena. But when I run up against resistance, especially at executive and management levels, I don't feel compelled to convince anymore. I'll help educate if that's requested. But I don't really feel the need to prove the wisdom I have found in process programs, process improvement, and process management. However, there is one attitude that I sometimes feel obligated to discuss. That's the attitude that process in generalor a particular process program (ISO, CMMI, Six Sigma)is just another flavor of the month, just another trendy solution put forth to solve a well-established problem.

But anyone who has seen a well-designed ISO 9001 program in active use would be hard pressed to dismiss it as a flavor of the month. The same for CMMI. And companies like GE and Motorola have presented a wealth of documented evidence as to the effectiveness of Six Sigma.

Often the people who tend to label these kinds of programs as flavors of the month are actually expressing their own limitations to commit to the regimen and discipline of process improvement. The term "flavor of the month" means basically that you try something for a month and then, if it doesn't taste quite right, you throw out the recipe and start all over. If that mix doesn't do it, you toss it out, too. And on and on and on. In other words, there's no time to get the mix right. Quick results are the only proof.

There are a host of reasons why process programs can go awry, and just as many reasons why process programs might fail to live up to their potentials. But it's rarely because the flavor is wrong. What's lacking is the full appreciation that process improvement takes time.