TRANSFORMING THE IS ORGANIZATION
Once the IS organization is committed to developing a system of architectural components, IS managers face the task of transforming the way the IS function itself interacts with the legacy portfolio. Because IS managers have relatively stagnant budgets, improvements must be rapidly self-funding. Such improvements result from five sources:
1. Better alignment of business and IS goals and strategies
2. Better partnering between the business and IS communities 3. Better management and technical processes within the IS organization 4. Better skills, practices, tools, and techniques at the developer level 5. Continuous enhancement of IS capabilities
Transformation of the IS organization centers on managing user demand, legacy systems evolution, and IS resources. There is a tendency to accept the behavior of an IS organization as yet another legacy rather than to challenge old assumptions and reshape managerial approaches. The IS function must fundamentally rethink and reengineer itself in the same way that many organizations are reengineering business processes.
IS management has traditionally focused on significant technology changes that cause work processes, skills, and understanding to lag until they are reshaped.
Recent examples of such change include client/server technology, object orientation, and multimedia. The fundamental issues of IS transformation, however, relate to commonly accepted practices and beliefs — in other words, to the culture within IS
itself.
IS Cultural Change
Craft-Based Development Much IS activity is still conducted in the cultural equivalent of a preindustrial craft. Methods are personal and unstandardized, private knowledge confers power, and success or failure is not readily determined. At worst, code is written in idiosyncratic ways by employees who must be retained to update their personal handiwork, trapping other developers because nobody else supposedly understands that system. Finally, a member of the guild can only be understood and therefore judged by another craftsperson, who is hesitant to criticize co-members.
For example, even though formal peer review is proven as the most cost-effective method for preventing and eliminating coding errors, few IS developers inspect each other’
s work.
A growing body of evidence highlights the severity of this problem. Recent experiments involving personal software production found that some programmers with at least five years of experience injected hundreds of defects per thousand lines of code, with a worst case of more than 1,100.
Fundamental lessons from the quality movement imply that the cost of finding and reworking all these defects must be enormous. Most IS professionals do not recognize the scale of the problem, and most IS organizations lack the metrics to quantify it. Even more startling is the improvement that results after three months of using personal metrics: the same programmers who injected hundreds of defects per thousand lines of code improved their delivered quality by a factor of from five to ten.
Moving to the Age of Engineering Much of legacy management requires IS
organizations to move software maintenance and development from craft work into the age of engineering. Mary Shaw of the Carnegie Mellon University Software Engineering Institute has developed a useful model of this transition for several other professional engineering disciplines (Exhibit 3). In an engineered approach, standards of performance are shared and transferred, patterns of work are made more methodical, and components are interchanged and reused.
Exhibit 3. Development of an Engineering-Based Discipline (From M. Shaw,
“Software’
s Current Crisis,” Scientific American, September, 1994.) Because this mode of thinking represents a dramatic change in the mind-set of the IS organization, opposition to the software engineering perspective can be widespread. IS managers are challenged to foster recognition by the IS organization of the need for change and to reinvent methods and priorities in accordance with the engineering culture.
Managing the Change Process
Most changes to existing systems are processed in a highly inefficient manner; they take approximately four times as long as a change made during new development.
IS organizations pressured to respond to business units often attempt the quick fix.
Developers routinely enter complex software systems and perform minor fixes (often generating a stream of so-called fix-on-fix errors before completing the job). They then proceed to another task without leaving a record of what they did. The conceptual integrity of the original design, the documentation, and the implemented system itself rapidly degrade as repeated quick-fix alterations build up like electronic scar tissue. Such systems are inevitably difficult to understand and maintain.
Once again, some organizations are fundamentally rethinking their approach by treating the installed base more like packaged software, which means that change requests are rationalized and managed. These organizations have replaced the quick-fix cycle with an iterative enhancement approach that achieves the following significant benefits (Exhibit 4):
Exhibit 4. Quick-Fix and Iterative Enhancement Cycles
§ They gain a broader perspective of a series of minor changes.
§ They resist demand for expensive tinkering that delivers little business benefit.
§ They develop a more efficient approach to maintenance because they reduce the 50 percent of maintenance time that is spent understanding the current application.
§ They use advanced techniques such as workshops, business process reviews, and prototyping to ensure that the right problem is being solved.
§ They protect the integrity of design and documentation.
Through this approach, business and IS partners exert a far greater level of control and address the real business and technical issue. A formal oversight body or change review board joins business sponsors and process owners with IS portfolio managers.
The board maintains a long-range focus (built around the 4R portfolio assessment) and avoids being caught up in the daily routine of change requests. Significant changes obviously require board approval, but even minor adaptations and fixes undergo some less formal scrutiny. Any contemplated change requires the answers to several questions:
§ To what degree is the requested change compatible with the original design?
§ To what degree is the change necessary?
§ How much will the change enhance the system? Does the benefit justify the cost? Is the change compatible with the strategic plan?
§ Is the change within budget limits?
§ How critical is the change compared with others in the backlog?
§ How soon will business payback be realized?
§ Are there combinations of changes that generate economies of scale or other synergies?
After these questions are answered, the organization then classifies changes, groups requests by urgency and business benefit, and establishes a review process to schedule changes by priority, cost-effectiveness, and appropriateness for overall legacy strategy. Urgent tasks — such as those associated with a system failure —
are performed more quickly when the system is well documented and skilled people are available. Minor changes with no strong business case are grouped and implemented in a planned release to optimize the maintenance process.
Once a regular schedule of updates and releases is established, business users rely on organized batches of changes, plan the introduction of change into the business, and see the portfolio as a business asset from a long-term rather than a moment-tomoment perspective. Reducing the time IS personnel spend each day on possibly redundant or ill-advised system changes frees them for more types of work.
The Case for Metrics
What would business be like without a profit-and-loss statement? What would baseball be like without earned run averages and on-base percentages? For most organizations, the lack of legacy metrics is only partially a matter of technical and methodological issues; it may be a prototypical example of the challenge posed by organizational culture.
Although many organizations thus find it difficult to maintain a history of their projects, estimates, and actuals, other organizations do commit to measurement programs and reap dividends. The results of these programs are striking. For example, a recent report on 500 IS organizations found that between 25 and 30
percent (even up to 60 percent) of effort in the few organizations that succeeded in instituting a metrics program is focused on corrective actions on an installed system (in classic quality terms, this is pure rework).
A growing body of support for metrics is originating outside the IS organization in the product and embedded software communities within the business. These outside customers will not return for more poor-quality software. Thus, the issue of me trics is best understood as being fundamentally a cultural conflict and a managerial challenge within IS. The main issue is that as long as solid knowledge about past performance is impossible to find, reliable assessments of future performance remain out of reach. As the following sections indicate, many categories of legacy activity lend themselves to accurate measurement.
Product Measurements How many lines of code were generated, changed, reengineered? How many function points were delivered or modified? How many defects were embedded along the way and how many errors were discovered before delivery? After delivery?
How well do the products satisfy customer needs? How well does a given system add value to or enable a business process?
Process Measurements How many hours were devoted to which projects in the past 12 months? How many of those were direct, indirect, and managerial? What funds were expended where and when? How much time was spent adding value to the application? What were the cycle times? When was testing performed and how effective was it? What kind of work was being performed?