The Features Of An Ideal Methodology

Published Date: 02 Nov 2017

Organisations are increasingly relying on their Information Systems (IS) to gain a better market foothold and thus secure that alluding competitive advantage. It is therefore a common occurrence for organisations to spend time and effort in getting their IS systems working in such a way so that it complements their business objectives (Avison et al., 2002).

There are therefore numerous IS implementation methodologies available within the market space which has been designed to assist management with the successful design and implementation of their IT\IS systems (Avison et al., 1997). This paper investigated and contrasted two such methodologies namely Structured Systems and Analysis Design Methodology (SSADM) and Dynamic Systems Design Methodology (DSDM). The former is an older, but well-known UK Government based methodology and the latter a newer management and control framework, aimed at Rapid Application Development (RAD) (Beynon-Davies, 1998). There are many other methodologies out there which fall outside the scope of this paper, but management is encouraged to consider them as well when looking for a best-fit solution.

Below follows a brief description of each methodology and then the paper moves on to discuss the findings of the research conducted.

SSADM

The activities in SSADM are structured in such a way that it forms a waterfall process, as each activity is performed one after another (Kaur et al., 2011). The emphasis is on thorough documentation of the requirements and design of the system (Ashworth et al., 1988). This improves the overall quality of the end product, but it is time consuming and gets complicated with very large projects as diagrams can have many nodes and relationships which can make it difficult to follow and understand (Ashworth et al., 1988). Since the design is done before the project starts (Aggelinos et al., 2011), it can be assumed that it will be well aligned with the business objectives and the end user’s requirements (Ashworth, 1988). It is assumed that the requirements will not change during the project, so it is unlikely that major changes in requirements and functionality will occur during development (Aggelinos et al., 2011). Management tends to be fond of this approach as it allows for easy training and technique dissemination within the organisation (O’Brien et al., 1993). This would suggest that it can be used on other projects and in combination with analysis design software to automate the document production (Ashworth et al., 1988). It is assumed that the requirements and designs will be passed to the project team in order to do the implementation of the actual system (Ashworth et al., 1988). Due to the large number of documentation that needs to be created, projects are often behind schedule, but money could be made up later-on due to the reusability of designs and techniques (Ashworth et al., 1988).

DSDM

DSDM’s aim is to produce an IS system rapidly by building a prototype which will gradually become a fully workable system (Barrit, 2002). Management will agree high-level requirements, but it is up to the development team to choose the method (Barrit, 2002). Only the deliverables that can be produced on time and on budget is performed, making this a rather successful approach (Barrit, 2002). End users become part of this development team so requirements can be amended and results tested as development unfolds (Avison et al., 2002). Upper management need not necessarily be consulted for requirement changes. The risk for these changes is managed by allowing for full rollbacks on mistakes or incompatibility issues (Barrit, 2002). Some drawbacks are that the system produced can be difficult to maintain due to the method chosen by the team and frequent requirements changes (Avison et al., 2002). Documentation is usually neglected due to the rapidness of the development (Barrit, 2002). This not only causes problems with maintenance, but also with technique reusability within the organisation. If the team dismantles, it could time consuming and difficult for someone else to understand what they did at a later stage (Avison et al., 2002).

Research

Although DSDM is a newer methodology to follow, this paper compared the key areas in an IS design and implementation project, in order to get a clearer view on whether the newer methodology outperforms the older SSADM methodology.

This paper compared the two methodologies on what the authors considered to be important management decision factors for such an IS implementation project:

IS Implementation life cycle phases: The authors investigated how well each methodology covered the design, build and implement phases of a typical IS project. Their findings indicated that both covered them equally with DSDM being slightly stronger in the build phase.

Manageability: The authors investigated how flexible each methodology was with handling changes, how it aligned with the requirements and business objectives as well as post-project maintenance. Their findings indicated that both methodologies responded to changes in a similar way.

Delivery: The authors investigated how well each methodology delivered on time and in budget. Different sectors and project sizes were included as part of the research. Their findings indicated that both methodologies delivered projects equally with DSDM being slightly stronger at on-time delivery.

These findings would suggest that both methodologies are very similar at a high glance. Subtle differences can be seen when delving deeper into the tertiary features (see Table and Table ) with one slightly outdoing the other. This would suggest that management should consider which areas are important to each IS implementation project and use the best-fit methodology.

Since DSDM is a control framework, it is possible to use it in conjunction with SSADM, giving the project the documentation it needs with the delivery rates of a RAD project (Stark, 2004).

The authors would recommend that management compare the two methodologies outlined within this paper to other methodologies on the market, before making a final decision on which one to use.

Features of an ideal methodology

In an ideal world there would be an ideal methodology that would cover all features needed for the perfect IS implementation. The authors used this ideal scenario to compare how well SSADM and DSDM would perform within such an ideal scenario.

The ideal features where decided upon the authors’ own views on what would make an IS project run smoothly. These features are outlined below in Table .

Table - Features of an ideal methodology

#

Feature

Description

1

IS Implementation Cycle

This includes the planning, build and support phases of a typical IS development life cycle. The ideal methodology should cover all phases.

2

Manageability

The ideal methodology should be flexibly with changes (requirement, technical and functional) and allow for easy measurement with business objectives, risks, project goals and user satisfaction. There should be enough external help available such as professional contractors, training and expert technical user groups. It should also be an asset to the organisation with easy knowledge dissemination (transfer) to complement the corporate memory.

3

Delivery

This outlines that the ideal methodology should allow for on-time and on-budget delivery. It should be able to cope in all sectors and for projects of all sizes.

Visual profile of an ideal methodology

Figure - Visual representation of an ideal methodology

Tabulation of all identified features for SSADM and DSDM

This section outlines the identified features of both methodologies investigated. Table and Table include the measurements as per test data gathered.

Table - SSADM Features

SSADM

#

Primary

Measure

#

Secondary

Measure

#

Tertiary

1

IS Implementation Cycle

3

1.1

Plan

3

1.1.1

Requirements Analysis & Feasibility Study

 

 

 

 

1.1.2

Systems Analysis

 

 

 

 

1.1.3

Physical and Logical Design

 

 

1.2

Build

2

1.2.1

Development \ Programming

 

 

 

 

1.2.2

Testing

 

 

1.3

Support

3

1.3.1

User Training

 

 

 

 

1.3.2

System Maintenance

2

Manageability

3

2.1

Flexibility

3

2.1.1

Requirements Change

 

 

 

 

2.1.2

Technical Change

 

 

 

 

2.1.3

Functional Change

 

 

2.2

Measurability

3

2.2.1

Business Objectives

 

 

 

 

2.2.2

Risks

 

 

 

 

2.2.3

Project Goals

 

 

 

 

2.2.4

User Satisfaction

2.2.5

Team Satisfaction

 

 

2.3

Maintainability

3

2.3.1

Knowledge Transfer

 

 

 

 

2.3.2

External Sources

3

Delivery

3

3.1

Time (on-time)

2

 

 

 

 

3.2

Cost (in-budget)

3

 

 

 

 

3.3

Sector Success Rate

3

3.3.1

IT Sector

 

 

 

 

3.3.2

Government

 

 

 

 

3.3.3

Energy and Transport

 

 

 

 

3.3.4

Banking and Finance

 

 

 

 

3.3.5

Retail

 

 

 

 

3.3.6

Other

 

 

3.4

Size of project

3

3.4.1

Small

 

 

 

 

 

3.4.2

Medium

 

 

 

 

 

3.4.3

Large

Table - DSDM Features

DSDM

#

Primary

Measure

#

Secondary

Measure

#

Tertiary

1

IS Implementation Cycle

3

1.1

Plan

3

1.1.1

Requirements Analysis & Feasibility Study

 

 

 

 

1.1.2

Systems Analysis

 

 

 

 

1.1.3

Physical and Logical Design

 

 

1.2

Build

3

1.2.1

Development \ Programming

 

 

 

 

1.2.2

Testing

 

 

1.3

Support

3

1.3.1

User Training

 

 

 

 

1.3.2

System Maintenance

2

Manageability

3

2.1

Flexibility

3

2.1.1

Requirements Change

 

 

 

 

2.1.2

Technical Change

2.1.3

Functional Change

 

 

 

 

2.1.4

User Involvement

 

 

2.2

Measurability

3

2.2.1

Business Objectives

 

 

 

 

2.2.2

Risks

 

 

 

 

2.2.3

Project Goals

 

 

 

 

2.2.4

User Satisfaction

 

 

2.3

Maintainability

3

2.3.1

Knowledge Transfer

 

 

 

 

2.3.2

External Sources

3

Delivery

3

3.1

Time (on-time)

3

 

 

 

 

3.2

Cost (in-budget)

3

 

 

 

 

3.3

Sector Success Rate

3

3.3.1

IT Sector

 

 

 

 

3.3.2

Government

 

 

 

 

3.3.3

Energy and Transport

 

 

 

 

3.3.4

Banking and Finance

 

 

 

 

3.3.5

Retail

 

 

 

 

3.3.6

Other

 

 

3.4

Size of project

3

3.4.1

Small

 

 

 

 

3.4.2

Medium

 

 

 

 

3.4.3

Large

Quantitative evaluation for SSADM and DSDM

Research has been conducted using Composite Feature Diagram (CFD) method.

The authors identified the primary features of an ideal IS Implementation methodology (gold standard) of what they thought would be needed to implement the perfect project.

According to the authors own opinion, the gold standard should:

Include all phases of the IS Implementation Life Cycle

Be highly manageable

Always delivery on target

Once the Golden primary features were identified, each of them was broken down into its respective secondary features:

IS Implementation Life Cycle

Plan

Build

Support

Manageability

Flexibility

Measurability

Maintainability

Delivery

Time (on-time)

Cost (in-budget)

Sector

Size (project)

The authors felt that the secondary features were still too broad and broke it further down into the tertiary features:

IS Implementation Life Cycle

Plan

Requirements Analysis & Feasibility Study

Systems Analysis

Physical and Logical Design

Build

Development \ Programming

Testing

Support

User Training

Systems Maintenance

Manageability

Flexibility (measures how flexible the methodology is to changes)

Requirements Change - User wants more features

Technical Change - Changing of databases and software

Functional Change - User wants it to work in a different way

User Involvement - How well were they involved

Measurability (measures how good the methodology aligns with key business and project features)

Business Objectives - how well were the business objectives met and considered

Risks - How well are risks being considered and managed

Project Goals – How clear the project goals that are being monitored

User Satisfaction - How satisfied are users with the end product

Team Satisfaction - How happy are teams with using each method

Maintainability (measures how good the methodology is maintained during and after the project)

Knowledge Transfer - How well are knowledge kept in the organisation and transferred between team members

External Sources - how much help is available to use each technique i.e. external consultants, books and training

Delivery

Time (on-time)

Cost (in-budget)

Sector (measures the methodology’s effectiveness in different sectors)

IT Sector

Government

Energy and Transport

Banking and Finance

Retail

Other

Size (project) (measures the methodology’s effectiveness with different project sizes)

Small

Medium

Large

After all the features were identified the authors gathered test data from industry experts by means of questionnaires. The industry expert were asked to rate each feature of SSADM and DSDM respectively on a scale from 0 to 5. The weight of the scale is as follow:

0 = absent

1 = poor

2 = satisfactory but marginal

3 = good

4 = very good

5 = excellent

The questionnaires were gathered and the weight of each section was determined by calculating the average of the 24 correctly completed questionnaires and then rounding the answer to the nearest whole number.

The tertiary features yielded the following averages:

The secondary features yielded the following averages:

Key:

0 = absent

1 = poor

2 = satisfactory but marginal

3 = good

4 = very good

5 = excellent

This resulted in the following primary feature averages which were compared to the "Gold" Standard.

Key:

0 = absent

1 = poor

2 = satisfactory but marginal

3 = good

4 = very good

5 = excellent

Calculations:

Feature

Gold Standard (Threshold)

SSADM

DSDM

MAX

IS Implementation Cycle

5

3

3

5

Manageability

5

3

3

5

Delivery

5

3

3

5

Total Area:

32.5

11.7

11.7

32.5

The research above would suggest that the industry experts regarded both methodologies to be very similar.

Conclusion

The authors were unsatisfied with the research findings as it was considerably different to the research they conducted (Edwards et al., 1989, ADD all other papers here).

According to their findings SSADM should’ve excelled in the following areas:

Planning phase of the IS cycle

Measurability: Project Goals

Maintainability: Knowledge Transfer

Delivery: Sector Success Rate: Government

Delivery: Size of Project: Medium

SSADM should have underperformed in the following areas:

Building and Implementation phases of the IS cycle

Flexibility

Delivery: On-time

Delivery: On-budget

The difference in finding could have been related to the difference between the research papers used by the authors and the personal experience of the expert group who completed the questionnaire.

Research papers were mostly UK based and the majority was quite out of date.

The expert group whom completed the questionnaire was mostly between the ages of 20 - 35 years and might have favored the more recent DSDM methodology. The majority was of a non-European origin and their foreign programming and project experience could have contrasted the findings of the UK research papers.

It is also possible that the author’s golden set of features were too general and could have been misinterpreted within the questionnaire.

It is also possible that the CFD failed to be more diverse because the authors decided to round the measurements to the nearest whole number, which resulted in similar values.

The authors felt that the CFD was a good way to determine which features are important when selecting a product or methodology. It allows for easy comparison between two products. On the other hand, having more than two products could’ve cluttered the CFD diagram making it difficult to interpret. Constructing the CFD took considerable time and the authors felt that if an auto-generation tool were available, it could’ve gone faster. Because of this, the project team would look for an alternative method.

Peer Evaluation of work carried out throughout the process

(How about Coffee??)

Wireframe of Poster

[INSERT HERE]