Design process 30

To develop the measurement instrument, we take the following steps. Step 1 – Analyzing PeopleSoft object types

31

Step 3 – Constructing customization complexity levels Sections 4.2.3.1 through 4.2.3.3 discuss each step in more detail.

4.2.3.1

Step 1: Analyzing PeopleSoft object types

The existing Accenture Methodology is taken as a basis for determining which object types can be modified, how these object types can be modified and what the average development times for the modifications are. The Accenture Methodology uses statistical data from past PeopleSoft implementations to arrive at average development times for modifying PeopleSoft objects. For each of the object types displayed in Figure 13, the methodology provides (1) the complexity level of the modifications expressed in terms of simple, medium, complex and very complex, (2) criteria used to determine these levels and (3) the average development time for each level based on past projects. To provide an example, Table 9 presents the above information for modifying the object type Batch COBOL Process.

Table 9: Modifying PeopleSoft object type

Object Complexity level Criteria Average development time Batch COBOL Process

Simple Standalone, 1 input & 1 output, read-process-write flow, no internal arrays, simple business logic

70

Medium Meets 2-3 of: called/calling module, multiple inputs/outputs, multiple logic paths, multiple internal arrays, array insert/delete logic, non-standard error

processing, moderate business logic, interaction with trees, interaction with process scheduler.

154

Complex Meets more than 3 of the criteria for medium.

268

4.2.3.2

Step 2: Categorizing object types into customization types

Then the second step was to categorize the object types into customization types. There are two reasons for this classification step. First we need to keep the instrument as simple as possible,

32

meaning that from the large number of object types, those which are similar or provide similar functionality should be grouped to keep the number of groups as low as possible and second, by classifying the object types into higher level customization types also we can extract from the PeopleSoft terminology.

The identified object types from the previous step are classified into the six customization types Reports, Interfaces, Conversions, Extensions, Forms and Workflow. In this classification step it was found out that modifications to the PeopleSoft objects can either be classified as Reports, Interfaces or Extensions:

Reports: Crystal Report, Essbase Model, Essbase Report (Excel Architecture), nVision Report,

PS/Query and SQR.

Interfaces: Application Engine File Interface, Batch COBOL Process, Batch SQR Process,

Component Interface, Transformations

Extensions: Application Engine Process, Page, Portal Pagelet, Record/Search Record/View,

PeopleCode, Menu, Tree, Business Process Maps, Component Interface, Business Interlink, Application Messaging, Navigation Bar, Content Reference

The three other customization types Conversions, Forms and Workflow are more general terms for which no specific PeopleSoft object is modified. The dataset contained data on average development times for Workflows and Conversions but not for Forms since Forms are very specific for each case and thus it is not possible to construct complexity levels for it based on statistical data. Because of this reason it was decided to leave Forms out of the framework.

4.2.3.3

Step 3: Constructing customization complexity levels

Once all the object types were categorized into customization types, for each customization type complexity levels were developed based on the data on average development times for modifying the object types. This is similar as the complexity levels of the object types and comprises the following: within each customization type, first the complexity of object type modifications are assessed to see which classes (from step 1) can be grouped and second, these joined classes, consisting of different object types, together form complexity levels for the customization types. For each complexity level it is defined (1) what the average development time is for modifying objects of that customization type and (2) what the range (in development time) is for that level. The average development time is then taken as the complexity index for that level. This is illustrated in the example below.

Example: developing the customization complexity indexes

Consider Table 10, where four object types which are classified as Reports, along with their associated average develop time1 for the four complexity classes are presented. It should be

33

noted that some objects (like object 1 and 2 in the example of Table 10) only have three complexity levels whereas others have four.

Table 10: Example Report objects

Reporting Objects Simple Medium Complex Very complex

SQR 15 25 65

PS/Query 5 15 30

Crystal Report 50 70 120 200

nVision Report 110 150 230 340

Figure 14 is a graphical representation of the table above. Based on the data, four complexity classes are constructed for the customization type Reports. Each class covers a range of development times as illustrated in Figure 14. The classes are constructed in such way that the standard deviation of the observed values is the lowest within each class.

Figure 14: Example Report objects

Table 11 presents the overall complexity levels for Reports. Each level represents a certain range in development time for customizing Reports and specifies which level of modifications to which objects belongs to the overall Report customization levels. The complexity index is the

34

statistical average of the development times of the data and the error term is the standard deviation in development time.

Table 11: Example overall complexity levels for Reports

Modifications to reporting objects Development time range Complexity index Error term Simple 1. All modifications to object

PS/Query

2. Simple and medium

modifications to object SQR

0 – 40 hours 18 8,7

Medium 1. Simple and medium modifications to object Crystal Report

2. Complex modifications to object SQR

40 – 90 hours 62 8

Complex 1. Simple and medium modifications to object nVision Report

2. Complex modifications to object Crystal Report

90 – 175 hours 127 17

Very Complex

1. Complex and very complex modifications to object nVision Report

2. Very complex modifications to object Crystal Report

> 175 hours 257 60

The steps of the above illustrated example are also carried out for the customization types Interfaces, Conversions, Extensions and Workflow. This has resulted into the matrix of Figure 15, which provides an overview of the customization types along with their complexity levels. The matrix shows for each level, next to the complexity index (i), also what the range in development time (dt) and the standard error (e) is. Next to the matrix of Figure 15, in Appendix A – Customization objects in PeopleSoft for each customization type detailed description is provided of their overall complexity levels and the objects which belong to each level.

35 Customization types

Complexity

Simple Medium Complex Very complex Reports 0 < dt ≤ 56 i = 31 e = 13 56 < dt ≤ 84 i = 66 e = 3 84 < dt ≤ 157 i = 121 e = 16 157 < dt i = 292 e = 108 Interfaces 0 < dt ≤ 44 i = 33 e = 4 44 < dt ≤ 116 i = 66 e = 10 166 < dt i = 213 e = 47 Extensions 0 < dt ≤ 44 i = 21 e = 12 44 < dt ≤ 103 i = 65 e = 13 103 < dt ≤ 227 i = 179 e = 37 227 < dt i = 281 e = 44 Conversions 0 < dt ≤ 90 i = 56 90 < dt ≤ 212 i = 124 212 < dt i = 300 Workflows 0 < dt ≤ 57 i = 49 57 < dt ≤ 71 i = 64 71 < dt i = 77

Figure 15: Customization complexity matrix