InformationWeek
Defining The Business Value Of Technology
September 1,
1998
Your letters to my print
column and this E-mail forum ask some serious questions about managing information
technology in today's world. Since today's world is essentially absurd, my serious responses may
sometimes sound a little whimsical, and my occasional whimsical ones, serious. In any case, if
you want to participate, write to me at lovelace@home.com. I'll respond to those letters that I
can. I reserve the right to edit for size and content. Just sign your E-mail the way you want it to
appear online.
Dear Herb:
I'd appreciate it very much if you could help us with the following issue.
We have an Industrial Engineering department, which was established a few months ago in our company here in Israel. The new department is in charge of process analysis and definition. The employees are IEs and some of them have systems analysis experience and formal education.
On the other hand, we have an IS department, which historically has been in charge of systems analysis, programming, and selection of software tools. Most of the employees are programmers, and only one is a systems analyst with some experience. There has been a high turnover rate in this department over the years. None of the employees have formal education or much experience in process definition.
As expected, there are turf wars between the two departments, and a lot of tension, which is harmful to the organization. Management doesn't quite know what to do and thinks the IE department should define the processes and then pass on these definitions to the IS department, which would continue the work, including systems analysis.
I have argued against this rather strange method, since in my experience you can't divide the responsibility between departments and this isn't like a race in which you run the first lap and then pass the baton to the next runner, and then just forget the whole thing.
Obviously, the division of labor depends on many factors, such as the capabilities of the people involved, leadership, willingness to take responsibility, the organizational culture, and so on.
So here are my questions:
1. What would be a common/accepted mode of division of labor?
2. What would be the main benefits and/or problems with the various ways of separating process analysis, systems analysis, and programming?
3. Would a transfer of people from one department to the other be beneficial?
4. Could you tell me of your experiences or of examples in the U.S. regarding this issue?
Many thanks,
Danny W.
Dear Danny:
Whenever one department has to hand work over to another department, tension results unless you are dealing with an unusual organization staffed by unusual people. When you have lots of words like process analysis, process definition, and systems analysis, the management of the company needs to spend a great deal of time explaining what those words mean and the boundaries between responsibilities. After you do that, you have to allocate even more time resolving the inevitable disputes as to what you meant when you described things in the first place.
The line between process analysis/definition and systems analysis is not as clear as the one between systems analysis and programming--and I don't think the boundary between systems analysis and programming is very clear. In my opinion, the only advantage of separating the functions among departments is to accommodate the span of control capability of the managers. In other words, if the number of people to be managed is small enough or the manager is skilled sufficiently to handle the range of skills, then there is no advantage in my mind in separating the functions at all. In that respect, I see no value in transferring people, only in combining the groups themselves as a mechanism to eliminate the infighting.
In the United States, in an earlier age, much of what we call reengineering was done by industrial engineers in our factories. Today, we use the term reengineering in a broader vein, but the basic concepts are similar. Our experience has been that many of the more progressive organizations are making their IT and reengineering functions work more closely together, and in some instances putting the responsibilities under the same executive. Problems get solved faster and staff members have the ability to learn from each more easily.
Dear Herb:
I just joined a very large company that has quite a large technical support staff. During my initial "get-your-feet-wet" period, I found that they are beginning a huge rollout of Windows 95 and NT and no one ever did the requirements analysis planning!
Since I am, shall we say, negatively passive, I brought it up in a meeting. Wow! Have you ever felt like a cat in a dog fight?
How do you relay to people that the requirements analysis is paramount to success?
John S.
Dear John:
It is difficult to convince someone to listen if they are completely ignoring what you have to say. Discussions of religion, politics, and software upgrades are subjects best not discussed in polite company.
For a situation in which an organization has a cultural bent toward having the latest and greatest, it is extremely hard to change the direction of the troops, even if you are the boss. As a result, you should recognize the issue is not the particular upgrade, but rather the whole concept of how the organization views itself. In other words, as the new kid on the block, you probably have the same likelihood of success as that cat you are talking about in explaining that they should actually investigate whether they really need the upgrade.
Dear Herb:
Full Disclosure: I am an IT management consultant.
I agree that information technology (the hidden assumption) should not be left holding the bag to justify projects. The business person should be the one to pitch the project (pay for it) and be its sponsor through thick and thin.
But, the CIO (who should have some business savvy if his or her title begins with "chief" and ends with "officer") should be the one to help the business lines (a) find opportunities to use IT better, and (b) make sure the projects are cost-justified.
This relationship is where the "partnership" is meaningful: IT and its projects cannot survive without the sponsorship and buy-in from business lines and senior management, and the executives and line organizations cannot by themselves figure out the best and most innovative ways to employ IT in the business (which is why they hired a CIO!).
By the way, I believe strongly that some projects can be justified strategically, but I don't accept your definition of strategic value as meaning you can't figure out the hard dollar benefits. This is 1998 after all, and there are very few firms, from General Motors on down to the corner laundry, that couldn't employ IT to achieve competitive advantage and increased revenues/profitability if they have their thinking caps on, and enough capital. Last time I checked, that is absolutely the definition of strategic, yet it has nothing special to do with selling out.
Any holes to punch in that logic?
Kevin M.
Dear Kevin:
No problem with your idea of the partnership. In fact, I particularly like your comments about the CIO requiring business savvy. To me, the partnership means that the CIO makes sure the tools are available to support the business plans and communicates the capabilities of the technology to make new innovation. On the other side, the business person explains the business plans and supplies the benefits. The problems occur when either side does not fulfill its part of the bargain, such as when the IT people do the justification of the projects.
While I don't disagree with your thoughts about strategic value, I frequently find that people have used the words "strategic value" whenever they cannot justify a project on any other basis. Many of these projects have about as much strategic value to a company as a fax machine has to a fish.
Dear Herb:
I agree wholeheartedly with your article, "The Hidden Assumption." I just believe that you do not go far enough. It is the business units that scream the loudest about how changes forced on them by the IS department are disrupting their work. I believe that they must initiate, participate, and own all of the systems that they use. I see IS as a service to implement and support, not reengineer.
Oh sure, we probably know more about how IS can help them do their jobs than they do. We need to channel ideas to the department heads so they can evaluate for themselves. They need to go to the well for approval and funding. No project will succeed without the department's buy-in.
Maybe what I am saying is beyond the scope of your column. I just see the willingness on the part of departments to use IS as the scapegoat for any problem attached to a computer. I am talking about responsibility here. IS does not have authority over many areas that it seems to be responsible for. Take training. A department head will tell me that his new people are not trained on their system.
"Really!" I say. "When did you get new people?" Is it my job to scan the employee lists to search for new hires? Why is it beyond his capability to introduce me to people as they are hired and arrange a couple hours for their training? Why did he just realize that tons of bad data were entered into his system?
The training AND the data are his responsibility. I provide training and system maintenance.
OK, enough ranting. I look forward to your next column.
Jim S.
Dear Jim:
Do I detect a tad of frustration in your voice? Not to worry. You are not alone.
I would agree with what you have to say with the possible exception of the comments on reengineering. I think all of us in a company are in the boat together and if the IS department can see ways of simplifying the processes they are about to automate, it is their responsibility to identify the potential benefits. I suspect you and I agree that it is not appropriate for IS to try to ram the changes down the throats of the business if for no other reason than that tactic never works.
With respect to the training problem you raise, I think you could not be more correct. You might enjoy a column that I wrote about the subject titled, "Won't Train? Don't Complain."
Herbert W. Lovelace is CIO at a multibillion-dollar international company. Herb practices his day job under an alias and has changed the names of colleagues to protect the guilty.
Got a question for The Secret CIO? Just send an E-mail
Send Us Your Feedback
Top of the Page
Featured Microsite
