1. 4th Module: Information Systems Development and Implementation:
Structure:
Management Control of IS Development
Management Characteristics of Projects
System Implementation
The Impact of the System Development Process

2. The process of developing information systems is covered in other courses (CIS207: Systems Development Methodologies and CIS314: Software Engineering Management).
This module will be more concerned with organisational issues of systems development and implementation.

3. Management Control of IS Development
In an IS development project, the organisation (i.e. the company, hospital, trust, etc.) needs the assurance that…
… everything is working as planned
…the project stays within a budget
…user needs as well as standards are fulfilled
…the quality of the work is good.

4. In order to gain this assurance, project management methodologies were invented for the teams within an IS development project.
These methodologies structure the organisation of the project, the reporting (communication) requirements between all parties that are involved, as well as the roles and responsibilities of the personnel.

5. Project Organisation Structure: The definition of the project organisation structure makes explicit who is involved in important project decisions.
Typically, the project stakeholders (Information Systems, Users and Management) are represented in all important project decisions.
Often, there is an additional quality assurance team that assists the project team and verifies that standards and procedures are kept. This team also ensures that quality of the work is of sufficient standard.

6. Project Reporting Requirements: In order to make sure that all decisions are explicit and approved by the relevant management level, communication must be clear between all parties who are involved.
In order to help making communication clear, methodologies define plans for the project.
These plans are concerned with budgets, quality assessment, evaluation reports, risk assessment, etc.

7. Project Roles and Responsibilities: To avoid conflict between team-members, roles and responsibilities are pre-defined.

8. Management Characteristics of Projects
Several researchers have doubted that there is a single right way of managing a project, e.g. Cash et al. (1992). They rather propose that the type of user involvement should depend on the particular project. It is dependent on a number of factors:
How good the final system can be defined at the start.
The degree of structure.
The level of experience the organisation has with the technologies it employs.

9. The following combinations are possible:
High Structure – Low Technology Projects:
This is typically the least risky type of a project because the technology is familiar and the outcome is well defined. As a result, senior management does not need to play an active part in controlling the project and user involvement can be minor.

10. High Structure – High Technology Projects:
Although the outcome is well defined, this is a challenging situation, as there are technical risks with regard to the project. In this scenario, user involvement is not so important, but a lot of attention should be drawn on internal integration of the project team to identify technical problems as early as possible. The senior management is involved as well, as it needs to be kept informed about possible problems.

11. Low Structure – Low Technology Projects:
Although the organisation has technical experience in this context, problems may arise from the user perspective, as users might change their minds with respect to the project. If users are not involved in a structured way, it might be hard to maintain their commitment for a certain design option. As a result, senior management support for the particular design is important. Moreover, it is important to ensure that user involvement is kept high throughout the project.

12. Low Structure – High Technology Projects:
These are the most risky projects and it is likely that conflicts arise between the preferences of the users and with respect to technical issues.
Consequently, active involvement of senior management is necessary to support decisions. Often, projects like this should only be done for very high returns. Otherwise, they involve too much risk.

13. System Implementation
Whether a system is successful or not can often be said after it has been implemented.
There are a number of success criteria Duncan (1997):
The extent to which the system is used.
User satisfaction.
The extent to which it meets the specification.
The contribution the system makes to the organisation.

14. There are many examples where the system is very good from a technical perspective, but users do not consider it user friendly enough (just compare the success of Microsoft Windows Operating Systems in contrast to UNIX when considering everyday users).
In many organisations, however, there is a big resistance to change of existing systems. This can be problematic, as IS have a large impact on people’s working life, job content, decision making etc.

15. The attitudes and actions of the management are critical to the success of a system implementation. It is particularly important how the staff are informed about the changes, i.e. is this done in a way that gives the individual employees the chance to understand why the changes are necessary?
The actions of the management must be consistent and in line with their goals as well as the goals of the organisation, and inform the users about the benefits that s/he gains by using the system.

16. Nevertheless, user resistance might be encountered
Nevertheless, user resistance might be encountered. There are 2 approaches that might help alter user behaviour.
Participative Change (lets the individual user acquire knowledge first, which might change the users’ attitudes and eventually their behaviour). If all individuals of a group undergo this change, they might support each other if they have questions/problems with the new system
Directive Change (is imposed by the management and tries to influence the users by setting goals, offering rewards, etc.)

17. In the long run, participative change is considered more successful, because it is more related to self-motivation, whilst rewards are an external form of motivation.
Participative change can be reached by openness, involvement of users and communication about the system.

18. Considering implementation of systems in general, implementation always starts with system conception and the management of changing the system should start as early as the project is approved to take place.

19. The Impact of the System Development Process
Traditional approaches saw system management from the perspective of directive change. The responsibilities of the developer were that of a change agent, with the task to analyse, design, implement and enforce the new system.
These traditional approaches were criticised by authors such as Hirschheim and Klein (1989), who suggest that traditional systems are a form of coercion.

20. Hirschheim and Klein (1989) say that traditional systems enforce management objectives on users.
Different authors have different opinions in terms of how system changes should be made.
It is now understood that the system development process itself influences the kind of system being developed. Most organisations want good systems, so they try to involve the user as much as possible and try to make the system changes attractive to them.

21. References:
Cash, J.I., McFarlan, F.W., McKenney, J.L. & Applegate, L.M. (1992). Corporate Information Systems Management: Text and Cases. 3rd Edition. Homewood, IL: Irwin.
Duncan, W.M. (1997). Information Systems Management. London: University of London Press.
Hirschheim, R. & Klein, H.K. (1989). Four Paradigms for Information Systems Development. Communications of the ACM, 32 (10),

22. References for students who are interested in further reading can be found on page 14 of the study guide.