The development of information systems (IS) has for many years been regarded as the domain of the technical expert. In what appears to be a growing number of instances systems appear to be having negative effects on the organization. A regular spate of system failures may have identified serious flaws in the system development process. Organizations may often be significantly affected by the implementation of IS. Future IS development may increasingly be trans-organizational and therefore increase the potential for dysfunctionality. Even changing one line of code may have repercussions within a department/organization. To implement a totally integrated system within an organization without adequate preparation could have serious consequences for the financial well-being of the company. The development of information systems is a complex process, one with many opportunities for things to go wrong. To try and control this complex process a methodology was required that would bring more discipline to the IS development process. There is a need to make more efficient use of the resources that are available. Historically, IS has been developed using the system.development.life.cycle. (SDLC). This has been the prevailing methodology for medium and large system projects. However, the use of accepted methodologies for IS development have not guaranteed the successful implementation of information systems.
Implementing Lean software development can lead to productivity gains of between 20% and 40% and that quality and speed of execution can improve markedly within a matter of months. Both valuable benefits when the cost of developing and maintaining applications now account for about 50% of the average I.T. budget – a figure that is set to rise in the future (McKinsey report dubbed “Applying Lean to Application Development and Maintenance 2007).
Until recently, many firms had bought business intelligence systems at a departmental level, resulting in myriad different tools being used across the business. Firms are now looking across the business to ensure a consistent, standardized approach to analyzing and measuring data which should also boost operational efficiency (Computer Weekly 2007).
TopIntroduction
The development of information systems (IS) has for many years been regarded as the domain of the technical expert. In what appears to be a growing number of instances systems appear to be having negative effects on the organization. A regular spate of system failures may have identified serious flaws in the system development process. Organizations may often be significantly affected by the implementation of IS. Future IS development may increasingly be trans-organizational and therefore increase the potential for dysfunctionality. Even changing one line of code may have repercussions within a department/organization. To implement a totally integrated system within an organization without adequate preparation could have serious consequences for the financial well-being of the company.
The development of information systems is a complex process, one with many opportunities for things to go wrong. To try and control this complex process a methodology was required that would bring more discipline to the IS development process. There is a need to make more efficient use of the resources that are available. Historically, IS has been developed using the system development life cycle (SDLC). This has been the prevailing methodology for medium and large system projects. However, the use of accepted methodologies for IS development have not guaranteed the successful implementation of information systems.
The information systems (IS) discipline has borrowed a number of techniques from other disciplines. However, many of these have been taken from areas where the outcome from projects is more certain. Virtually all projects are liable to have changing requirements. In IS there are many variables that need to be considered before, during, and after a project has been completed. It is one thing to identify what those variables are and another to react to the changing circumstances.
The question IS must address is whether it is inevitable that projects of a certain size and length will fail to deliver expected benefits. In essence IS is trying to hit a moving target. The ‘contract’ (user requirements) for a new information system is agreed at a comparatively early stage. All parties agree on requirements and the project development team retreats to build the system. This can be a lengthy process.
For a change in the system development process to take place participants must agree that the current methodologies are not working. This in itself is problematical. System developers are generally happier with a fixed set of requirements. What incentives are there for the various stakeholders to change the way system projects are currently handled?
The methodologies that support this process tend to provide more emphasis on control at the expense of planning. They would be more appropriate in static business environments. Even in this situation there will be project failures. The initial premise for an IS project should be that there will be change. The methodologies should then provide enough flexibility to allow for the forthcoming changes. Ideally a vision of the implemented system should be formulated at an early stage.
In many instances the full implications of change are not appreciated. If an information system is implemented in one area of the organization there are often knock-on effects elsewhere. Inevitably data and information often cut across departmental and functional boundaries. However, from the system developer’s perspective it is simpler to draw a tight boundary around the system. This may manifest itself through a narrow focus being taken i.e. only a small number of potential Users may be interviewed about the previous system and the possible effects of the new system.