Exploration of links between Initial Statement of Objectives and Development Pressures entities

The hypothesis being explored in this section is that there is a link between the two distinct parts of the problem entity - the initial statement of objectives and the development pressures entities. The initial hypothesis is based on our initial conceptual frameworks, which claimed that the main link between the two entities was in the amount of change a project had to deal with. The argument here being that the amount of emergent or consequential change was dependent on both the starting position of the project (emergent requirements in particular being felt to be more likely when the project starts without an explicit terms of reference) and the skills and experiences of developers in anticipating and coping with the demands of change.

The first test carried out was to identify any possible links between the initial statement of objectives and the impact of requirements change on a project. Figure 7.5 shows the results. The two thick lines on the diagram shows two sets of expected results if there was a strong relationship between one of the change types and the initial statement of objectives classification. The first line argues that the impact of requirements change increases the more rigorous the initial set of requirements. The second argues that the impact of requirements change drops as the requirements become more rigid, because the

rate of change on projects without solid initial requirements is likely to be that much more intense. Neither of the two requirements change types shows this relationship. The impact of consequential requirements in particular, are almost entirely flat across all four categorisations. Emergent requirements, by contrast, show an inverted bell-shape curve. This result is interesting in itself if it highlights the possibility of existence of both sets of expectations, i.e. that intense change for projects with few initial requirements impacts greatly on a project, whilst at the other end of the scale, the high cost of reviewing and incorporating emergent changes when a rigid set of requirements is already in place also increases the impact of emergent requirements changes.

Job

Roles Procedure Process

Number of projects

Analysis Development Paradigm

Explicit Formal Stable 3 (4.3%) 2 3C

Explicit Formal Unstable 1 (1.4%) 2 1C

Implicit Formal Stable 1 (1.4%) 3 IG

Implicit Formal Unstable 5 (7.1%) 2 3I-2C

Job

Roles Procedure Process

Number of projects

Analysis Development Paradigm

Explicit Informal Stable 4 (5.7%) 2.5 2C-2I

Explicit Informal Unstable 5 (7.1%) 2 3I-1C-1G

Implicit Informal Stable 7 (10%) 2.5 3G-2I-1C

Implicit Informal Unstable 44 (63%) 2.4 9G-25M5C

Table 7.8 Organisational Context - Relationships with Starting Point and Development Paradigm

The second set of results; comparing the impact of developer experience on the impact of requirements change, produces more interesting results. Figure 7.6 illustrates these results.

Emergent Change

Impact

ypothesis A: The more rigid the requirements, the greater the impact of change Perceived Need Desired Change Desired Solution Consequential Change

Hypothesis B: Having mature set of requirements reduces the impact of requirements change

Chosen Solution

Figure 7.5: The Impact of Change: Dependencies on Initial Statement of Objectives

The results show a gradual reduction in the impact of both sets of requirements change as developer experience increases". I would conclude that this firmly shows that the impact of requirements change (in terms of consequential and emergent requirements) is managed by developer expertise. The links between the two entities (development pressures and initial statement of objectives), however, are not so clearly defined in the two diagrams in this section, which raises questions whether the requirements change link should be between the development pressures entity and the strategy entity or should be a component of the development pressures entity itself - an issue explored in section 7.7.9.

" D1 to D3 referring to increasing levels of developer experience.

high Emergent Change 4.4 4.3 3.6 3.2 3.3 Impact Consequential Change 2.7 low D1 D2 D3

Figure 7.6: The Impact of Change: Depending on Developer Experience

One (unexpected) link between the two may be highlighted in figure 7.7. Chosen Solution Desired Solution _2.7 UR2 2.5 2.0 2.3 Desired Change URl Perceived Need D1 D2 D3

Figure 7.7 The Relationship between Experience and Initial Statement of Objectives

When a direct comparison was made between the initial statement of objectives and development pressures entities, an interesting pattern emerged. The first is the consistent gap between the line labelled URl, which signifies the users having little experience of a system of this type, and the line labelled UR2, which signifies the fact that users have experience with a system of this type. What the diagram suggests is that the more

experienced the user, the more likely that more robust requirements are developed during the initiation of the project. The more ‘novel’ the system is, and the less exposure the users have to a system of this type, then the more likely that the project will start with a looser set of initial requirements. This finding supports the arguments of Harker (1991), who identified the need to evolve requirements within novel, interactive projects. The second result, the general increase in formality of analysis starting points based on the experience of developers, presents another interesting question. Are development staff chosen for their experience in a particular domain? In other words, does a level of domain expertise equate with placement on a project and does a level of collective domain knowledge result in developers producing more rigorous sets of requirements? The link between the system characteristic and domain experience elements are used to explain this characteristic in chapter 8.