From formalised method to method-in-action: The rational and political role of methods

Kulveer Singh U4557928

Discussion Papers The fiction of methodological development: a field

study of information system development (R11) Coordination in Software Development (R17) Formalized system development methodologies: a

critical perspective (R46) System dynamics in software project management:

towards the development of a formal integrated framework (R75)

The utilization of information system development methodology in practice (R112)

The fiction of methodological development: a field study of

information system development (R11)

Joe Nandhakumar

David E. Avison

The fiction of methodological development: a field study of information system development

Objectives Explores the process of information system development

in large organization Paper argues that

• Traditional IS development methodologies are considered primarily as a necessary fiction to present an image of control or to provide a symbolic status

• Methodologies are too mechanistic to use in detail in day-to-day organizational system development activities

Paper also illustrate use of an “ecological” research approach to IS development

IS development process Avision and Fitzgerald,1995

• Argued that most of the literature work described showed concerned describing about the particular methodologies

• How project is to be broken into discrete stages

• How task is to be carried out in each stage

• How tools are to be used in each stage to achieve the specifies deliverables

• They argued the development of new methodologies are focussed to be technological driven

• Some focus was also given on expanding the scope of existing methodologies to address further stages and life cycle such as strategy & planning phase in Information Engineering

• Some methodologies are also developed by combining the two methodologies in order to overcome the drawback of each other

• Eg: Multiview

Continued…

Hirschheim and Klein (1989)

• Identified that there are four “ideal” type of IS development practices

• Functionalist

• Social Relativist

• Radical Structuralist

• Radical humanist

• Also identified four main roles of IS developer

• System Expert

• Facilitator

• Labour Partisan

• Emancipator/social therapist

Research Study

Development process of executive information system (EIS) in large multinational manufacturing company (LMC)

Research findings

Research results mainly highlighted • Nature of IS development process

• Use of IS development methodologies

Implication for IS development methodologies

Traditional methodologies are too mechanistic to be used in detail

Methodologies were seen primarily as a fiction to present an image of management control or reflects symbolic status

Social control factors has significant influence on developer’s work practices

Conclusion

Formal methodologies are too mechanistic to be much of use in detailed during the day to day organizational developer’s activities.

The traditional IS development methodologies act as a necessary fiction to provide an image of control or symbolic status to IS projects.

Approach of using participants observation provided an effective mean of understanding the complex social process of IS development

Coordination in Software Development

 (1995) (R17)

Robert E. Kraut

Lynn A. Streeter

Software Development (SD)

“The process of analysing needs, designing solutions, writing programs, testing them, and implementing them to solve the problems of individuals and organizations.”

Software Crisis and Coordination Problem

“[Software] is unreliable, delivered late, unresponsive to change, inefficient, and expensive and has been for the past 20 years”

Even today, problems with software systems are common and highly-publicized occurrences.

Coordination has been defined as the direction of “individuals” efforts toward achieving common and explicitly recognized goals” and “the integration or linking together of different parts of an organization to accomplish a collective set of tasks”

Why Coordination Problem?• Large Software Systems• Software Complexity• Ineffective Communication• Less Informal Communication and Interaction

Software Crisis and Coordination Problem

What is Needed- Coordination

Common Definition/ Common View• 5 W’s (Why, When, What…) and 1H (How)

Share Information Mesh Activities

Characteristics of Software Development

Scale• Small Software development projects

• Large Software development projects• large projects are more successful if a single, often

exceptional, individual with both application domain knowledge and software knowledge guides and coordinates the project.

• Impossible: Size measurement is in millions or yeas

Characteristics of Software Development

Characteristics of Software Development

Uncertainty• Means the unpredictability of both software and the

task that software engineer performs.

• Most software systems have no existing prototype, applications or systems.

• Specifications of the software functionality change over time. (User demands and Physical Changes)

• Specification are incomplete.

• Different beliefs- 5 W and 1 H

Characteristics of Software Development

Interdependence• Large size project have thousands of modules

which requires perfect mesh.

Informal communication• The combination of large size, uncertainty

and interdependence requires special coordination technique.

• Formal and Informal communication.

A survey Study of Coordination In Software Development

Surveyed- Intergroup coordination practice across 65 projects in one large software development company.

Focused Factors• Coordination Practice Used

• Structural characteristics of projects that might interact with the practicality and utility of various coordination techniques.

• Success of projects on several dimensions.

A survey Study of Coordination In Software Development

Research site• Software development division of a research

and development company• 5000 managers

• Analyst, Software engineers, Programmers, Testers, documentation specialist.

• In general- Waterfall model and standard development environment, code reviews and quality programs

Discussion

Formal and Informal Interpersonal Communication• Helps in sharing of information

• Achieving coordination

• Cope uncertainty

• Minimise managerial and technical problems

• Promote help etc

Implications

Can draw- Practical and theoretical implications• Personal communication is important for

coordination but expensive.

• Need of technological assistance

• Deleterious effects Leads to

• Work overload

• More time spent with neighbours

Formalized system development methodologies: a critical perspective (R46)

Brian Fitzgerald

Formalized system development methodologies: a critical perspective

Objective • Paper discusses arguments and pressures which

support use of methodologies

• Paper also identifies number of arguments and pressures which question the value of methodology in practice

• Critical perspective shows that increased adoption of methodologies to address the problem in system development is by no mean proven

Argument and Pressures in favour of formalized methodologies

Argument and Pressures in favour of formalized methodologies

Critical consideration of formalized methodologies

System dynamics in software project management: towards the development of a formal integrated framework (R75)

AG Rodrigues

TM Williams

System Dynamics in software project management: towards the development of a formal integrated framework

Objectives • Traditional software project management

approach vs. System Dynamic (SD)

• Paper discusses about the conceptual integrated model SYDPIM to incorporate the system dynamics in software project management

Traditional Software Project Management

Software management comprises the several functions responsible to keep the project within time, cost and quality.

Paper mainly focus on three functions of project control:

• Estimating

• Planning

• Monitoring Progress Approaches followed

• Network models developed on the basis of WBS

• Process Definition Diagram (PDD)

• Rapid Application Development (RAD)

Problem & Limitation of Tradition Approach

Main cause highlighted for the drawback of traditional technique is strategic area such as

• Political/social environment

• Legal agreements

• Human factors (Soft factors) These traditional network based models failed to cope

with the higher level of complex problems Need of new approach arises and System Dynamics (SD)

came into existence.

• Based on the holistic view of managerial problems and focused on the human aspect of the system’s behavior

Conceptual integrated framework Network model

• Top-down process

• Management problems at operational level

• Focus on detailed logic of project work structure and resource requirement

SD model

• Bottom-Up approach

• Managerial problems at strategic level

• Focused more on capturing general aspects of the project behavior

Therefore, integrated framework is to be developed considering the benefits of both model.

System Dynamics Project Management Integrated Model (SYDPIM)

System Dynamics Project Management Integrated Model (SYDPIM)

SYDPIM considered both levels strategic and operational management to support

• Planning

• Focus was given on estimating future results and performing risk analysis

• Monitoring

• Focus on diagnosing the past behavior of the project Strategic level – high level SD strategic model (SDSM) is

consider which covers the whole project life cycle and captures major software development milestone

Operational level – complex model SDOM is considered which covers individual life cycle of each phase in detail

Definition of SD model structure

SD Model is based on four basic principles:

• Dual life cycle of management and engineering

• Breakdown of projects into major sub-tasks

• Dual life cycle of work and defect within the engineering process

• Single high level project management and human resource management function

Critical issues for application of SYDPIM

Availability of accurate data which is required for• Defining two project model behavior

• Calibrating the SD model

Range of application for SYDPIM• Size and complexity of the project

• Type of software development process

Conclusion Traditional software project management and analysis tools

has proven to be inadequate due to failure in capturing both human factor and project interaction and feedback effects.

SD emerged as the possible solution offering both aspects in analysis

It is needed to embed into the framework of traditional project management

Conceptual integrated framework SYDPIM is introduced which uses SD models at both strategic and operational management level.

Author considered that integrated tools provides a powerful support for managing major software engineering projects.

The Utilization of Information System Development

Methodologies in Practice (R112)

Karlheinz Kautz

Bo Hansen

Dan Jacobsen

The Utilization of Information System Development Methodologies in Practice

Objectives of the paper• Study people and their actions within an

organizational context i.e. how developers use ISD methodologies in practices.

• Case Study – Danish Software Development Company

Practical use of ISD There is disparity between the way methods are formally described in

literature and the way they are used in practice

• As a symbol to support the fiction of system development as a controllable process

• Adoption of techniques of the method but, without adoption of the philosophy on which the method is built

• Unclear mission

• Lack of management support

• Organizational culture – hostile

• Doubts about methodology – usability & validity

• Insufficient training and insecurity

• No systematic monitoring

• No participation of the methodology users in the decision making

Practical use of ISD

Productivity of developer and quality of developed system was also effected due to

• Limited domain knowledge

• Fluctuating requirements

• Communication breakdowns System development process and methods do not

support any learning about domain, understanding the fluctuating behaviour and impact of environment and organizational context

Danish Software Company 2300 employees of which 620 are system

developers Founded in 1972 by National Association of Local

Authorities in Denmark Deliver software solutions mainly to public sector and

limited to private sectors System development is primarily directed towards

product development and adjustment Two groups of projects

• New development project

• Maintenance projects

Danish Software Company New development projects

• Building of new system but, in actual it is renewal and re-implementation of projects

• Divided into smaller chunks to renew gradually part by part Method Support Department

• Helps in guiding the projects in their development

• Arranges training courses

• Buying help

• Provide system architect

• Helps in securing the system complies with the technical standards of the company

• Provide suggestion in framing product architecture

• Also collect feedback for system architecture

Investigated Projects Project A : Re-implementation of Administrative System

• System is in use for 20 years therefore constitute a large part of public sector users of Denmark

• As project is redeveloped all the functionality is know except some serious changes in legislation

Project was divided into 3 layers

• Back-end system

• Process layer

• Dialogue components Development work is to be carried out using the following tools:

• CASE tools

• Web-development tools

• Mainframe programming tool – (for developers)

Continued… Project B: Replacement project that renew and enhance large administrative

project

• It was used by staff and personnel management by private and public sector

• Replacement will take place in form of pilot operation where new and old system will run parallel

• Project uses so-called architecture paradigm for specification of the system

• According to the paradigm system is described in five perspectives:

• Product perspective

• Architecture perspective

• Development perspective

• Operation perspective

• Delivery perspective

Continued…

• While defining the technical platform it was decided not to use CASE tool and accompanying method for component based development

• Large parts of the functionality are programmed with the help of rule-based development tools

• For communicating the development UML diagrams were used Project C: Redevelop a specific part of another administrative

system used by public sector

• Based on classical client-server architecture

• Applied CASE tools and accompanied method

• Prototyping function to facilitate communication with the customers

Finding of the study Practical use of system development methodologies are

influenced by five factors and processes

• Universality

• Idea of using one methodology applicable universally to all is not shared among the respondent

• Reasons were

• Problem with sequential development method due to large size and complexity of the project

• Different tools an platform demand different methodologies

• Inappropriate development tools were chosen for the application methods and techniques

Continued… Confidence

• Developers needed feedback to see whether they are on right track of development

• Developers wanted to have more comments from user-side rather then assuming the user requirement themselves.

• It also showed the symbolic use of methodologies in order to fetch the management’s goodwill

Experience

• Developers experience in regards to system development process and domain knowledge is also the influencing factor for utilizing method

Continued…

• A pragmatic use of methodology is seen during the development by experienced developers

• They characterized methodology as a set of toolbox where appropriate techniques and methods can be found instead of characterizing as a general adoption of underlying philosophy

• This type of behavior can lead to the implication on adopting new methodologies

Co-determination

• Use of methodology is also related to the developer’s desire for involvement and management co-operation with respect to policy and decision making

Continued… Introduction

• Methodology introduction always plays a major role in its adoption.

• Certain level of training and education is required to get comfortable with the methodology

Lesson learnt

• Methodology are adjusted in action; no universally applicable methodology exists

• Varying complexity of information system

• Varying experience of developers

• Symbolic utilization of methodologies

• It act as a mean to provide comfort and confidence

Continued… Methodology utilization moved towards incremental methodologies

• Due to the rapid change in application domain and business environment, traditional life cycle approaches are not appropriate to use

• Large and complex size of system tends developer to divide the project in smaller parts

• This also provides a sense of control and comfort as there is continuous deliverances of prototyping

Methodology adoption depends on management support, explications and co-operation

• Lack of clear mission statement and resources can lead to poor introduction of methodology

Conclusion

The extensive empirical study helped in identifying five inter-related theme of factors and processes affecting the use of methodologies

Result of this study defines the framework for the future research to get deeper understanding of information system development and the utilization of methodologies.

Thank You