Risks Inherent in Organizational Innovation

In consultation with users, analysts must consider the risks that organizations face when adopting new methodologies. Clearly this is part of a larger question of when is the appropriate time to upgrade human skills, adopt new organizational processes, and institute internal change.

In the larger sense, these are questions of a strategic dimension for organizational leadership. Specifically, we consider the case of the systems analysis team adopting agile methods in light of the risks to the organization and the eventual successful outcome for the systems development team and their clients. Figure illustrated below shows many of the variables that need to be considered when assessing the risk of adopting organizational innovation.

Adopting new information systems involves balancing several risks.

Organizational Culture

A key consideration is the overall culture of the organization and how the culture of the development team fits within it. A conservative organizational culture with many stable features that does not seek to innovate may be an inappropriate or even inhospitable context for the adoption of agile methodologies by the systems development group. Analysts and other developers must use caution in introducing new techniques into this type of setting, since their success is far from assured, and long-standing development team members or other organizational members may be threatened by new ways of working that depart from customary, dependable approaches with proven results.

Conversely, an organization that is dependent on innovation to retain its cutting edge in its industry might be the organization most welcoming toward agile innovations in systems development methods. In this instance, the culture of the organization is already permeated with the understanding of the critical nature of many of the core principles of agile development methodologies. From the strategic level downward, the company’s members have internalized the need for rapid feedback, dynamic responses to changing environments in real time, dependence on the customer for guidance and participation in problem solving, and so on.

Located between these extremes are organizations that do not rely on innovation as a key strategic strength (in other words, they are not dependent on research and development of new products or services to remain afloat) but that might still wish to adopt innovative practices in small units or groups. Indeed, such small, innovative centers or kernels might eventually drive the growth or competitive advantage of this type of organization.

Timing

Organizations must ask and answer the question of when is the best time to innovate with the adoption of new systems development methodologies, when all other projects and factors (internally and externally) are taken into account. Organizations must consider the entire panoply of projects in which they are investing, look ahead at project deadlines, schedule the upgrading of physical plants, and absorb key industry and economic forecasts.

Cost

Another risk to the adoption of agile methodologies for organizations is the cost involved in education and training of systems analysts and programmers in the new approach. This can involve either costly off-site seminars and courses or hiring consultants to work with current staff onsite. Further, opportunity costs are involved when systems developers are necessarily diverted (albeit temporarily) from ongoing projects to learn new skills. Education in itself can be costly, but an additional burden is recognized when analysts cannot earn income during their training period.

Clients’ Reactions

When clients (whether they are internal or external) are involved as users or initiators of information systems development efforts, reactions to the use of new methods entailed by the agile approach are also a key consideration. Some clients react with joy once the benefits of timeliness and involvement are described. Others do not want to be used for systems “experiments” with uncertain outcomes. The client-analyst relationship must be resilient enough to absorb and adapt to changes in expected behaviors. For example, the onsite presence of a client during development is a major commitment that should be thoroughly understood and agreed upon by those adopting agile methods.

Measuring Impact

Another consideration for organizations adopting agile methodologies is how to certify and measure that the new methods are going to facilitate successful systems development. The strengths and weaknesses of traditional structured methods used to develop information systems are well-known.

While there is ample anecdotal evidence that agile methodologies are superior for development under some conditions, their history is short-lived and not yet empirically supported. Therefore, the adoption of agile methodologies carries with it the risk that systems created with them will not be successful or will not adequately interface with legacy systems. Measuring the impact of the use of agile methodologies has begun, but organizations need to be vigilant in proposing impact measurements in tandem with the adoption of new methods.

The Individual Rights of Programmers/Analysts

Successful systems developers (analysts and programmers) exercise creativity in their approach to their work, and they deserve the right to work in the most fruitful configuration possible. It is possible that the working requirements of new agile methods (for example, pair programming) encroach upon some basic rights of creative people to work alone or in groups as the design work dictates. There is no “one best way” to design a system, module, interface, form, or Web page. In the instance of systems developers, creativity, subjectivity, and the right to achieve design objectives through numerous individual paths need to be balanced against the organizational adoption of innovative approaches such as agile methodologies.

As you can see, adopting organizational innovations poses many risks to the organization as well as to individuals. We examined risks to the organization as a whole as well as to those posed to the individual systems analyst who is caught up in the organization’s desire to innovate.

Contents