IT Project Development Fundamentals

INFORMATION TECHNOLOGY PROJECT DEVELOPMENT
FUNDAMENTALS1
ALEJANDRO DOMÍNGUEZ-TORRES
JADOMING@MAIL.UNITEC.MX
SCHOOL OF POSTGRADUATE STUDIES
UNIVERSIDAD TECNOLÓGICA DE MÉXICO (UNITEC), WWW.UNITEC.MX

CONTENTS
1 INTRODUCTION ....................................................................................................................................... 6

1.1 CONTEXT .............................................................................................................................................. 6

1.2 OBJECTIVES .......................................................................................................................................... 6

1.3 KEY WORDS .......................................................................................................................................... 7

1.4 ASSESSMENT ACTIVITY ......................................................................................................................... 7

2 INFORMATION TECHNOLOGY PROJECT DEVELOPMENT BASICS......................................... 9

2.1 SUMMARY ............................................................................................................................................ 9

2.2 IT PROJECT DEVELOPMENT ................................................................................................................... 9

2.3 IT PROJECT DEVELOPMENT ELEMENTS ................................................................................................ 11

2.3.1 People............................................................................................................................................ 11

2.3.2 Process .......................................................................................................................................... 13

2.3.3 Product/service ............................................................................................................................. 13

2.3.4 Information.................................................................................................................................... 14

2.3.5 Tools .............................................................................................................................................. 15

2.4 THE RELATIONSHIP AMONG THE FIVE ELEMENTS ................................................................................ 16

2.5 BIBLIOGRAPHICAL REFERENCES ......................................................................................................... 18

3 CAPABILITY MATURITY MODELS ................................................................................................... 19

3.1 SUMMARY .......................................................................................................................................... 19

1
Development and administration of information projects. At a distance course. Inter-american Center for Social
Security Studies. September 2003.

August 2004 Page 1 of 39

3.2 BACKGROUND .................................................................................................................................... 19

3.3 CMM FOR SOFTWARE ......................................................................................................................... 20

3.3.1 The software project development process.................................................................................... 20

3.3.2 S-CMM components ...................................................................................................................... 21

3.3.3 S-CMM framework ........................................................................................................................ 22

3.3.4 Key process areas (KPAs) ............................................................................................................. 24

3.3.5 Goals ............................................................................................................................................. 25

3.3.6 Common features .......................................................................................................................... 27

3.3.7 Key practices ................................................................................................................................. 27

3.3.8 S-CMM in organisations ............................................................................................................... 28

3.3.9 Conclusion .................................................................................................................................... 30

3.4 CMM FOR PEOPLE .............................................................................................................................. 30

3.4.1 Background ................................................................................................................................... 30

3.4.2 Themes .......................................................................................................................................... 30

3.4.3 Key process areas (KPAs) ............................................................................................................. 31

3.4.4 Implementation .............................................................................................................................. 32


4 COMMUNICATION PROCESS WITHIN AN IT PROJECT ............................................................. 35

4.1 SUMMARY .......................................................................................................................................... 35

4.2 ELEMENTS OF A COMMUNICATION PLAN ............................................................................................. 35

4.3 COMMUNICATIONS STRATEGIES.......................................................................................................... 36

4.3.1 Project Characteristics and Requirements .................................................................................... 36

4.3.2 Communications requirements ...................................................................................................... 37

4.3.3 Technical capabilities ................................................................................................................... 38

4.3.4 Staff considerations ....................................................................................................................... 38

4.4 CONCLUSIONS..................................................................................................................................... 39



FIGURES
FIGURE 1. FORMAL AND INFORMAL INFORMATION. ............................................................................................... 15

FIGURE 2. RELATIONSHIP OF THE FIVE ELEMENTS: EQUILIBRIUM. ......................................................................... 16

FIGURE 3. BUILDING A MORE DIFFICULT PRODUCT/SERVICE BY INCREASING CAPABILITY FROM PEOPLE. .............. 17

FIGURE 4. BUILDING A MORE DIFFICULT PRODUCT/SERVICE BY INCREASING CAPABILITY FROM PROCESS. ............ 17

FIGURE 5. BUILDING A MORE DIFFICULT PRODUCT/SERVICE BY INCREASING CAPABILITY FROM PEOPLE AND
PROCESS. ...................................................................................................................................................... 17

FIGURE 6. MATURITY LEVELS REPRESENTATION. .................................................................................................. 20

FIGURE 7. THE FIVE LEVELS OF SOFTWARE PROCESS MATURITY. ........................................................................... 23

FIGURE 8. S-CMM STRUCTURE. ............................................................................................................................ 24

FIGURE 9. EXAMPLE OF A KEY PRACTICE. .............................................................................................................. 28

FIGURE 10. PROJECT COMMUNICATION CHANNELS. ............................................................................................... 39

TABLES
TABLE 1. TOPICS FOR DEVELOPING IT PROJECTS. .................................................................................................... 9

TABLE 2. SOME IT PROJECTS AND THEIR DESCRIPTION. ........................................................................................... 9

TABLE 3. STAKEHOLDERS RESPONSIBILITIES. ........................................................................................................ 12

TABLE 4. STATEMENTS ABOUT PROCESS. .............................................................................................................. 13

TABLE 5. FORMAL AND INFORMAL INFORMATION. ................................................................................................ 14

TABLE 6. TOOLS FOR PROJECT DEVELOPMENT. ...................................................................................................... 15

TABLE 7. CRITERIA FOR THE EVALUATION AND SELECTION OF PROJECT DEVELOPMENT TOOLS............................. 15

TABLE 8. STEPS FOR DEVELOPING A SOFTWARE PROJECT. ..................................................................................... 21

TABLE 9. SOME S-CMM COMPONENTS. ................................................................................................................ 22

TABLE 10. S-CMM LEVELS. .................................................................................................................................. 23

TABLE 11. S-CMM KPAS. .................................................................................................................................... 24

TABLE 12. GOALS FOR EACH KPA. ........................................................................................................................ 25

TABLE 13. COMMON FEATURES DESCRIPTION. ....................................................................................................... 27

TABLE 14. S-CMM LEVEL 4 AND 5 ORGANISATIONS. ............................................................................................ 29


TABLE 15. PERCENT IMPROVEMENT COMPARED WITH RESULTS AT PREVIOUS LEVELS. ......................................... 30

TABLE 16. P-CMM LEVELS. .................................................................................................................................. 31

TABLE 17. P-CMM THEMES. ................................................................................................................................. 31

TABLE 18. KPA NECESSARY TO ADDRESS EACH OF THE FOUR THEMES OF THE P-CMM. ...................................... 32

TABLE 19. EXAMPLE FOR THE TRAINING KPA. ..................................................................................................... 33

TABLE 20. BASIC ELEMENTS TO BE CONSIDERED FOR ANY COMMUNICATION PLAN. .............................................. 35

TABLE 21. KEY FACTORS FOR EVERY PROJECT. ..................................................................................................... 36

TABLE 22. COMMUNICATIONS REQUIREMENTS ANALYSIS: THE PURPOUSE. ........................................................... 37


1 INTRODUCTION
1.1 CONTEXT

Information Technology (IT) industry moves rigorously toward new methods for managing
the increasing complexity of IT projects. In the past there have been several evolutions,
revolutions, and recurring themes of success and failure.

At present, success of IT projects depends on having in equilibrium five main components:
People, Information, Process, Tools, and Products/Services. All of the five components are
important at the moment of developing any IT project. Two of them have been explored in
detail in the past. These two components are: People and Process.

People and process require having a conducting channel permitting communication among
their several composing elements as well as between them. Without communication there is
no way of developing any IT project.

Study and description of the relation and equilibrium of these five components, paying special
attention in People and Process, as well as the communication as “glue” of IT project
development, are the purposes of this first module.

Chapter 1 discusses IT project development as part of the delivery of IT services and
functions, presents the major five elements of IT project development as a foundation for the
specification of standard practices and procedures, and shows the relationship among the
elements and how changes in one element affect the others.

Chapter 2 goes into Process and People components and discusses two models for project
development success. These models are the Software Engineering Institute (SEI) “Software
Capability Maturity Model (S-CMM)” and “People Capability Maturity Model (P-CMM)”.

Finally, Chapter 3 discusses two main topics: elements of a communication plan and some
communication strategies.

1.2 OBJECTIVES

 Analyse the major five elements of IT project development as a foundation for the
specification of standard practices and procedures, as well as the relationship among
these elements.
 Analyse two international standards for project development associated to People and
Process.
 Analyse the importance of communication in project development.


1.3 KEY WORDS

Common Features Communication Strategies
Communications Plan Goals
Information Information Technology Project Development
Key Practices Key Process Areas
Maturity Level People
People Capability Maturity Model Process
Product/Service Software Capability Maturity Model
Software Process Capability Tools

1.4 ASSESSMENT ACTIVITY

Consider the actual situation of an organisation; this one could be either where you work for
or one you chose (this organisation must develop software applications).

Using the following table, assess that organisation in order to know how far is from S-CMM
level 2.

Repeatable KPAs Goal 1 Goal 2 Goal 3 Goal 4

Invalid Invalid
Requirements management
grid grid

Invalid
Project planning
grid

Invalid
Project tracking and oversight
grid

Software subcontract management

Software quality assurance

Configuration management

Fully Satisfied Not Satisfied

Not Applicable Not Rated

Once you have analysed organisation’s situation, rate each goal and write (in MSWord) a
justification for it. Each justification will be clear, concise, and less or equal than a half a
page.

The document you write must follow next structure:

 Front page, give the following data: name, e-mail, city, country, name given to your
work, and date
 Abstract page (no more than 200 words)

 Organisation background (this is the organisation where assessment is applied). It
should contain information to know the type of organisation you are assessing
 The assessment and their justification
 For each “not satisfied” mark, indicate how to proceed in order to change this mark to
a “fully satisfied” mark; that is, say how you solve the problem (again, the solution for
each “not satisfied” will be less than a half a page)
 Give some conclusions of your own


2 INFORMATION TECHNOLOGY PROJECT DEVELOPMENT BASICS
2.1 SUMMARY

This chapter presents some useful guidelines to develop Information Technology (IT) projects
as shown in the following Table.

Table 1. Topics for developing IT projects.

SECTION SECTION ABSTRACT
Discusses IT project development as part of the delivery of IT services and
1.1 IT PROJECT DEVELOPMENT
functions
1.2 IT PROJECT DEVELOPMENT Presents the five major elements of IT project development as a foundation
ELEMENTS for the specification of standard practices and procedures
1.3 THE RELATIONSHIP OF THE Shows the relationship among elements and how changes in one element
FIVE ELEMENTS affect the other ones

2.2 IT PROJECT DEVELOPMENT

IT is present in all business matters. However, if business goals are to be met, processes by
which IT solutions are chosen, designed, and implemented have to be developed by a
carefully crafted set of strategies and procedures. This is the essence of IT project
development.

IT project development consists of a set of structured process for achieving a specific and
unique outcome in a defined and bounded period of time. Successful outcomes are more
likely when an IT project is properly defined, designed, implemented, and controlled.

IT projects come in many different shapes and sizes, some of them are shown next.

Table 2. Some IT projects and their description.

TYPE OF IT PROJECT DESCRIPTION
The evaluation of IT and its use in an organisation, which may include the selection
FEASIBILITY STUDIES
of IT solutions and recommendations for future strategies
The design, testing, integration, and implementation of customised IT applications,
IT DEVELOPMENT
and related platforms and interfaces
IT UPGRADE The upgrade of existing IT platforms, solutions, and products
The replacement and/or removal of existing IT platforms and solutions; typically
IT MIGRATION
replaced by different products
The participation of IT as a change agent; it includes office renovations, relocations,
SUPPORT SERVICES
organisation mergers, training programs, and internal reorganisations
Relate to the improvement of IT performance and service delivery; it includes IT
IT MANAGEMENT
process re-engineering, maintenance, security audits, and documentation projects


Nevertheless, the list given does not end here. For when IT is chosen and installed, it must
also be maintained and supported. Moreover, the fast pace of technological change mandates
an ongoing cycle of IT enhancement, upgrade, and renovation.

Whether the IT development goal is to design, install, or re-engineer, IT initiatives are often
driven by aggressive deadlines and periods of frequent change. To accomplish the goals,
resources must be identified and allocated, and activities must be properly organised and
structured in accordance with business and IT requirements.

However, considering the variety of available IT solutions, applied within a diverse range of
business and professional environments, IT project development is not an easy task, for
example:

 IT functionality issues are often mistaken for technical problems;
 There is a limited tolerance for downtime that may greatly complicate the
implementation of platform upgrades and migrations.

As such, the traditional boundaries that exist between IT projects and ongoing operations tend
to blur IT world, creating unique development challenges.

IT project development best practices can be used to address those challenges. Considering
the need for consistent quality and fast delivery, any practices designed to deliver
performance and productivity will prove worthwhile, provided that the practices are not
allowed to overtake the purpose.

As with any other discipline, IT project development must be put in proper organisational
perspective. To practice effective IT project development, it must have:

 Defined policies and procedures for project selection, definition, design and control;
 Supported and committed management;
 Trained and committed staff;
 An environment that fosters teamwork and cooperation;
 Strong technical capabilities;
 An understanding of business goals and objectives;
 The right IT tools sized to suit project requirements and technical capabilities;
 The authority to enforce and update IT project management practices as needed.

Most organisations face many different types of IT projects, each with its own degree of
urgency and business priority. IT project development best practices can add structure and
definition to this chaos, but not by accident. When they are applied, restrictions and
boundaries influence decisions and activities. Speed, creativity, and innovation must find a
place within an environment of standards, rules, forms, and templates.

Project success is increased when the required deliverables are produced on time and within
budget. Moreover, to be truly successful, IT projects should have:

 Realistic and workable plans;
 Strong management commitment;
 Proper oversight and monitoring;


 Effective analysis of risks;
 Strong business justifications;
 Controlled costs;
 Sound technical designs and deployment plans;
 Realistic expectations;
 Strong teamwork.

To deliver successful results on a consistent basis, workable, realistic standards and best
practices must be defined and applied. These standards must be aligned with organisational
requirements, internal capabilities, and project characteristics.

2.3 IT PROJECT DEVELOPMENT ELEMENTS

Any IT project development includes five main elements: People, Process, Product/Service,
Information, and Tools. Successful IT project development requires keeping these five
elements in harmony. Balancing the elements means looking at who is trying to build what, so
it becomes important to think about the elements at the project’s development start.

2.3.1 PEOPLE

The primary element of any IT project is the People:

 People gather requirements;
 People interview users (People);
 People design IT for People;
 No People – no IT.

The best thing that can happen to any IT project is to have:

 People who know what they are doing and have the courage and self-discipline to do
it;
 Knowledgeable people to do what is right and to avoid what is wrong;
 Courageous people to tell the truth when others want to hear something else;
 Disciplined people to work through projects and do not cut corners.

A successful IT project development requires that project team participates (at some level) in
the design process and be responsible for completion of assignments.

It is important to have a defined formal organisation for project and for project staff. This
provides each individual with a clear understanding of the authority given and responsibility
necessary for successful accomplishment of project activities. Project team members need to
be accountable for effective performance of their assignments.

Project Organisational Structures come in many forms. However, their impact can be seen
throughout the project. For example:

 On a large project, individual role assignments may require full-time attention to the
function;


 On smaller projects, role assignments may be performed part-time, with staff sharing
in the execution of multiple functions.

Project team includes a diverse mix of people and skills. It goes beyond just the project
member performing specific tasks. The required mix for any project team will include, but not
be limited to, the following people:

 People specifically charged with implementation of project solution (also known as
“the project team”):
o Requirements development staff;
o Business rule specifications staff;
o Project management staff;
o Subject matter experts;
o Documentation (user and technical) staff;
o Training staff;
o Technical staff;
o Leaders/decision makers;
 Customers (both internal and external) of the product/service created;
 Project sponsor;
 Stakeholders.

Stakeholders are individuals and organisations that have a vested interest in the success of the
project. Identification and input of stakeholders help to define, clarify, drive, change, and
contribute to the scope and, ultimately, the success of the project.

To ensure project success, project team needs to identify stakeholders early in the project,
determine their needs and expectations, and manage and influence those expectations over the
course of the project.

Stakeholders on every project include the following people and groups:

Table 3. Stakeholders responsibilities.

STAKEHOLDER RESPONSIBILITY
PROJECT MANAGER Who has ultimate responsibility for ensuring project success
Who takes the lead in getting the need for the project recognition as well
PROJECT SPONSOR
as possibly providing financial resources
ORGANISATIONAL MANAGEMENT Who defines the business needs of the project
PROJECT TEAM MEMBERS Who are responsible for performing the work on the project
CONFIGURATION MANAGEMENT Who are responsible for manage project configuration within the
ENTITIES boundaries of the project
Who verify the ability of the product/service to meet the stated necessary
QUALITY ASSURANCE TEAMS
requirements
ORGANISATIONAL PROCUREMENT
Who assist in procuring project resources
PERSONNEL

Who is the person(s) or organisation(s) using the product/service of the
CUSTOMER
project


2.3.2 PROCESS

Process is how people go from the beginning to the end of a project. All projects use a
process. Many IT project managers, however, do not choose a process based on the people
and product/service at hand. They simply use the same process they have always used or
misused.

There are two main statements regarding process: Process Improvement and Right Process
Use. These two statements are discussed in the table below.

Table 4. Statements about Process.

STATEMENT DESCRIPTION

PROCESS  It is the key to increasing the ability to produce IT
IMPROVEMENT  There must have a process before it can be improved
 There are different and useful process models
 A good and standard processes models are “The Software Capability Maturity Model (S-
RIGHT CMM)”, and “The Capability Maturity Model for People (P-CMM)”
PROCESS USE  S-CMM and P-CMM have a series of levels through which an organisation can progress
from the chaotic level 1 (Initial) up through level 5 (Optimised) (see Chapter 2 for more
details)

2.3.3 PRODUCT/SERVICE

Product/service is the result of an IT project. The desired product/service satisfies the
customers and keeps them coming back for more. Sometimes, however, the actual
product/service is something less.

Product/service pays the bills and ultimately allows people to work together in a process and
build IT. Always keep product/service in focus. The current emphasis on process sometimes
causes to forget product/service. This results in a poor product/service, no money, no more
business, and no more need for people and process.

Instead of discussing different types of products/services (computer systems, data networks,
voice networks, etc.), it is better to focus on two other aspects of product/service:

 Difficulty of building product/service;
 External and internal quality.

Difficulty of product/service influences the process needed. "Difficult" is subjective and
depends on how familiar people are with product/service. For example, for some people a text
editor is a very difficult product, while an intelligent image analyser is simple for other ones.

Answering the following questions determines the "difficulty" of product/service and the type
of process needed:

 Is product/service familiar or new to people?
 Is it new to everyone in the World?
 Is the user interface a major portion of product/service?


Difficult products/services demand process models that allow for experimenting and learning.
Easy products/services call for process models that are simple, straightforward, and efficient.
Difficult products/services become easier when it is brought in people with knowledge of the
product/service.

On the other hand, it is always important to keep in mind the external and internal quality of
product/service. External quality is what the customer sees. The customer is happy if
product/service has all the required functions, is easy to learn and use, runs quickly, and does
not demand so many resources to operate.

Internal quality is what the builder sees. High internal quality indicates, among other things,
that the design is easy to understand and result is according to customer specifications. When
the customer announces changes in the IT platform, high internal quality lets to change
product/service quickly and easily.

These quality factors also influence people and process. For example, if portability (internal
quality) is important, it must be available people having expertise in several IT platforms. If
these people are not available, it must be allowed for learning and risk in the process.

2.3.4 INFORMATION

Information is an essential commodity for the operation and development of a project and its
organisation. In order to understand the nature of information, it is important to understand
the purposes for which is provided. However, the primary purpose of information is aid to
decision making.

The estimation of the value of information is a difficult area. In some cases a quantitative
measure may be placed on the provision of speedier information, as in debtor control, or in
the reduction of uncertainty. These are, however, intangible benefits. It is difficult, if not
impossible, to analyse the contribution of more effective information to make a better
decision, or to isolate the impact of greater information availability to customers on their
purchases. It is a great mistake to ignore the intangible, no-measurable benefits in assessing
the overall benefits to the firms of a proposed IT.

Finally, it is important to notice that IT project development will be based on available
information both formal and informal (see Table and Figure below):

Table 5. Formal and informal information.

TYPE OF INFORMATION CHARACTERISTICS
It is produced by standard procedures, is objective and is generally regarded as
FORMAL INFORMATION
relevant to a decision
This is often subjective, passed by word mouth, and involves hunches, opinions,
INFORMAL INFORMATION guesstimates and rumour. It generally involves explanatory and/or evaluative
information


Formal information: usually quantitative,
produced by known rules, objective

Informal information: usually qualitative,
no produced by known rules, subjective

Figure 1. Formal and informal information.

2.3.5 TOOLS

Project development tools are the means by which process become reality. Through the use of
software, templates, training and communications systems, process directives are given form
and substance (see Table below). As a result, these tools stand as tangible proof of
development’s commitment to the practice of project development.

Table 6. Tools for project development.

TOOL PURPOSE
SOFTWARE For automating project management activities
TEMPLATES For documenting project activities
TRAINING For educating staff and end-users
COMMUNICATION SYSTEMS For sharing knowledge, information and status

Before any tools can be chosen and properly integrated into the project standards program,
certain key criteria have to be addressed (see Table below). These form a useful set of criteria
for the evaluation and selection of project development tools.

Table 7. Criteria for the evaluation and selection of project development tools.

CRITERIA DESCRIPTION
PROJECT DEVELOPMENT What will product/service accomplish and what role will software, training,
OBJECTIVES templates, and communication play in product/service delivery and execution?
PROJECT AND Software tools must match project characteristics and requirements, including
ORGANISATIONAL size, duration, task complexity, reporting, resource allocations and the need to
CHARACTERISTICS manage multiple projects across an organisation
It must be considered the capacities and characteristics of the current technical
environment. These considerations may include, but are not limited, to
TECHNICAL CAPABILITIES Internet access, intranet access, computing power, access to shared printing,
LAN/WAN connectivity, electronic mail access, and the ability to share data
with external service providers and telecommuters
COMPATIBILITY WITH To fully assess technical compatibility, it will be needed detailed information
CURRENT TECHNOLOGICAL on platform configurations, capacities and structural limitations, as well as the
PLATFORMS corresponding requirements for the products and toolsets to be considered


IT project development may require some degree of maintenance and
STAFF SKILL AND RESOURCE
administration. These requirements must be considered when evaluating skill
AVAILABILITY
levels and resource availability
When considering the selection and deployment of project development tools,
COST TO PURCHASE AND
thought must be given to the costs of testing, evaluation, acquisition,
MAINTAIN
development, deployment, and maintenance.

2.4 THE RELATIONSHIP AMONG THE FIVE ELEMENTS

Figures 2 through 5 show an integrated graphical view of the five elements. Figure 2 shows a
situation of equilibrium (equilateral pentagon) among the elements. This is a desired situation
in any IT project development. The pentagonal region shows the difficulty of developing a
product/service. Obviously, it is easier to build products/services near the centre since they are
less complex. Easy products/services do not require much capability from the other four
elements. As products/services move away from the origin, they become more difficult and
demand more from the complementary elements.

People

Product/Service Information

Tools Process

Figure 2. Relationship of the five elements: Equilibrium.

Figures 3 through 5 show that the added capability needed to build a more difficult
product/service can come through different combinations of improving people.
Product/Service has the same difficulty in all three figures. In each of them, the
product/service moves from a difficulty lower to a higher. In Figure 3, the needed capability
comes from people. This extra capability could be achieved by adding experts or training the
people. Figure 4 shows that the same amount of extra capability can come from improving the
process instead of the people. Using an incremental delivery model or stretching the schedule
is the way to add capability. Figure 5 shows that the extra capability can come from
improving both the people and process. This could be done by bringing in a consultant a few
hours a week, sending one person to training, using rapid prototyping on one part of the
product/service development, using incremental delivery on another, and so on.


People


Tools Process

Figure 3. Building a more difficult product/service by increasing capability from people.

People


Tools Process

Figure 4. Building a more difficult product/service by increasing capability from process.

People


Tools Process

Figure 5. Building a more difficult product/service by increasing capability from people and process.

The point of the graphs is that building a more difficult product/service requires more
capability from somewhere. It cannot be done a new thing with the same old people and
expect something wonderful to happen. It must be improved people, process, information,
tools, or all of them.

Successful IT projects do not happen as often as they should. One way to increase their
frequency is to achieve the proper relationships among the five elements. Given a


product/service to build, choose people, a process, information, and tools that match. Given a
product/service to build and the people to do it, choose a process, information, and tools that
match. Given people who prefer one type of process and have some type of information and
tools, try to build only products/services that match.

The capability to build difficult products/services must come from people, process,
information, and tools. Tougher products/services require people with knowledge in the
product/service area, or doing something different with the process, information and tools.

Select courageous and disciplined people who know the product/service and can work in the
process using the maximum capabilities of information and tools. Use a process, information
and tools that allow the people to build the required product/service. It is important to say that
only should be attempted to build products/services within the capabilities of people, process,
information, and tools.

On the other hand, do not use more capability than is needed. Using desktop publishing
experts on a text editor is a mistake; they will get bored and leave. Think about people,
process, information, tools and product/service. There is always some flexibility on a project.
Choose people, process, information, tools, and product so that they will fit one another.

2.5 BIBLIOGRAPHICAL REFERENCES

Edman, E. G. The project management analysis companion: Creating and implementing
standards for IT project management. Right Track Associates, Inc. www.ittoolkit.com.
USA, 2001-2002.

McConnell, Steve. Rapid development. Microsoft Press, McGraw-Hill. USA, 1997.

McConnell, Steve. Software project survival guide. Microsoft Press, McGrah-Hill. USA,
1998.

Phillips, Dwayne. The software project manager’s handbook. IEEE Computer Society Press.
USA, 1998.

Phillips, Dwayne. People, process, and product.
http://members.aol.com/dwaynephil/CutterPapers/ppp/ppp.htm . Visited August 2003.


3 CAPABILITY MATURITY MODELS
3.1 SUMMARY

This chapter presents two international standard models for project development associated to
the Process and People components discussed so far. These are, respectively:

 The Software Capability Maturity Model;
 The People Capability Maturity Model

Both models are basic for project development success since are the result of many years of
experience of a number organisations.

In order to introduce both models, this chapter is started studying how an organisation should
mature each of the five elements. Discussion continues exploring the main features of both
aforementioned maturity models.

3.2 BACKGROUND

As it was seen in Sections 1.3 and 1.4, the five elements are fundamental for any IT project
development. These elements change once product/service element is changed. Hence,
building a more difficult product/service implies an increase of capacity for the other four
elements.

Increasing the capacity of the five elements requires an increasing of maturity for managing
each of them. If at the beginning of each project development there is not an agreement in a
set of developing steps, then the maturity for managing project issues is at its lowest level
(initial maturity level). At this level, a common terminology is probably known and shared
and project success depends on individual efforts and heroics.

If each time projects are developed a successful process is repeated, then there is a risk
reduction in the development and an increasing of success. Due to this, this level of maturity
is known as “repeated maturity level”.

On the other hand, if various developing activities and the processes of management are
formally defined, documented, and integrated, then the level of maturity is said to be “defined
maturity level”.

Moreover, if it is stressed the importance of quantitatively measuring the quality of
products/services delivered by each process setting quantitative goals for both
products/services as well as processes, then the level of maturity is called “managed maturity
level”.

At the fifth level of maturity, called “optimised maturity level”, the focus is on the continuous
process improvement pro-actively identifying its strengths and weakness, with the aim of
preventing the occurrence of defects. Here continuous improvement becomes institutionalised
into the development process. Instead of merely correcting defects as they are found, the main


aim at this level is to stall future defects and address the key to those defects by planning in
advance.

Next Figure is a graphic representation of levels. In this figure, it is seen that at the initial
level the products/services successfully developed are those having a low complexity,
meanwhile at optimised level, products/services successfully developed could have a higher
complexity.

People

Initial Maturity Level
Product/Service Information Repeated Maturity Level
Def ined Maturity Level
Managed Maturity Level
Optimized Maturity Level
Tools Process

Figure 6. Maturity levels representation.

The set of maturity levels for software processes in an organisation is known as “Software
Capability Maturity Model (S-CMM)”. This model has been developed by the Software
Engineering Institute (SEI) and is discussed in Section 2.2. It is important to notice that S-
CMM has only been developed for software projects and not for any IT project.

As well, SEI has developed a framework for improving the way in which an organisation
manages its human assets known as “People Capability Maturity Model (P-CMM)”.This
model is discussed in Section 2.3.

3.3 CMM FOR SOFTWARE
3.3.1 THE SOFTWARE PROJECT DEVELOPMENT PROCESS

Before starting discussion, the term “process” must be defined in a software development
context. Process defines a way to do a project, projects typically produce a product (software),
and product is something that is produced for a co-worker, an employer, or a customer.

This definition can now be used to achieve project success. To do that, a three-step strategy
will be followed:

 Analyse the current process by which the organisation executes its projects;
 Figure out the strengths and weaknesses of the current process;
 Improve upon the process’s strengths and remove its weaknesses.

The above seemingly simple steps have baffled the software industry for years. Different
software organisations have adopted different techniques to implement the three-step recipe,
with varying degree of success. The problem now is trying to interpret and master this “three-
step approach to success”.

Consider the normal course of steps that follow when a software project is undertaken. Details
of these steps will only be outlined, without going into the details of each; since the purpose is
to highlight the most common events and not their particular details, as they may vary
depending on the nature of the project (see next Table).

Table 8. Steps for developing a software project.

STEP ACTIVITIES
 Client gives a set of product requirements to the organisation
 Organisation discusses these requirements with client
1. REQUIREMENTS  Discussion is focused on removing any ambiguity, conflict, or any other
issues related to the product/service in question
 The outcome of this discussion is ideally a “well-defined set of
functionalities that the product will achieve”
 Organisation should estimate and allocate both human and non-human
2. PLANNING (COST AND TIME resources
ESTIMATES)  Various milestones are defined to facilitate project monitoring
 Plans are also made to outsource any part of the project
3. ON WITH THE PROJECT Organisation is ready to start actual work on the project
Organisation continuously monitors the project progress against plans and
4. CONTINUOUS MONITORING
milestones made in Step 2
5. SUB-CONTRACTORS Sub-contractors (if any) are managed and their progress monitored closely in
CONTINUOUS MONITORING order to ensure that no delays occur due to lapses caused by them
6. SOFTWARE QUALITY Organisation ensures that no work is done in violation of any standard and any
ASSURANCE system requirements
 Organisation ensures that all bits-and-pieces of the project remain well
coordinated
7. CHANGE MANAGEMENT  Organisation determines if a change made to one piece of the product also
requires a change to one or more other pieces, and if it does then those
changes must be made accordingly (this is called “Configuration
Management”)

It is obvious that the above mentioned activities are performed by almost all software
projects; then what is it that makes an organisation differs from another one? The answer is
simple: Not all the organisations observe the above steps with the same vigour. These steps
are all very simple to understand but extremely difficult to execute effectively.

The purpose of discussion so far was to appreciate the need for a road map that software
organisations can follow to produce quality software, with in budget and with in time. One
such roadmap is called Capability Maturity Model for Software (S-CMM). It must be realised
that S-CMM is a tricky model to fully understand and is even trickiest to successfully
implement.

3.3.2 S-CMM COMPONENTS

S-CMM is the outcome of decades of research and study of successful and unsuccessful
projects. The major philosophy of S-CMM is very similar to life itself. When a child is born it
is at a very "initial" level of maturity. The child grows up, learns and attains a higher level of
maturity. This keeps on going until he/she becomes a fully mature adult; and even after that,

the learning goes on. According to S-CMM, a software organisation also goes (or should go)
through similar maturity evolutions. It should be noticed that S-CMM is NOT a software
development life cycle model. Instead it is a strategy for improving the software process
irrespective of the actual life-cycle model used.

Given below is a brief explanation of various components of S-CMM. This explanation has
been extracted from SEI's official documents.

Table 9. Some S-CMM components.

COMPONENT EXPLANATION
MATURITY It is a well-defined evolutionary plateau toward achieving a mature software process. The
LEVEL five maturity levels provide the top-level structure of the S-CMM
SOFTWARE It describes the range of expected results that can be achieved by following a software
PROCESS process. It provides one means of predicting the most likely outcomes to be expected from
CAPABILITY the next software project
Each maturity level is composed of its own KPAs. Each KPA identifies a cluster of related
KEY PROCESS activities that, when performed collectively, achieve a set of goals considered important for
AREAS (KPAS) establishing process capability at that maturity level. For example, one of the KPAs for level
2 is “Software Project Planning”
Goals summarise the key practices of a KPA and can be used to determine if a project has
effectively implemented the KPA. Goals signify the scope, boundaries, and intent of each
GOALS
KPA. An example of a goal from the Software Project Planning KPA is "Software estimates
are documented for use in planning and tracking the software project"
The key practices are divided among five Common Features parts:
 Commitment to perform
 Ability to perform
 Activities performed
COMMON  Measurement and analysis
FEATURES
 Verifying implementation
These are attributes that indicate whether the implementation and institutionalisation of a
KPA is effective, repeatable, and lasting. The Activities Performed common feature
describes implementation activities. Other four ones describe the institutionalisation factors,
which make a process part of the organisational culture
Each KPA is described in terms of key practices that, when implemented, help to satisfy the
KEY PRACTICES goals of that KPA. Key practices describe the infrastructure and activities that contribute
most to the effective implementation and institutionalisation of the KPA

3.3.3 S-CMM FRAMEWORK

S-CMM is a framework that characterises an evolutionary process improvement path toward a
more mature organisation. An organisation can use S-CMM to determine their current state of
software process maturity and then to establish priorities for improvement. An organisation's
current state of maturity can be categorised as Initial, Repeatable, Defined, Managed, or
Optimised. Therefore, S-CMM defines five levels of maturity (see next Table and Figure)


Table 10. S-CMM levels.

LEVEL DESCRIPTION
Software process is characterised as ad hoc and occasionally even chaotic. Few process
1. INITIAL
are defined and success depends on individual effort
Basic project management processes are established to track cost, schedule, and
2. REPEATABLE functionality. The necessary process discipline is in place to repeat earlier success on
projects with similar applications
Software process for both management and engineering activities is documented,
standardised, and integrated into a standard software process for the organisations. All
3. DEFINED
projects use an approved, tailored version of the organisation's standard process for
developing and maintaining software
Detailed measures of software process and product quality are collected. Both software
4. MANAGED
process and products are quantitatively understood and controlled
Continuous process improvement is enabled by quantitative feedback from the process
5. OPTIMISED
and from piloting innovative ideas and technologies

Continuously 5.Optimised
Improving Focus on process
Process improvement
4. Managed
Predictable Managing
Process measured
Process Change
and controlled
Standard,
3. Defined
Consistent Product and
Process Process characterised,
Process Quality
fairly well understood
Disciplined 2. Repeatable
Integrated
Process Can repeat previously
Engineering
mastered tasks
Process
1. Initial
Project
Unpredictable and
Management
poorly controlled

Figure 7. The five levels of software process maturity.

Each maturity level has been decomposed into constituent parts. With the exception of level
1, decomposition of each maturity level ranges from abstract summaries of each level down to
their operational definition in the key practices, as shown in next Figure. Each maturity level
is composed of several KPAs. Each KPA is organised into five parts called Common
Features. Common features specify the Key Practices that, when collectively addressed,
accomplish the goals of the KPA.


Maturity Levels
Indicate
Process Contain
capability
Achieve
Key Process Areas
Organised by
Goals
Common
Address Features
Implementation or Contain
institutionalisation
Key
Describe Practices
Infrastructure or
Activities

Figure 8. S-CMM structure.

The above discussion may produce some confusion. S-CMM is a vast subject, and a few lines
cannot even begin to explain it. However, in order to understand it, the rest of this section
further breaks the above levels down according the S-CMM structure.

3.3.4 KEY PROCESS AREAS (KPAS)

Each level has been divided into certain KPAs. For an organisation to achieve a certain
maturity level it must fulfil all the corresponding KPAs. Since every organisation is at least at
level 1, there are no KPAs for level 1. This means that an organisation does not need to do
anything to be at level 1. KPAs may be thought as a task list that must be performed. A KPA
contains a group of common activities an organisation must perform to fully address that
KPA. Given below is the list of KPAs for each maturity level.

Table 11. S-CMM KPAs.

LEVEL KEY PROCESS AREAS
1. INITIAL No KPAs
a. Software Requirement Management
b. Software Project Planning
c. Software Project Tracking & Oversight
2. REPEATABLE
d. Software Sub-Contract Management
e. Software Quality Assurance
f. Software Configuration Management
a. Organisational Process Focus
b. Organisational Process Definition
c. Training Program
3. DEFINED d. Integrated Software Management
e. Software Product Engineering
f. Inter-Group Co-ordination
g. Peer Review
a. Quantitative Process Management
4. MANAGED
b. Software Quality Management
a. Defect Prevention
5. OPTIMISED b. Technology Change Management
c. Process Change Management


Therefore, there are 18 KPAs in S-CMM. What S-CMM tells by virtue of the above KPAs is:
For an organisation to level with the best, it MUST address all the 18 KPAs. Failing to
address one or more of the above KPAs would result in a relatively immature organisation,
hence resulting in a decreased productivity and increased risk.

3.3.5 GOALS

Looking at the KPAs, the only way an organisation can be sure that it has successfully
addressed a KPA is achieving ALL the goals associated with that KPA. Given below is the
complete list of GOALS associated to each of the above 18 KPAs.

Table 12. Goals for each KPA.

KPA GOAL
LEVEL 2: REPEATABLE
 Goal 1: System requirements allocated to software are controlled to establish a baseline
Software for software engineering and management use
Requirement
Management  Goal 2: Software plans, products, and activities are kept consistent with the system
requirements allocated to software
 Goal 1: Software estimates are documented for use in planning and tracking the
software project
Software Project
 Goal 2: Software project activities and commitments are planned and documented
Planning
 Goal 3: Affected groups and individuals agree to their commitments related to the
software project
 Goal 1: Actual results and performances are tracked against the software plans
Software Project  Goal 2: Corrective actions are taken and managed to closure when actual results and
Tracking & performance deviate significantly from the software plans
Oversight  Goal 3: Changes to software commitments are agreed to by the affected groups and
individuals
 Goal 1: The prime contractor selects qualified software subcontractors
 Goal 2: The prime contractor and the software subcontractor agree to their commitments
Software Sub- to each other
Contract  Goal 3: The prime contractor and the software subcontractor maintain ongoing
Management communications
 Goal 4: The prime contractor tracks the software subcontractor's actual results and
performance against its commitments
 Goal 1: Software quality assurance activities are planned
 Goal 2: Adherence of software products and activities to the applicable standards,
procedures, and requirements is verified objectively
Software Quality
Assurance  Goal 3: Affected groups and individuals are informed of software quality assurance
activities and results
 Goal 4: Non-compliance issues that cannot be resolved within the software project are
addressed by senior management
 Goal 1: Software configuration management activities are planned
Software  Goal 2: Selected software work products are identified, controlled, and available
Configuration  Goal 3: Changes to identified software work products are controlled
Management
 Goal 4: Affected groups and individuals are informed of the status and content of
software baselines


LEVEL 3: DEFINED
 Goal 1: Software process development and improvement activities are coordinated
across the organisation
Organisational
 Goal 2: The strengths and weaknesses of the software processes used are identified
Process Focus
relative to a process standard
 Goal 3: Organisation-level process development and improvement activities are planned
 Goal 1: A standard software process for the organisation is developed and maintained
Organisational
Process Definition  Goal 2: Information related to the use of the organisation's standard software process by
the software projects is collected, reviewed, and made available
 Goal 1: Training activities are planned
 Goal 2: Training for developing the skills and knowledge needed to perform software
Training Program management and technical roles is provided
 Goal 3: Individuals in the software engineering group and software-related groups
receive the training necessary to perform their roles
 Goal 1: The project's defined software process is a tailored version of the organisation's
Integrated standard software process
Software
Management  Goal 2: The project is planned and managed according to the project's defined software
process
 Goal 1: The software engineering tasks are defined, integrated, and consistently
Software Product performed to produce the software
Engineering
 Goal 2: Software work products are kept consistent with each other
 Goal 1: The customer's requirements are agreed to by all affected groups
Inter-Group Co-  Goal 2: The commitments between the engineering groups are agreed to by the affected
ordination groups
 Goal 3: The engineering groups identify, track, and resolve intergroup issues
 Goal 1: Peer review activities are planned
Peer Review
 Goal 2: Defects in the software work products are identified and removed
LEVEL 4: MANAGED
 Goal 1: The quantitative process management activities are planned
Quantitative  Goal 2: The process performance of the project's defined software process is controlled
Process quantitatively
Management  Goal 3: The process capability of the organisation's standard software process is known
in quantitative terms
 Goal 1: The project's software quality management activities are planned
Software Quality  Goal 2: Measurable goals for software product quality and their priorities are defined
Management  Goal 3: Actual progress toward achieving the quality goals for the software products is
quantified and managed
LEVEL 5: OPTIMISED
 Goal 1: Defect prevention activities are planned
Defect Prevention  Goal 2: Common causes of defects are sought out and identified
 Goal 3: Common causes of defects are prioritised and systematically eliminated
 Goal 1: Incorporation of technology changes are planned
Technology  Goal 2: New technologies are evaluated to determine their effect on quality and
Change productivity
Management  Goal 3: Appropriate new technologies are transferred into normal practice across the
organisation


 Goal 1: Continuous process improvement is planned
 Goal 2: Participation in the organisation's software process improvement activities is
Process Change
organisation wide
Management
 Goal 3 The organisation's standard software process and the projects' defined software
processes are improved continuously

3.3.6 COMMON FEATURES

KPAs are organised by “common features”. These are attributes that indicate whether the
implementation and institutionalisation of a KPA is effective, repeatable, and lasting. The five
common features are listed below.

Table 13. Common features description.

COMMON FEATURES DESCRIPTION
It describes actions the organisation must take to ensure that the process is
COMMITMENT TO
established and will endure. It typically involves establishing organisational
PERFORM
policies and senior management sponsorship
It describes the preconditions that must exist in the project or organisation to
ABILITY TO PERFORM implement the software process competently. It typically involves resources,
organisational structures, and training
It describes the roles and procedures necessary to implement a KPA. It
ACTIVITIES
typically involve establishing plans and procedures, performing the work,
PERFORMED
tracking it, and taking corrective actions as necessary
It describes the need to measure the process and analyse the measurements. It
MEASUREMENT AND
typically includes examples of the measurements that could be taken to
ANALYSIS
determine the status and effectiveness of the Activities Performed
It describes the steps to ensure that the activities are performed in compliance
VERIFYING
with the process that has been established. It typically encompasses reviews
IMPLEMENTATION
and audits by management and software quality assurance

The practices in the Activities Performed common feature describe what must be
implemented to establish a process capability. The other practices, taken as a whole, form the
basis by which an organisation can institutionalise the practices described in the Activities
Performed common feature.

3.3.7 KEY PRACTICES

Each KPA is described in terms of the key practices that contribute to satisfying its goals. The
key practices describe the infrastructure and activities that contribute most to the effective
implementation and institutionalisation of the KPA.

Each key practice consists of a single sentence, often followed by a more detailed description,
which may include examples and elaboration. These key practices, also referred to as the top-
level key practices, state the fundamental policies, procedures, and activities for the KPA. The
components of the detailed description are frequently referred to as subpractices. Next Figure
provides an example of the structure underlying a key practice for the Software Project
Planning KPA.


Maturity level:
Maturity level:
2, Repeatable
2, Repeatable

Indicates Contains

Process capability: KPA:
KPA:
Disciplined process Software project planning
Software project planning
Achieves Organised by

Goal 1:
Software estimates are Common feature:
documented for use in Common feature:
Activities performed
Activities performed
planning and tracking the
software project
Address Contains

Key practice:
Key practice:
Implementation or Activity 9. Estimates for the size of the
Activity 9. Estimates for the size of the
institutionalisation: software work products (or changes to the
software work products (or changes to the
Implementation size of software work products) are derived
size of software work products) are derived
according to aadocumented procedure
according to documented procedure
Describes

Infrastructure or
activities:
Activity

Figure 9. Example of a key practice.

3.3.8 S-CMM IN ORGANISATIONS

Many organisations have successfully implemented S-CMM, and have reported considerable
improvement in almost all the aspects of software life cycle. Some of these organisations are:
Bull HN, GTE Government Systems, Hewlett Packard, Hughes Aircraft Co., Loral Federal
Systems (formerly IBM Federal Systems Company), Lockheed Sanders, Motorola, Northrop,
Schlumberger, Siemens Stromberg-Carlson, Texas Instruments, United States Air Force
Oklahoma City Air Logistics Centre , United States Navy Fleet Combat Direction Systems
Support Activity.

Fundamentally speaking S-CMM helps an organisation in two ways:

 S-CMM instils definite practices, resulting in an increase in profitability;
 It brings and immediate change in an organisation's culture and mentality, thereby
helping it to climb up the S-CMM ladder.

Among some 900 plus organisations, which contribute their assessment data to the SEI, a
majority of them fall within level 1 and level 2, the percentages being 34.9 and 38.2
respectively.

However, the journey to reach a higher level of process maturity requires a considerable
amount of time and effort. The S-CMM-based enhancement effort that organisations initiated
in 1992 and later has shown that the time to move from one level to the next averaged as
follows:

 From level 1 to level 2: 25 months;
 From level 2 to level 3: 22 months;
 From level 3 to level 4: 36.5 months.

The illustration below shows the number of organisations which have qualified for Level 4
and Level 5 as on October 2002.


Table 14. S-CMM level 4 and 5 organisations.

NUMBER OF S-CMM LEVEL 4 NUMBER OF S-CMM LEVEL 5
COUNTRY
ORGANISATIONS ORGANISATIONS
AUSTRALIA 2
CANADA 1
CHINA 2
FRANCE 1
INDIA 27 50
IRELAND 1
ISRAEL 1
RUSSIA 1
SINGAPORE 1
USA 39 20

The advantages of moving up the S-CMM ladder are evident in a large number of
organisations. Upgrading to each higher level is accompanied by an improvement in the
overall performance level of the organisation. Some of S-CMM's major plus points include:

 A shift from re-active to pro-active management;
 Helps build a skilled and motivated workforce;
 Cuts cost in development and support system;
 Shortens delivery schedules and improves delivery of requirements;
 Results in customer satisfaction;
 Improves quality of software products;
 Induces robustness;
 Improves management decision-making;
 Introduces newer technology thus creating competitive advantages.

S-CMM levels are like a prescription provided by a doctor. Just as standards in life have to be
followed to improve the overall quality of life, similarly following the key process criteria of
the S-CMM helps an organisation to improve its overall health and prosperity. The scaling up
of each level enhances the performance and core competency of the organisation significantly.

It helps to improve the growth of software engineering from an ad-hoc level to a disciplined
and managed level and is well supported by up to date technology. In addition to this it is
advantageous for an organisation to achieve the maturity level from a purely business point of
view.

According to reports, when S-CMM is applied properly, it can (see also next Table):

 Improve productivity three-fold;
 Improvement in time-to-market by 0-70%;
 Decrease in product defects by 90%.


Table 15. Percent improvement compared with results at previous levels.

CRITERIA LEVEL 1 - 2 LEVEL 2 - 3 LEVEL 3 - 4
REDUCE DEFECTS 12% 40% 85%
REDUCE CYCLE TIME 10% 38% 63%
REDUCE COST 8% 35% 75%
SCHEDULE VARIANCE 145% 24% 15%

S-CMM by itself does not guarantee that the work done will be outstanding and successful. It
rather makes sure that the practicing organisations work in an orderly manner thereby
implying that results will be predictable.

Through practicing the S-CMM process, an organisation can reach new heights and look
forward to the sky as its limit.

3.3.9 CONCLUSION

It can be concluded that S-CMM helps in judging the software processes of an organisation as
well as identifying the pre-requisites necessary to enhance the overall maturity level of these
processes.

It furthermore points the way down a well-defined path to improve the management and
development of software products in a disciplined and orderly way.

Applied in a proper manner, S-CMM is indeed a powerful system, which can help transform
an IT organisation and help it to reach its pinnacle.

3.4 CMM FOR PEOPLE
3.4.1 BACKGROUND

Every employee in an organisation has an impact on the quality of the product/service. It is
imperative that the level of employee development reflects the quality expectations placed on
each and every employee. Since well-trained and competent employees are a strategic
advantage for an organisation, it is sensible for an organisation to take a strategic approach to
their training activities.

The People Capability Maturity Model (P-CMM) was also developed by the Software
Engineering Institute (SEI) of Carnegie-Mellon University in Pennsylvania.

The SEI collaborated with representatives from industry, government, military, and academic
organisations to develop an evolutionary model intended to develop and optimise employee
training and competence in organisations.

3.4.2 THEMES

P-CMM defines success in terms of an organisation’s “maturity”. The structure of P-CMM
demonstrates how an organisation can progress sequentially through increasing levels of
maturity to a summit of optimal performance.

There are five defined maturity levels in the P-CMM:

Table 16. P-CMM levels.

LEVEL DESCRIPTION
1. INITIAL No processes initiated
Processes focus on establishing basic workforce practices and eliminating problems that
2. REPEATABLE
hinder work performance. The intent is to instil basic discipline into workforce activities
Processes address organisational issues, as the organisation tailors its defined workforce
3. DEFINED practices to the core competencies required by its business environment. The intent is to
identify primary competencies and align workforce activities with these competencies
Processes focus on building competency-based teams and establishing a quantitative
understanding of trends in the development of knowledge and skills and in the alignment
4. MANAGED of performance across different levels of the organisation. The intent is to quantitatively
manage organisational growth in workforce capabilities and establish competency-based
teams
Processes cover issues that both the organisation and individuals must address in
5. OPTIMISED implementing continuous improvements in their capability. The intent is to continuously
improve methods for developing personal and organisational competence

There are relationships which link the maturity levels so that progress can occur on a set path.
Through these themes, the implementation of processes at one maturity level can serve as a
foundation for practices and capabilities at a higher level. The Themes of the P-CMM are:

Table 17. P-CMM Themes.

THEMES DESCRIPTION
The trend starts with identifying current training needs within a unit, progresses to the
DEVELOPING identification of core competencies developed by the organisation, and evolves to
CAPABILITIES having individuals being able to establish their own program of professional
development
The trend in building teams and culture begins with establishing basic communication
BUILDING TEAMS
skills, grows to developing a participatory culture, and continues on into formal team-
AND CULTURE
building and continuous improvement of team capabilities
The trend in motivating and managing performance begins with establishing basic
MOTIVATING AND
performance management and compensation practices, then improves these practices
MANAGING
through adaptation to competency development and team building. From this level,
PERFORMANCE
the trend optimises by looking for constant sources of innovation
The trend in shaping the workforce begins with establishing basic staffing practices,
SHAPING THE
grows to developing plans for workforce development, sets and tracks objectives for
WORKFORCE
competencies in the workforce, and then looks for constant sources of innovation

3.4.3 KEY PROCESS AREAS (KPAS)

KPAs refer to the particular tasks and activities which must be completed in order for an
organisation to gain maturity and progress towards optimising their training initiatives. The
following Table identifies the appropriate KPA necessary to address each of the four Themes
of the P-CMM, and allow the organisation to mature.


Table 18. KPA necessary to address each of the four Themes of the P-CMM.

MATURITY THEME 3:
LEVELS THEME 1: THEME 2: THEME 4:
MOTIVATING AND
DEVELOPING BUILDING TEAMS SHAPING THE
PROCESS MANAGING
CAPABILITIES AND CULTURE WORKFORCE
CATEGORIES PERFORMANCE

Coaching
LEVEL 5:
Personal Competency Continuous Workforce Innovation
OPTIMISED
Development
Organisational
Performance Organisational
LEVEL 4: Alignment
Mentoring Team Building Competency
MANAGED
Team-Based Management
Practices
Competency Competency-Based
LEVEL 3: Development Participatory Practices Workforce
DEFINED Knowledge and Culture Career Planning
Skills Analysis Development
Compensation
LEVEL 2: Training Performance
Communication Staffing
REPEATABLE Communication Management
Work Environment
LEVEL 1:
No process categories
INITIAL

3.4.4 IMPLEMENTATION

Implementation of the P-CMM requires support and approval from the different areas of an
organisation. This model will not be effective if it is imposed or forced on department. Since
the model is generic in nature, it has to be interpreted and customised in order to make it
appropriate to the nature of the organisation.

This model was designed to impart benefits at every maturity level. It does not benefit an
organisation to skip a level, or to disregard the processes characteristic of an early maturity
level. The outputs of each level serve as the foundation for the practices of subsequent
maturity levels. This is best described through the four Themes of the model.

To aid with the interpretation and the implementation of this model in an organisation, the P-
CMM has identified the following acceptance criteria for each KPA:

 Goals;
 Commitments to perform;
 Abilities to perform;
 Activities performed;
 Measurement and analysis;
 Verification of implementation.

As an example, this is the breakdown for KPA: Training


Table 19. Example for the Training KPA.

COMMITMENTS ABILITIES TO ACTIVITIES MEASUREMENT VERIFICATION OF
GOALS
TO PERFORM PERFORM PERFORMED AND ANALYSIS IMPLEMENTATION
A responsible
Within each
Critical Measurements individual(s)
unit, an
Training in Organisation skills are made and verifies that
individual(s) is
the critical follows a required for used to training activities
assigned
skills documented performing determine the are conducted
responsibility
required in policy for its critical tasks status of according to the
for ensuring
each unit is training are training unit’s plan and the
that training
provided activities identified in activities within organisation’s
activities are
each unit each unit documented
conducted
policies
An Executive
Individuals organisational Adequate Unit measures management
receive role(s) is resources and of training periodically
timely assigned funding are The training status are reviews the
training that responsibility provided for needs for collected and organisation’s
is needed to for assisting implementing each unit are aggregated at training activities
perform and advising the planned identified the to determine if
their units on training organisational they comply with
assignments training activities level its documented
activities policies
Training time
is made Each unit
Training
available to develops and
opportunities
each maintains a
are made
individual plan for
available to
according to satisfying its
all
the training
individuals
organisation’s needs
training policy
Individuals
Individuals
and/or
responsible for
groups
identifying
receive the
training needs
training they
are trained in
need to
methods
perform
relevant to
their
their
assigned
responsibilities
tasks
Individuals Relevant
developing or training
providing opportunities
training have are
the necessary identified
training and/or and made
experience available to
required to support each
perform their individual’s
responsibilities development
Training is
tracked
against the
unit’s
training plan


In order to aid in the interpretation and implementation, P-CMM provides similar descriptions
for each KPA in a thorough and detailed manner. The application of this system is intended as
a guideline for organisations.

The development of employees into productive and strategic assets is a worthwhile initiative
that can bestow great rewards for an organisation. To achieve these rewards, an organisation
should examine the various processes and activities outlined in the P-CMM, and determine an
applicable and appropriate strategy to optimise employee performance.

3.5 BIBLIOGRAPHICAL REFERENCES

Bardoloi, Sabyasachi. Quality: A Health Capsule to Retain Growth. Pinnacle Systems, Inc.
ftp://projectperfect.com.au/CMM.pdf. Visited August 2003.

Curtis, Bill, William E. Hefley, and Sally A. Miller. People Capability Maturity Model® (P-
CMM®), Version 2.0. CMU/SEI-2001-MM-01. July 2001. www.sei.cmu.edu. Visited
August 2003.

Hefley, William E. Where Does Team Building Fit As A Component of Mature Software
Development Processes? http://hsb.baylor.edu/ramsower/ais.ac.96/papers/hefley2.htm.
Visited August 2003.

Manzoor, Kashif. CMM – an introduction.
http://homepages.com.pk/kashman/CMMIntro.htm. Visited August 2003.

Paulk, Mark C. Using the Software CMM in small organizations. 1998. www.sei.cmu.edu.
Visited August 2003.

Paulk, Mark C., Bill Curtis, Mary Beth Chrissis, and Charles V. Weber. Capability Maturity
Model for Software, Version 1.1. Technical Report CMU/SEI-93-TR-024 ESC-TR-93-
177. www.sei.cmu.edu. February 1993.

Paulk, Mark C., Bill Curtis, Mary Beth Chrissis, and Charles V. Weber. The Capability
Maturity Model for Software. www.sei.cmu.edu. February 1993.

Zrymiak, Dan. People - Capability Maturity Model. http://www.msi.ms/MSJ/People-
Capability_Maturity_Model.htm. Visited August 2003.


IT Project Development Fundamentals

IT Project Development Fundamentals

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à IT Project Development Fundamentals

Similaire à IT Project Development Fundamentals (20)

Plus de Universidad Tecnológica de México - UNITEC

Plus de Universidad Tecnológica de México - UNITEC (20)

IT Project Development Fundamentals