5
Risks involved in management of technology innovations Andrew Iserson, MSITS Mark Thompson, P.E. PB Farradyne Rockville, Maryland INTRODUCTION The field of information technology has been in a constant state of innovation since the introduction of the original mainframe computers. No matter the type or reason for computing there seems to always be the desire for more and more innovation. Innovation may lead to a strategic advantage for an organization, or may be a death-blow making a project more complicated, more expensive, and require a significantly longer project schedule than can be justified. Organizations find differing reasons to move towards innovation in technology development. Reasons range from: cost issues of components of parts of the system supporting new pieces and parts of the system simply wanting something new being required to use the latest and the greatest technology by an RFP requirement marketing driven choices to support the sales force with the latest technology “buzz” staffing issues such as retention through technological challenges planned obsolesces of previous technologies Any and all of these types of reasons may push an organization towards innovations. Infrastructure and peripherals have the opportunity of adding substantial costs to the total systems cost. In a pragmatic view of the system it is the total-cost-of-ownership (TCO) that is important to the end user. When pieces and parts of the system substantially raise the TCO, the underlying architecture must change in order to reduce this cost. Historically an example of this has been costs of telecommunications infrastructure for distributed organizations. During mainframe days when the computer was the center of the information systems infrastructure, leased lines were required between the mainframe and each user. With offices and users spread across a continent the ongoing costs of the telecommunications infrastructure added significant costs to the TCO. In order to substantially lower the TCO for distributed systems new, innovative architectures were used. These involved moving mainframe functionality to minicomputers, allowing connectivity through dial-up connections. By eliminating the need for leased lines the costs were dramatically lowered. But, the architecture that was used was unique and imposed many risks, both from a development and an operational point of view. New technologies continue to become available quickly. The technologies are announced and touted well before they can reliably be integrated into a project or an organization’s systems. Whether the technology is in the shape to be currently integrated, an organization wants to spend their budget on systems that will have as long a life as possible, provide the greatest marketing impact or increase overall functionality. The specified requirements therefore will typically be for the latest and greatest technology that has hit the press. In order to win the work, both internal and external IT organizations are likely to sign up for these risky interfaces. The interfaces may be to either new hardware or software products. Newly introduced hardware has the probability of not working as advertised and documented. This may mean extra time and effort spent on finding a work around. In a worse case it may involve working with the vendor on updating their product. Interfaces with newly developed hardware add risk to development process. Upgraded operating systems and other infrastructure components add their own complexities and related risks to development products. As is true in newly introduced hardware, there has been a history of newly developed infrastructure components that do not initially work as advertised and documented. The propensity of software components being introduced with errors is higher than those with hardware. This is due to the relative cost to the producer of changing hardware products after production has begun versus the cost of changing software products after production has begun. Software changes and error fixes are introduced at any time during the production process. These changes may or may not be indicated to the consuming public. Called “slip- streaming”, changes are introduced without changing the publicly available release/version number to solve reported problems. Updates may also be made available through the company’s web site for resolution to problems. This type of error resolution is not always possible with errors in hardware being delivered. New development methodologies may also be an impetus for adding innovation to the development process. Each time a new development methodology is introduced it is touted as being able to save time and money on the initial development and future maintenance. This has happened recently with various forms of object oriented programming and again with Agile programming. Each of these methodologies uses mathematical principals to improve the end product. In each of the methodologies different best practices are emphasized. In all cases though, there is a learning curve involved in beginning the use of a new methodology. Risk exists in that non-mathematically oriented 0-7803-9139-X/05/$20.00 ©2005 IEEE. 856

[IEEE 2005 IEEE International Engineering Management Conference, 2005. - St. John's, Newfoundland & amp; Labrador, Canada (Sept. 11-13, 2005)] Proceedings. 2005 IEEE International

  • Upload
    m

  • View
    212

  • Download
    0

Embed Size (px)

Citation preview

Page 1: [IEEE 2005 IEEE International Engineering Management Conference, 2005. - St. John's, Newfoundland & amp; Labrador, Canada (Sept. 11-13, 2005)] Proceedings. 2005 IEEE International

Risks involved in management of technology innovations Andrew Iserson, MSITS Mark Thompson, P.E.

PB Farradyne Rockville, Maryland

INTRODUCTION

The field of information technology has been in a constant state of innovation since the introduction of the original mainframe computers. No matter the type or reason for computing there seems to always be the desire for more and more innovation. Innovation may lead to a strategic advantage for an organization, or may be a death-blow making a project more complicated, more expensive, and require a significantly longer project schedule than can be justified.

Organizations find differing reasons to move towards innovation in technology development. Reasons range from:

• cost issues of components of parts of the system • supporting new pieces and parts of the system • simply wanting something new • being required to use the latest and the greatest

technology by an RFP requirement • marketing driven choices to support the sales force

with the latest technology “buzz” • staffing issues such as retention through

technological challenges • planned obsolesces of previous technologies

Any and all of these types of reasons may push an organization towards innovations.

Infrastructure and peripherals have the opportunity of adding substantial costs to the total systems cost. In a pragmatic view of the system it is the total-cost-of-ownership (TCO) that is important to the end user. When pieces and parts of the system substantially raise the TCO, the underlying architecture must change in order to reduce this cost. Historically an example of this has been costs of telecommunications infrastructure for distributed organizations. During mainframe days when the computer was the center of the information systems infrastructure, leased lines were required between the mainframe and each user. With offices and users spread across a continent the ongoing costs of the telecommunications infrastructure added significant costs to the TCO. In order to substantially lower the TCO for distributed systems new, innovative architectures were used. These involved moving mainframe functionality to minicomputers, allowing connectivity through dial-up connections. By eliminating the need for leased lines the costs were dramatically lowered. But, the architecture that was used was unique and imposed many risks, both from a development and an operational point of view.

New technologies continue to become available quickly. The technologies are announced and touted well before they can reliably be integrated into a project or an

organization’s systems. Whether the technology is in the shape to be currently integrated, an organization wants to spend their budget on systems that will have as long a life as possible, provide the greatest marketing impact or increase overall functionality. The specified requirements therefore will typically be for the latest and greatest technology that has hit the press. In order to win the work, both internal and external IT organizations are likely to sign up for these risky interfaces. The interfaces may be to either new hardware or software products.

Newly introduced hardware has the probability of not working as advertised and documented. This may mean extra time and effort spent on finding a work around. In a worse case it may involve working with the vendor on updating their product. Interfaces with newly developed hardware add risk to development process.

Upgraded operating systems and other infrastructure components add their own complexities and related risks to development products. As is true in newly introduced hardware, there has been a history of newly developed infrastructure components that do not initially work as advertised and documented. The propensity of software components being introduced with errors is higher than those with hardware. This is due to the relative cost to the producer of changing hardware products after production has begun versus the cost of changing software products after production has begun. Software changes and error fixes are introduced at any time during the production process. These changes may or may not be indicated to the consuming public. Called “slip-streaming”, changes are introduced without changing the publicly available release/version number to solve reported problems. Updates may also be made available through the company’s web site for resolution to problems. This type of error resolution is not always possible with errors in hardware being delivered.

New development methodologies may also be an impetus for adding innovation to the development process. Each time a new development methodology is introduced it is touted as being able to save time and money on the initial development and future maintenance. This has happened recently with various forms of object oriented programming and again with Agile programming. Each of these methodologies uses mathematical principals to improve the end product. In each of the methodologies different best practices are emphasized. In all cases though, there is a learning curve involved in beginning the use of a new methodology. Risk exists in that non-mathematically oriented

0-7803-9139-X/05/$20.00 ©2005 IEEE. 856

Page 2: [IEEE 2005 IEEE International Engineering Management Conference, 2005. - St. John's, Newfoundland & amp; Labrador, Canada (Sept. 11-13, 2005)] Proceedings. 2005 IEEE International

individuals will have a harder time learning these new techniques and are likely to make the system significantly less efficient than through use of the previous methodologies.

At times change is desired simply to introduce something new. The desire for something new may be based on real or perceived market forces, or based simply on personal desire.

Customers investing in new product want to feel that their money is being spent on a product that is the latest and the greatest. When investing scarce resources on a new system, the consumer desires a product that will have a long life, one that will provide the desired results in the most current technology possible. History has shown that virtually every system reaches a point of planned obsolesces. Many of these customers have had to deal with the transition of good working systems due to planned obsolesces. Therefore the desire to have the latest technology is viewed as a time hedge in terms of planned obsolesces.

Internally within an organization, using the latest technology is normally thought of as a good for involved personnel’s future career. It is also and opportunity to express one’s knowledge level relative to the new technologies. As with most decisions, when applicable staff looks at decisions in relationship to their personal circumstances, they will choose the path that offers the greatest personal reward. Associated risks are viewed as opportunities to enhance the personal experience of individual staff members. Implementation risks are considered normal in today’s technology based world.

Requirements for moving to newly developed technologies and methodologies are required by many RFPs. These requirements are often written based on the marketing hype that accompanies the new technologies. The requests are often made by subject matter expertise with little or no experience hands-on experience with the specific technology and related development.

Some development methodologies have added to more efficient and effective creation of systems. These have included 4th generation languages and database centric technologies that aid in displaying data in reports and on web pages more expediently.

Today’s business and technology environments remain one where technology is rapidly changing. Products that are developed and consumed by international clientele are the norm in this environment. With this type of environment, technology innovation is the norm.

The level of innovation that is required by an organization may be the next step in technology, or may be a quantum leap in technology over what is currently being used and understood by the organization.

LEADING EDGE vs. BLEEDING EDGE TECHNOLOGY There is a difference in the risk associated with new technology depending upon the maturity of the technology that is to be used. Leading-edge technology versus bleeding-edge technology each presents its own levels of risk to a project.

BLEEDING EDGE TECHNOLOGY Bleeding-edge development refers to putting together

technology in ways that previously have not been attempted. The technology that is being used may or may not actually be new on the market. The technology may be existing technology that is being used in the organization, or in other organizations. In the case of existing technology, the bleeding-edge component is the fashion in which the technology is being used. Or, bleeding-edge technology may refer to technology that has just been introduced and your organization is one of the first to try to utilize the technology.

The benefits if bleeding-edge technology works is that the innovation can give the organization a market advantage. Your system meets requirements that existing technology can not. The technology can make your organization’s products and services better, faster, and cheaper. There is also a perception in the market place that if a product uses the newest technology, it must be better. The technology is likely to have a longer useful life for the organization.

These advantages can come at a large cost. Working with bleeding-edge technology is frequently a frustrating experience. Many times, working with this level of technology will require working with the original developer of the technology if the person is available to you. If not, it turns out to be a series of trial and error exercises often with many “fixes” associated with the system. Finding the correct staff or funding arrangement that works well under bleeding-edge conditions is a complicated effort. Most all developers believe that this is a fun experience, and in the beginning it may be. But, in order to complete the project, many long frustrating days (and nights) of scientific approach to problem solving must be undertaken. It is not likely in a project of this type that schedules and budgets will be met. LEADING EDGE

Development within the current state-of-the-art is considered leading-edge development. Using products and methodologies that are new, but have already been successfully used in the same fashion that is proposed has its own associated benefits and related costs.

Leading-edge development will give the organization the ability to stay at the forefront of the industry. From a requirements standpoint this will allow the company to stay current with functionality within the technology environments. Staying current in this way also allows stakeholders to remain happy with the relationship they have with the organization. Employees understand that they will be working with state-of-the-art systems. Customers will perceive the organization as one that is current within the industry.

Costs associated with staying at the leading-edge are still significant. Training and literature to assist in the development is scarce. Many times classes are being taught by people without significant experience because none is available. The developers of the technology are normally not available to assist in solving problems. But, with that, other developers that have or are working in the technology freely exchange information. Many times the information is found

0-7803-9139-X/05/$20.00 ©2005 IEEE. 857

Page 3: [IEEE 2005 IEEE International Engineering Management Conference, 2005. - St. John's, Newfoundland & amp; Labrador, Canada (Sept. 11-13, 2005)] Proceedings. 2005 IEEE International

through searches on the Internet. Development with leading-edge technologies will lead to long days of frustration, but with availability of information exchange, the frustration is lessened from that of bleeding-edge development. Expectations of missed schedules and budgets are still a reality.

Some innovation is necessitated by the requirements of the system, some by oddities of the specific hardware and/or software environment, and other innovations are imposed due to a belief that the only good ways to handle a requirement is the way that we invented. Whatever the reason for the innovation, there are costs and benefits, and risks and rewards that are possible.

COST/BENEFIT

As is standard in any business decision the use of innovation must be validated by a cost/benefit examination. Even with this type of examination of proposed development processes it should be understood that all cost and benefits may not be able to be quantitatively assessed. Soft costs and benefits must be considered as closely as hard costs and benefits.

Soft costs and benefits include items such as the effect on stakeholders. Current employees leave if the organization does not keep up with technology, clients that expect to be able to review accounts using web access, government’s feelings about an organization’s access by disabled people are examples of soft costs and benefits. These benefits are real, although not quantifiable. They must be taken into account.

Taking soft costs and benefits into account are frequently not an easy task. There is a tendency to find a way to quantify the non-quantifiable. To do this, credibility of the argument is often lost. For an example of trying to quantify soft benefits we can look back to the business cases that were made in the 1990s for adding Internet EMAIL to the organization’s environment. A number of soft benefits could easily determined such as appearing state-of-the-art to stakeholders, being able to communicate in a more efficient and effective manner with clients and vendors, and ease of internal communications. To quantify these benefits, some people tried to determine the number of hours that can be saved; the number of additional clients will be added due to the EMAIL, and the reduction in hiring with the attendant costs of the hiring. Numbers of this type can easily be argued.

Given soft costs and benefits of technological innovation, it is important to note this level of issues without related quantification. Business cases for innovative technology should note soft costs and benefits and state that these are realistically not quantifiable. By doing this management can more easily understand all issues involved and make a consider decision.

Quantitative costs and benefits must also be considered. The less maturity of the particular technology, the more probability that the costs and benefits will not be able to be accurately assessed before the project begins. This is not to say that staff is purposefully providing inaccurate information.

It is more a function that staff can not adequately assess the unknown ahead in the project.

Benefits that may be quantified include longer life of the system, lower cost of future maintenance, and competitive advantage through use of the new technology. As a business case is presented the champion of the business case fully believes the case that is being made. After the project is funded and moves forward new information and understanding will be gained on the pieces and parts of the system. New understandings will be gained on the capabilities of the new technologies being used. These new understandings are likely to reduce the functionality of the new system. The outcome is likely to have a negative effect on the benefits that have been proposed.

New information that will be learned during the project is likely to also have a deleterious effect on the cost of the project. Moving through the project unexpected issues will become evident. Every possible question can not be asked before a project is begun. Small issues often quickly turn into large problems. Problems lead to higher costs and longer schedules for the development cycle.

Problems encountered often result in non-elegant workarounds. These workarounds compound the issues in terms of debugging and future maintenance. Workarounds will make debugging the issue more complicated. This is true during the initial implementation as well as for ongoing maintenance. New people that later get involved with the system are will not understand the logic of the workaround. By the time that alternate personnel work on the system upgrades to the original components have likely been applied. Additional research will be needed to work within the system. Workarounds will have to be applied to the original workarounds creating an even less maintainable system.

TECHNICAL PERSONNEL PERSPECTIVE

Technical personnel often view innovation as being positive for their career or just a fun exercise. Having the latest technical buzzword on a resume is attractive to many technical specialists. And, in reality many hiring managers put significant credence in these citations. Having written a system using a new technology may open doors for technical personnel in the future to organizations that require expertise in these fields.

Technical personnel may be categorized in several ways. These staff members may be classified as being employed in a job versus career, and as being a mathematician versus a coder. By understanding the technical staff member’s capabilities and motivations management will be able to have a better perspective of the reasoning for the technical decisions being offered by the staff member.

Career personnel are those that are in the position due to a true desire to be involved in the work. The desire may be based on a multitude of factors, with the basic fact that they really enjoy the work. Many technical staff that are classified as being in a career position enjoy the challenge of the puzzle. They enjoy solving puzzles and see the new technology as a new puzzle to be solved, another hill to climb. Career staff

0-7803-9139-X/05/$20.00 ©2005 IEEE. 858

Page 4: [IEEE 2005 IEEE International Engineering Management Conference, 2005. - St. John's, Newfoundland & amp; Labrador, Canada (Sept. 11-13, 2005)] Proceedings. 2005 IEEE International

will always want to work with the latest technology and afford the highest likelihood of success with new technologies.

This is as opposed to those that consider the position a job. These are people that may do a good job as a technical staff member, but look to the position as one that provides a significant salary, work that is acceptable, and an atmosphere that is conducive to their life priorities. This type of staff member is likely to encourage the use of innovative technologies in order to add the latest buzzwords to their resumes; but is not well suited to successful outcomes when new technologies are used on a specific project.

There are two basic types of software developers: 1. software developers 2. software coders

Some people inherently understand mathematical concepts. Mathematical concepts are second nature to these people. They can work through complex concepts, and normally do not understand why these concepts are hard for others to understand. These mathematical concepts are the basis for many of the new technologies and methodologies. Examples of this are relational data bases and object oriented development. To the mathematically adept among us they are able to design and work within these concepts easily.

A subset of technical personnel view their career as a logic game, attempting to logically work their way through a complicated technical labyrinth of other people’s architectures in order to meet their personal or organizational objectives, these people are software developers. By using new technologies, or existing technologies in ways that they have not been used before, a new portal of the labyrinth is opens before them. These are the basic material from which technology war stories are based. This is as opposed to the coders.

Coders are able to learn the syntax and the proper operations to enable the programming to be accomplished, but do not understand the patterns and mathematical concepts underlying these architectures. This means that a coder can work on the new technology, and ultimately make the technology work. But, in order to make it work the coder will use illogical patterns and concepts. This will make the ultimate system hard to complete and to maintain.

The mathematician will want to proceed into using innovative technology for the fun of experiencing a new pattern and mathematical idea. This idea is much like a pianist enjoying a new music pattern. The coder will want to use new technology to add to the tools that they have in their programming toolbox. This will be another architecture, language, or device that they are familiar with. They perceive this to make them more valuable to their current and future employers.

The recognition of the type of staff resource is important in the potential success of a new technology based endeavor. The use of software developers is critical to a successful outcome when implementing solutions based on new technology. Software coders can support the developer types, but their role is significantly different.

DECISION MAKING PROCESS

Decisions on technology should not be solely made by technical staff members. Input to the decision should definitely be received from the technical specialists, but they should not be of sole authority to make decisions of this type. A process is needed to address costs and benefits of a critical decision of this type. Costs and benefits should be considered along with both the goals of the organization, the current state of the industry and authoritative opinions of the future of the industry.

Technical staff opinions and estimates are taken by management at face value. These are taken without any questions asked and often these opinions and estimates are exponentially wrong. Postmortems do not normally go back the original reasons for the decisions that were made. Given that any estimates can be made without future repercussions, there is no reason for the technical staff member’s personal goals not to be factored into their decisions.

Processes should be used to document the reasons for the decision. All assumptions, facts, and estimates should be validated, documented and stored for future review against actual results of the systems project.

Organizations must balance the risk reward model of market place perception for their product against the schedule and budget risk of implanting a new technology based approach. Often the market place wants the latest greatest technology, but is not willing to pay for the cost of the implementation. Management must look at variable such as expected volume sales to determine return on risk in many instances.

Organizations also have internal reasons for attempting technology innovations. These include the “not invented here” syndrome, ideas of longer payback on the cost of development, and a strategic advantage by being the first on the block with the latest and greatest innovations. The complicating factor in the organization’s opinion is a realistic estimation of the requirements, cost, and schedule of using the latest and greatest technologies.

As technology progresses on its own lifecycle, in many ways it is becoming ever more complicated. Innovating in an environment is, or may at any time go past the point where most personnel can conceptualize the new technologies. From the earliest days of programming the cry from the experienced programmers was “KISS”, Keep It Simple, Stupid! That cry is often being lost in the current environment. Technical people trying to innovate make it complex, many times not realizing the complexity until it is too late to be changed.

Organizations frequently make the decision to move forward with new technology and agree to innovation because they are told that the additional cost in money, time, and quality will be minimal. Changes that require innovation are often thrown in without significant thought by both the technical and the organizational staff as “wouldn’t it be nice if…” The full implications do not become apparent until the project becomes extremely late and over budget.

0-7803-9139-X/05/$20.00 ©2005 IEEE. 859

Page 5: [IEEE 2005 IEEE International Engineering Management Conference, 2005. - St. John's, Newfoundland & amp; Labrador, Canada (Sept. 11-13, 2005)] Proceedings. 2005 IEEE International

REASONS TO MOVE FORWARD WITH INNOVATION

There are good reasons for organizations to choose to move forward with higher risk innovation. These must come out of a planned, considered approach to the direction that the organization is to move and management direction as to the path to forge. Reasons may include R&D funding available, market expectations, or positioning of the company versus others in the industry. But, this type of decision should be made considering the full situation and the likelihood that estimates will not be met. It is very likely that given this type of development schedules will slip and corresponding budget overruns will occur.

Funding for specific R&D is a good idea for any companies that want to move ahead of the competition on a technical innovation basis. These funds will give a specific tolerance for overruns, so that it may be better scheduled into the company’s plans. By doing this, senior management has the up-front ability to decide on the amount of resources that should be dedicated to innovation. This allows the decision to be made as a business decision.

In some industries innovation is expected. It is one of the barriers to entry to entering the industry. Companies within industries of this type must innovate. There is no choice. Management may take the position that innovation is required and specific projects will work with the new leading-edge or bleeding-edge technology, no matter the costs. The important factor to keep in mind with innovation and the associated risk is that it is not always a good path, and not always a bad path to take. Innovation is just another management decision that must be made in a considered fashion. In this way, the organization may continue to proceed in their planned direction.

0-7803-9139-X/05/$20.00 ©2005 IEEE. 860