All Posts in Leadership

|In: Leadership|Last Updated:

In my first exposure to business process re-engineering, our chosen consultant explained how Information Systems is “just like a factory.” We have a process for understanding the products we’re supposed to create (systems requirements analysis), another process for designing them (systems design), one for building them (systems development) and one for distributing them to our “customers” (operations). Since factory and systems processes line up one for one, IS is a factory, right?

And it is, except for everything we do. I could probably figure out a one-to-one correspondence between a factory and human courtship rituals, but that doesn’t mean human courtship is a factory either. (Let’s agree to not explore the parallels.)

In our ongoing quest to improve ourselves, many of us have tried to apply process redesign to IS, and for the most part the results haven’t been pretty. The biggest problem has been a misunderstanding about what constitutes a process. It’s a process if you do it over and over again. It’s an ad hoc task if you do it once or infrequently. Carefully designing and documenting processes for handling ad hoc tasks is pointless.

This week we continue to create our integrated IS plan, zooming in on the core processes of IS. Your first step is to identify the core processes that most need fixing and include in the plan initiatives to improve them. Improving them is important because employees only have five choices in how they get their work done. They can:

1. Improvise constantly because there is no well-defined process.

2. Slavishly follow a poorly designed process that leads to mediocre results.

3. Fight with a poorly designed process that interferes with achieving excellent results.

4. Improvise constantly, ignoring the well-designed process that would facilitate the creation of high-quality results.

5. Follow a well-designed process to create high-quality results.

It isn’t a core process unless you do it over and over again, so the process you instinctively thought of first — systems development — is rarely worth your time and attention. (You buy whenever you can, building new applications only when you’re desperate.) If you’re a typical IS organization, your core processes are vendor/product selection, systems integration (very different processes from systems development), systems maintenance, end-user support, and data center operations.

Since you can’t fix everything, choose the one or two processes that are broken the worst and include initiatives to fix them in your integrated plan.

How can you tell if a process is broken? Simple — your performance measures for that process don’t show an improvement trend. Don’t have process performance measures? Your integrated plan just got another entry: “Develop process performance measures.” Just remember:

  • What you can’t measure, you can’t manage, but when you mismeasure, you mismanage.
  • Measure what’s important, not what’s easy to measure. The two are mutually exclusive because the more important something is, the more subjective and less measurable it will be.

(Please note: Performance measures are for managing processes, not people, so focus on creating process measures, not staff performance measures. They’re two very different issues.)

Underlying all of your core processes are a few important organizational capabilities. I’m constantly surprised at how many IS organizations aren’t very good at decision-making, project management, data modeling and data management, systems library management, and training, but it’s true nonetheless. If you’re deficient in these capabilities, you won’t be able to improve your processes, so make sure your integrated plan addresses any problems with them.

Not everything is a process, no process fits every situation, and no process is good enough to survive employees who neither understand it nor care about its success. Process isn’t everything.

Saddling your employees with bad processes is like handicapping them with handcuffs and leg-irons, though, so make sure you give them processes that help them get their work done instead.

Comments

|In: Leadership|Last Updated:

A lot of my correspondence comes from people who think their employers should do more — or at least anything — to make their workplace more enjoyable and fulfilling.

They’re right. The correlation between treating people well and a higher-quality workforce is not exactly controversial, and even with a cooling economy good employees have no trouble finding other work.

When the shoe is on the other foot, though, a lot of you seem far more interested in keeping your headaches to a minimum than in creating a quality work environment for everyone else in the company.

Yes, it’s mailbag time here at the IS Survivalist Institute, so we’re going to defer our continuing exploration of the integrated IS plan until next week. This week we’ll deal with the mail I received following my column describing how IS botched the introduction of the PC and still hasn’t learned from its mistakes..

The mail I received split demographically into writers who lived through the introduction of the PC and agreed with my recounting of events, and those who didn’t and didn’t. A question: If you weren’t there, how come you’re so willing to disagree with eyewitnesses?

To those readers who pointed out that as company resources, PCs shouldn’t be under end-user control, you make a good point. And since that desk you’re sitting at is a company desk, you won’t mind when internal audit goes through your drawers, file, and interoffice mail on a regular basis, will you?

Besides, IS often causes far bigger problems than individual end-users. When it’s your installation, though, you blame the vendor instead of accepting responsibility for poor planning and testing. (Yes, vendors could make it a lot easier, but they don’t. Deal with it.)

The mutual finger-pointing that goes on between IS and end-users starts with you blaming them. If Dell can build millions of PCs to order, you can do better than delivering a one-size-fits-all minimalist PC configuration and then complaining when employees individualize their systems. Here’s the program:

1. Segment your user community: Talk with a wide variety of end-users and their managers, and define five to 10 logical groupings, such as basic users, travelers, power users, mentors, and heads-down data entry staff.

2. Determine work habits: You may be surprised at the complexity. Consultants, for example, sometimes have network connections, sometimes use modems, and sometimes connect to client networks. If you don’t carefully craft an appropriate work environment, they’ll be in Network Neighborhood every couple of weeks. And you’ll blame them for goofing up their systems.

3. Determine resource needs: For each logical grouping, draw a picture with a member of the group in the middle. Around the periphery draw the resources they need access to. Then figure out how they’ll get that access.

Don’t assume. Ask — and be prepared for surprises. That group you thought was a candidate for NCs may not be, for example, because they send and receive e-mail with Microsoft Office attachments. Don’t argue, either. For example, I refuse to use Outlook as my personal information manager, because I rely heavily on Ecco Pro’s outlining capabilities. I’m willing to use something else, but not to give up capabilities I make extensive use of. Don’t argue: I know how I work better than you do.

4. Plan configurations: Tailor standard configurations for each group. Design them. Show them to group members. Test them. Assign people in your group to try them on for size. Push, poke, and stretch them. Find out where they break and where they develop DLL conflicts. Fix what you can fix and train the help desk on what to expect.

5. Roll them out: You have some retrofitting and training to do, so plan the roll-out carefully to minimize disruption. This should be fun, though, because almost without exception you’ll be improving employees’ work environments in a recognizable, tangible way.

6. Keep it current: Review your standard configurations at least annually to see if there’s anything you need to change.

Sound like a lot of work? Maybe, but it’s both less work and more rewarding than responding to the problems and complaints you get now.

Comments