Figure 12 – Extended PERA (Source: Katz 2005) 1.3.5 Enterprise Engineering fundamentals conclusion
2. Maturity Model Lifecycle Impact Mapping
This chapter describes, summarises and derives conclusions from the maturity model lifecycle impact mappings, as initially described in the research proposal (Section 1.4.2).
The objective of the mappings was to improve the understanding of the maturity models in terms of their ability to impact and support the enterprise throughout its lifecycle. Impact is thus described in terms of enterprise-relevant lifecycles (Enterprise, Technology and Product Lifecycle), their constituent phases, and their interrelatedness. An improved understanding of the interaction between the various lifecycles according to the maturity models could also be established. Furthermore, the mappings could be used to identify the maturity model process areas, and/or combinations thereof, that support the innovation lifecycle.
Any entity that experiences a change in state, exhibits a lifecycle that is comparable with others and independent of both content and detail (Williams et al. 1998; Van der Ven and Poole 1995). It is this generic nature of the lifecycle that prompted the use thereof in determining the applicability of the maturity model approach to generically describe organisational maturity.
The aim was to use these impact mappings as an evaluation of whether the maturity model approach is able to achieve the primary objective of this research. The approach will thus be scrutinised for its ability to depict a model that can consistently support the innovation activities of an organisation throughout the Enterprise, Product and Technology lifecycles. This outcome is discussed Section 4.3.
The basics of maturity models (purpose, structure, level descriptions, benefits, etc.) were discussed in Section 1.2. In order to re-establish context, the two primary and generic purposes of maturity models will be reiterated. The first is to establish the capability maturity of an enterprise in terms of a specific domain of practice. The second is based on the results of the first; to facilitate in establishing a direction and course for improvement that will best suit the enterprise and that is in accordance with the prescribed best practices of the maturity model.
Note that this chapter assumes a basic knowledge of maturity models. In an effort to reduce the content of this dissertation, the detailed descriptions of the mapped maturity models have been removed. For those who are interested in these details, see: CMMI-SE/SW/IPPD/SS, v1.1, P3M3, v0.1 and SE-CMM, v1.1. Furthermore, basic knowledge of generic lifecycles and the Enterprise-, Product-, and Technology Lifecycles in particular is required. If the reader is unfamiliar with these concepts, it may be worthwhile to refer to Van der Ven and Poole (1995), Williams et al. (1998), Williams, Bernus, Uppington and Nemes (1998), Du Preez (2004), Louw (2005) and Katz (2005).
2.1 Maturity Model selection
The choice of maturity models from which to select for the purpose of this mapping exercise was extensive. The number of maturity models developed by the year 2002 had already reached 120 (Champlin 2002). The
types of models are also diverse, covering the domains of: Software Development, Business Development, Project Management, Information Technology Management, Data Management, Systems Engineering, Knowledge Management, etc. A selection had to be made as to which maturity models to analyse. Having spent a considerable amount of time wading through the high-level content of approximately 15 models, the eventual choice was based upon the arguments presented below.
The first constraint, although an unfortunate one, immediately narrowed down the selection. Only certain models were public domain. Documentation pertaining to these models was and is readily available. Those models not in the public domain were generally proprietary to the developing organisation and often formed part of a consulting methodology. These models were therefore excluded.
The selection logic that followed was of a qualitative nature and considered (in no particular order) the following aspects: origin and relationship with other models, model detail available, domain of application (i.e. Systems Engineering, Knowledge Management, etc.), industry acceptance of the model, and type of model (staged or continuous representation – see CMMI-SE/SW/IPPD/SS, v1.1). These criteria could not be evaluated in all the models, but played a strong role in at least several selection decisions.
The first of an extensive list of maturity models was developed by the Software Engineering Institute (SEI) of Carnegie-Mellon University, under the sponsorship of the United States Department of Defence (Cooke- Davies 2004; Shrum and Phillips 2004). The Department of Defence identified the need for a more mature and structured approach to Software Development. Development of the first Capability Maturity Model® for
Software (SW-CMM®) commenced around 1986, based on the original works of Watts Humphrey (see
Section 1.2), and was first published in 1993 (Version 1.1). Continued revision arising out of workshops and ongoing feedback continued until 1992. Following this, the growth in maturity models really took off and numerous models were eventually created in various domains of practice. The vast majority of these models were based on the initial works of the SEI (SW-CMM®, v1.1).
Considering the abovementioned origins of maturity models, it was logical to select at least one of the SEI products. This too is a fairly extensive list, including: Software Development, Systems Engineering, Integrated Product and Process Development, Workforce Management, People Management, etc. (CMMI- SE/SW/IPPD/SS, v1.1). The eventual selection was that of the Capability Maturity Model Integration®,
Version 1.1, or CMMI-SE/SW/IPPD/SS, v1.1. This is the latest development of the SEI and endeavours to integrate the domains of Systems Engineering, Software Development, Integrated Product and Process Development and Supplier Sourcing. Industry acceptance and support for the model is extensive and it enjoys application in various industries and in organisations of varying size (Goldenson and Gibson 2003; see Appendix A).
The next model selected was that of the Portfolio, Programme and Project Management Maturity Model, Version 0.1, or P3M3, of the Office of Government Commerce (OGC). Extreme interest from within organisations as to the most effective means of measuring project performance has become evident (Cooke- Davies 2004). This is particularly true for organisations concerned with governance, portfolio management,
and enterprise-wide project management (Cooke-Davies 2004). It is also common knowledge that all enterprises, at some time, will employ a project approach to execute and fulfil objectives. It was therefore logical to select a maturity model designed to assess and guide the improvement of project management capability. The names of several such models could be obtained (such as PM Solutions‟ Project Management Maturity Model and the OGC‟s Prince2™ Maturity Model), but the detail of P3M3 was most readily available. P3M3 is strongly based on the original products of the SEI (P3M3, v0.1), and thus utilises the same model structure as that of the SEI‟s staged representation.
The third and final model selected was the Systems Engineering Capability Maturity Model®, or SE-CMM®,
also a product of the SEI. This model was published in 1995 and was one of the original works of the SEI, closely following the release of SW-CMM® (Version 1.1) in 1993. Although specific domain practices of
Systems Engineering were later integrated into the consolidated CMMI® (one of the selected models), there
were two primary reasons for selecting this model. The first is based on the maturity model representation type of the SE-CMM®. This model employed the continuous approach rather than the staged approach
employed by the previous two selections (although CMMI is also available in the continuous format). SE- CMM is available in only this format due to the structuring of Systems Engineering domain practices. The second reason for selecting the SE-CMM was based on the nature of the Systems Engineering domain. Systems Engineering principles are generic in their application, where “system” can refer to practically any “construct or collection of different elements that together produce results not obtainable by the elements alone” (Rechtin, 1999). By implication then, the model constitutes a generic nature that is of obvious valuable in better understanding maturity models and organisational maturity in general.
Selecting more than three models was considered briefly, but the idea was later rejected in an effort to concentrate analyses on a smaller selection of models and develop a better understanding of those models.
2.2 Mapping activity explained
Various aspects needed consideration before and during the execution of the mappings and these will be discussed in this section.
2.2.1 Granularity of mappings
It is generally a difficult task to determine the appropriate granularity of comparison between models. A high-level mapping may not deliver sufficient insight into similarities and differences, or bring the desired understanding of the models themselves. At a low level, resultant data may be overwhelming and generally fail to accurately clarify model association.
It was thus logical to map the chosen maturity model level of detail directly onto the relevant lifecycle phases. A more detailed mapping (onto lifecycle phase activities for example) may have proven tedious and not adequately more insightful. It is the lifecycle phase impact and support that was of interest to this study, and not the impact on individual activities within each phase.
The necessary maturity model level of detail required a slightly more complex decision process however. There were basically three levels of detail from which to select: the maturity levels (or capability levels in the case of continuous representations), the process areas, or the specific and generic practices.
With the level of detail at maturity/capability levels, a holistic understanding of the process areas and practices would have needed to be established and consolidated for each of the levels. This would have been extremely challenging, considering the complex interaction of process areas and practices within each level, and each having a different impact on the lifecycle phases.
The mappings would have contained an extremely large amount of impacts (relations) at a specific and generic practices level of detail. Specific practices are also focused towards achieving the specific objectives of a given process area. Thus, lifecycle phase impacts of these practices may not even have differed for a specific process area.
Given the above arguments, it appeared logical then to select the process areas as the appropriate level of detail for the mappings. This would sufficiently deconstruct the maturity/capability levels to extract the desired information and describe the impact profile of the maturity models on the lifecycles phases. To establish the impact of a specific maturity level, on a specific phase, the impacts of the individual process areas within that maturity level could then simply be aggregated.
2.2.2 Definition of impact and support
Impact may be defined as evidence of direct or indirect relation between the specific process area and the specific lifecycle phase, determined through a comparison of the relevant summaries. The degree of impact (rating) is the perceived level to which this direct or indirect relation is observed during the comparison of summaries (see Table 1). The aggregated effect of all process areas in a specific maturity/capability level on a specific lifecycle phase is also referred to as impact.
Support is the aggregated effect of all process areas, in all maturity levels of a specific maturity model on a specific lifecycle phase. It is thus the total impact of the maturity model on the specific lifecycle phase. It provides an indication of the maturity model‟s overall ability to facilitate the various activities of a specific lifecycle phase.
2.2.3 Grading of mappings
There are two basic factors that were considered in determining the level of impact of a specific process area on any lifecycle phase. The first is the necessity to perform process area activities in the lifecycle phase, as specified by the process area itself, and so facilitate the execution of that phase. If the specification was not explicitly made, interpretation was required based on an understanding of both the specific lifecycle phase and the specific process area. This was achieved through the simultaneous comparison of the process area and lifecycle phase summaries.
The second factor considered in deciding on a level of impact was that of either a direct or indirect positive effect of the successful execution of a process area on the specific lifecycle phase. Thus, process area activities do not necessarily need to be executed within the phase. The effects of activities executed within others phases, but that have a significant consequence on the specific phase, are captured in the level of impact.
The actual impact rating of a process area on a specific lifecycle phase is assigned based on the abovementioned factors. The rating is between 0 (zero) and 4 (four) and graded as follows:
Rating Description
0 (zero) Zero perceivable impact – no evidence of process area and lifecycle phase relation
1 (one) Small perceivable impact – evidence of weak indirect relation between process area and lifecycle phase
2 (two) Moderate perceivable impact – evidence of moderate direct or indirect relation between process area and lifecycle phase
3 (three) Strong perceivable impact – strong evidence of moderate or strong direct relation between process area and lifecycle phase
4 (four) Extremely strong perceivable impact – very strong evidence or specific mention of direct process area relation with lifecycle phase