Efficiency Models in it Field

In spite of different approaches regarding the best practices in the IT area, there is a general consensus about the importance of three, widely used efficiency models: the Capability Maturity Model - CMM (Humphrey, 1989; Paulk et al, 1995), the Project Management Maturity Model - PMMM (Kerzner, 2000, 2001); the Project Management Body of Knowledge - PMBoK (PMI, 2000), and Quality Systems for software - ISO9000-3 (2001) and ISO 12207 (1995). In order to verify managerial IT practices in the studied companies, the analysis was performed based on these models. All of them are empirical and were developed based on best practices used in real projects. Although they have different approaches in their conception, they are rather more complementary than conflictive.

Capability Maturity Model (CMM)

The implementation of formal efficiency procedures is quite new in IT projects. Pressman (1987) describes quality assurance activities in software. Humphrey (1989) identifies maturity levels in the IT project development process, based on the managerial behavior found in companies. The fundamental concepts of the process maturity derive from the belief that the development management process is evolutionary. Paulk et al. (1995) identify the distinguishing characteristics between immature and mature organizations, as shown in Table 1.

Table 1: Immature organization x mature organization (adapted from Paulk et al., 1995)

IMMATURE ORGANIZATION

MATURE ORGANIZATION

  • Ad hoc; improvised process by practitioners and managers

  • Not rigorously followed and not controlled

  • Highly dependent on personal knowledge

  • Little understanding of progress and quality

  • Compromising product functionality and quality to meet schedule

  • High risk when new technology is applied

  • High maintenance costs and unpredictable quality

  • Coherent with action plans; the work is effectively achieved

  • Processes are documented and continuously improved

  • Perceptible top and middle management commitment

  • Well controlled assessment of the process

  • Product and process measures are used

  • Disciplined use of technology

The CMM - Capability Maturity Model (Humphrey, 1989; Paulk et al., 1995; Pessôa & Spinola, 1997) was developed by SEI - the Software Engineering Institute, of Carnegie Mellon University, and presents five maturity levels, each corresponding to a set of structural requirements for key process areas (Figure 1).

click to expand
Figure 1: Maturity levels (adapted from Paulk et al., 1995)

Although each project is unique, it could be organized in a process to be applied in other projects. IT projects managers used to apply a "methodology", i.e. they establish the steps to be followed in order to develop a system. Another singular characteristic is the dynamic technologies breakthrough that demands continuous improvements in the development methods and management of changing process, as described in CMM model, at level 5, the highest level of maturity.

The analysis through CMM requirements shows that all cases denote improvement possibilities. Cases "A" and "B" do not use CMM as a referential model, but an internal developed "methodology." According to CMM requirements, Cases "A" and "B" are at the first maturity level. However, this does not mean that they are equally efficient, which can be explained by the difficulty of passing to higher stages. Case "B" presents more structured project evaluation and control procedures, discussing effectiveness aspects (formal meetings among IT and users) and efficiency (cost and benefit analysis). Case "C" adopted CMM and has just moved to the second level.

The CMM second level has a consistent project management structure and the goal of this level is to deliver projects on time. To perform this, the model have several points that must be achieved, like effort and size estimation, strong process control (such as periodic meetings between technical people and managers), and several measures to show project status more clearly.

CMM is not an adequate reference for the assessment of internal methodologies, since it was not conceived to perform this kind of analysis. ISO 15504 (1998) proposed the standard project SPICE as a more appropriated model to evaluate maturity level of specific processes. While CMM level of maturity specifies a set of processes that have to be performed, ISO 15504 establishes maturity levels for each individual process: level 0-incomplete; level 1-performed; level 2-managed; level 3-established; level 4-predictable; level 5-optimizing. This is a different approach of CMM, since an organization does not perform a maturity level, but have a maturity profile: a maturity level is measured for each specific process. This new approach is a very useful to the organization perspective because one can easily measure strong and weak points of their process and plan improvement activities. Furthermore, from the companies' point of view, it is easier to understand staged levels as the performed processes are already predefined.

The SPICE approach defined in standard ISO 15504 (1998) had firstly influenced CMM for Systems Engineering, published in 1995 and more recently influenced CMM I (CMM-I1; CMM-I2), just published in 2002. CMM-I, the integration model, was enhanced in two dimensions: scope dimension and evaluation dimension.

In the scope dimension, this new model incorporated other published models and cover all project activities, not only software, as the original software CMM did, but also other engineering fields. In the evaluation dimension, CMM-Il incorporated both approaches: the traditional (called staged CMM) and the maturity profile (called continuous CMM). Figure 2 shows the continuous CMM-I representation to be compatible with ISO/IEC 15504 standard.

click to expand
Figure 2: Continuous maturity process representation in CMM-I (adapted from CMM-I1, 2002)

CMM-I (and software CMM) considers that maturity level is an organizational characteristic and it is independent of the professionals involved.

Project Management Model

Project Management plays an important role in the competitive scenario, and achieves in 90's the status of methodology. The model proposed by Project Management Institute - PMI (2000), called Project Management Body of Knowledge (PMBoK), provides a framework to manage project efficiency, balancing scope expectations and the available resources (Rabechini Jr & Carvalho, 1999). This model proposes the following nine key areas: (i) integration; (ii) scope; (iii) time; (iv) cost; (v) quality; (vi) human resource; (vii) communication; (viii) risk; (ix) procurement.

Nevertheless, the PMBoK framework cannot provide a standard benchmark for project management capability as CMM to software engineering capabilities. In order to extend the capability maturity model (CMM) to project management, Kerzner (2000) and (2001) proposes a Project Management Maturity Model (PMMM).

The PMMM differs in many aspects from the CMM, but this framework also introduces benchmarking instruments for measuring an organization's progress along the maturity model, detailing five levels of development for achieving maturity: level 1 - common language, level 2 - common processes, level 3 - singular methodology, level 4 - benchmarking, and level 5 - continuous improvement, as shown in Figure 3.

click to expand
Figure 3: Project management maturity model - PMMM (adapted from Kerzner, 2001)

It is important to highlight the differences in terminology between the CMM and PMMM, (compare Figures 2 and 3) which could lead to misunderstanding when both models are being implemented in the IT domain of the same organization.

PMMM addresses the key knowledge areas across the project management process, in compliance with PMBoK, and integrates them with the Project Management Office - PMO in the strategic level.

Kerzner (2000) identifies a life cycle in PMMM level 2, common processes, which could be broken into five phases: embryonic; executive management acceptance; line management acceptance; growth and maturity, as shown in Figure 4. It is important to note that some simultaneity among the phases can occur.

click to expand
Figure 4: Life cycle phases (Kerzner, 2000)

The embryonic phase means that the organization starts to recognize the benefits of project management - PM, usually by lower and middle levels of management. The two next phases are achieved when the PM concepts are accepted and have visible support and commitment by executive and line management.

Kerzner (2001) emphasizes the growth phase as the most critical, because it is the beginning of the creation of the PM process, and warns that different methodologies for each project should be avoided.

The last life cycle phase -maturity - is difficult to achieve due to several factors such as organizational resistance to project cost control and horizontal accounting.

The main characteristics of these life cycle phases emphasized by Kerzner (2001) are described in Table 2.

Table 2: Life cycle phases characteristics (Kezner, 2001)

Phase

Characteristics

embryonic

  • recognizing the need for PM;

  • recognizing PM's potential benefits;

  • applications of PM to the business;

  • recognizing the changes necessary to implement PM.

executive management acceptance

  • visible executive support;

  • executive understanding of PM;

  • project sponsorship;

  • willingness to change the way the company does business.

line management acceptance

  • visible line management support;

  • line management commitment to PM;

  • line management education;

  • release of functional employees for PM training programs.

growth

  • development of company PM life cycles;

  • development of a PM methodology;

  • a commitment to effective planning;

  • minimization of scope;

  • selection of PM software to support methodology.

maturity

  • development of a management cost/schedule control system;

  • integration of schedule and cost control;

  • development of an educational curriculum to support PM.

Analysis through the PMMM life cycle analysis requirements states that all cases do not achieve the maturity phase. According to this model, Case "A" is in the first life cycle phase, embryonic. In Case "B", it could be identified a strong commitment with PM programs by executive management board, but there is a lack of support by the line management. Case "B" develops different projects evaluation and control procedures for each type of project, which affect the PM efficiency. Case "C" presents the higher maturity level, it could be classified in the beginning of growth phase. The support of executive and line management to PM programs is visible and there are effective planning procedures (see Figure 4).

Quality Systems

It is important to note that the adoption of systems models, such as ISO 9000, focuses on the creation and maintenance of a quality system, applied to any process. The ISO 9001:2000 new version, published in the year 2000, was fully restructured to have a more clear process focused approach. Other ISO standards offer an overview of these standards to the software field and contribute to deploying this approach to specific processes, such as: software products (ISO 9126-NBR 13596), quality requirements for software packages (ISO 12119), and the software life cycle process (ISO 12207).

ISO 9000-3 (2001) is a guide to help with ISO 9001 interpretation for the software field, i.e., the development, supply, acquisition and maintenance of software (Pessôa & Spinola, 1997). The previous versions of this guide were developed by the ISO/TC/SC2 committee, the quality branch of ISO. Nowadays this ISO 9000-3 guide is being revised by ISO/IEC JTC1/ SC7, the information technology branch, and a new version is planned to be published in 2002. The ISO9001:2000 new structure made this task easier than previous versions and it is incorporating a map of the relationship between IT standards (ISO/IEC JTC1/SC7) and its respective quality systems described in ISO 9001 to this standard. For example, ISO 9001 specifies that the organizations have to identify their processes and ISO 12207 (ISO12207) proposes a set of processes involving software development, supply, acquisition and maintenance. In addition to ISO 12207, other standards are referenced, such as ISO 9126 for software products, ISO 12119 for quality requirements for software packages and ISO 15504 for software evaluation. This was considered an improvement of the standards structure that matches quality system standards with technical and specific standards.

ISO 9001:2000 standards have the purpose of certifying organizations whose Quality Systems comply with the standards and provides a structure to manage quality independent of the organizational activity. This is not enough for specific fields of application and, for this reason there are complementary sets of standards in some areas, like QS-9000 for the automobile industry and TL-9000 for the telecommunications industry.

The standards from ISO/IEC/ JTC1/SC7 have the purpose of complementing the quality system for the IT specific area, not focusing on applications as with the automobile or telecommunications industry, but considering the specificities of software and systems development.

In general, ISO 9000 can be a good starting point for implementing a quality system. This system allows the organizations to disseminate quality culture and create the initial structure to implement more specific quality systems. This can be observed in the studied cases.

In general, the Quality System (ISO 9000), processes (CMM) and project (PMI) models have the possibility of mutual and complementary synergy, maintaining consistency with their fundamental points. On the other hand, there are important differences among these models, especially concerning the degree of abstraction. (Pessôa et al., 1997b; Tingey, 1997).



Managing Globally with Information Technology
Managing Globally with Information Technology
ISBN: 193177742X
EAN: 2147483647
Year: 2002
Pages: 224

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net