it project development fundamentals
DESCRIPTION
TRANSCRIPT
August 2004 Page 1 of 39
INFORMATION TECHNOLOGY PROJECT DEVELOPMENT
FUNDAMENTALS1
ALEJANDRO DOMÍNGUEZ-TORRES
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 2 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
3.5 BIBLIOGRAPHICAL REFERENCES ......................................................................................................... 34
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
4.5 BIBLIOGRAPHICAL REFERENCES ......................................................................................................... 39
August 2004 Page 3 of 39
August 2004 Page 4 of 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
August 2004 Page 5 of 39
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
August 2004 Page 6 of 39
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.
August 2004 Page 7 of 39
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.
Fully Satisfied Not Satisfied
Not Applicable Not Rated
Fully Satisfied Not Satisfied
Not Applicable Not Rated
Configuration management
Software quality assurance
Software subcontract management
Invalid
gridProject tracking and oversight
Invalid
gridProject planning
Invalid
grid
Invalid
gridRequirements management
Goal 4Goal 3Goal 2Goal 1Repeatable KPAs
Configuration management
Software quality assurance
Software subcontract management
Invalid
gridProject tracking and oversight
Invalid
gridProject planning
Invalid
grid
Invalid
gridRequirements management
Goal 4Goal 3Goal 2Goal 1Repeatable KPAs
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)
August 2004 Page 8 of 39
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
August 2004 Page 9 of 39
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
1.1 IT PROJECT DEVELOPMENT Discusses IT project development as part of the delivery of IT services and
functions
1.2 IT PROJECT DEVELOPMENT
ELEMENTS
Presents the five major elements of IT project development as a foundation
for the specification of standard practices and procedures
1.3 THE RELATIONSHIP OF THE
FIVE ELEMENTS
Shows the relationship among elements and how changes in one element
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
FEASIBILITY STUDIES The evaluation of IT and its use in an organisation, which may include the selection
of IT solutions and recommendations for future strategies
IT DEVELOPMENT The design, testing, integration, and implementation of customised IT applications,
and related platforms and interfaces
IT UPGRADE The upgrade of existing IT platforms, solutions, and products
IT MIGRATION The replacement and/or removal of existing IT platforms and solutions; typically
replaced by different products
SUPPORT SERVICES The participation of IT as a change agent; it includes office renovations, relocations,
organisation mergers, training programs, and internal reorganisations
IT MANAGEMENT Relate to the improvement of IT performance and service delivery; it includes IT
process re-engineering, maintenance, security audits, and documentation projects
August 2004 Page 10 of 39
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;
August 2004 Page 11 of 39
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;
August 2004 Page 12 of 39
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
PROJECT SPONSOR Who takes the lead in getting the need for the project recognition as well
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
ENTITIES
Who are responsible for manage project configuration within the
boundaries of the project
QUALITY ASSURANCE TEAMS Who verify the ability of the product/service to meet the stated necessary
requirements
ORGANISATIONAL PROCUREMENT
PERSONNEL Who assist in procuring project resources
CUSTOMER Who is the person(s) or organisation(s) using the product/service of the
project
August 2004 Page 13 of 39
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
IMPROVEMENT
It is the key to increasing the ability to produce IT
There must have a process before it can be improved
RIGHT
PROCESS USE
There are different and useful process models
A good and standard processes models are “The Software Capability Maturity Model (S-
CMM)”, and “The Capability Maturity Model for People (P-CMM)”
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?
August 2004 Page 14 of 39
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
FORMAL INFORMATION It is produced by standard procedures, is objective and is generally regarded as
relevant to a decision
INFORMAL INFORMATION
This is often subjective, passed by word mouth, and involves hunches, opinions,
guesstimates and rumour. It generally involves explanatory and/or evaluative
information
August 2004 Page 15 of 39
Formal information: usually quantitative,
produced by known rules, objective
Informal information: usually qualitative,
no produced by known rules, subjective
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
OBJECTIVES
What will product/service accomplish and what role will software, training,
templates, and communication play in product/service delivery and execution?
PROJECT AND
ORGANISATIONAL
CHARACTERISTICS
Software tools must match project characteristics and requirements, including
size, duration, task complexity, reporting, resource allocations and the need to
manage multiple projects across an organisation
TECHNICAL CAPABILITIES
It must be considered the capacities and characteristics of the current technical
environment. These considerations may include, but are not limited, to
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
CURRENT TECHNOLOGICAL
PLATFORMS
To fully assess technical compatibility, it will be needed detailed information
on platform configurations, capacities and structural limitations, as well as the
corresponding requirements for the products and toolsets to be considered
August 2004 Page 16 of 39
STAFF SKILL AND RESOURCE
AVAILABILITY
IT project development may require some degree of maintenance and
administration. These requirements must be considered when evaluating skill
levels and resource availability
COST TO PURCHASE AND
MAINTAIN
When considering the selection and deployment of project development tools,
thought must be given to the costs of testing, evaluation, acquisition,
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
Information
ProcessTools
Product/Service
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.
August 2004 Page 17 of 39
People
Information
ProcessTools
Product/Service
Figure 3. Building a more difficult product/service by increasing capability from people.
People
Information
ProcessTools
Product/Service
Figure 4. Building a more difficult product/service by increasing capability from process.
People
Information
ProcessTools
Product/Service
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
August 2004 Page 18 of 39
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.
August 2004 Page 19 of 39
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
August 2004 Page 20 of 39
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
Information
ProcessTools
Product/Service
Initial Maturity Level
Repeated Maturity Level
Def ined Maturity Level
Managed Maturity Level
Optimized Maturity Level
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”.
August 2004 Page 21 of 39
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
1. REQUIREMENTS
Client gives a set of product requirements to the organisation
Organisation discusses these requirements with client
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”
2. PLANNING (COST AND TIME
ESTIMATES)
Organisation should estimate and allocate both human and non-human
resources
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
4. CONTINUOUS MONITORING Organisation continuously monitors the project progress against plans and
milestones made in Step 2
5. SUB-CONTRACTORS
CONTINUOUS MONITORING
Sub-contractors (if any) are managed and their progress monitored closely in
order to ensure that no delays occur due to lapses caused by them
6. SOFTWARE QUALITY
ASSURANCE
Organisation ensures that no work is done in violation of any standard and any
system requirements
7. CHANGE MANAGEMENT
Organisation ensures that all bits-and-pieces of the project remain well
coordinated
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,
August 2004 Page 22 of 39
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
LEVEL
It is a well-defined evolutionary plateau toward achieving a mature software process. The
five maturity levels provide the top-level structure of the S-CMM
SOFTWARE
PROCESS
CAPABILITY
It describes the range of expected results that can be achieved by following a software
process. It provides one means of predicting the most likely outcomes to be expected from
the next software project
KEY PROCESS
AREAS (KPAS)
Each maturity level is composed of its own KPAs. Each KPA identifies a cluster of related
activities that, when performed collectively, achieve a set of goals considered important for
establishing process capability at that maturity level. For example, one of the KPAs for level
2 is “Software Project Planning”
GOALS
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
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"
COMMON
FEATURES
The key practices are divided among five Common Features parts:
Commitment to perform
Ability to perform
Activities performed
Measurement and analysis
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
KEY PRACTICES
Each KPA is described in terms of key practices that, when implemented, help to satisfy the
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)
August 2004 Page 23 of 39
Table 10. S-CMM levels.
LEVEL DESCRIPTION
1. INITIAL Software process is characterised as ad hoc and occasionally even chaotic. Few process
are defined and success depends on individual effort
2. REPEATABLE
Basic project management processes are established to track cost, schedule, and
functionality. The necessary process discipline is in place to repeat earlier success on
projects with similar applications
3. DEFINED
Software process for both management and engineering activities is documented,
standardised, and integrated into a standard software process for the organisations. All
projects use an approved, tailored version of the organisation's standard process for
developing and maintaining software
4. MANAGED Detailed measures of software process and product quality are collected. Both software
process and products are quantitatively understood and controlled
5. OPTIMISED Continuous process improvement is enabled by quantitative feedback from the process
and from piloting innovative ideas and technologies
2. Repeatable
1. Initial
3. Defined
4. Managed
Disciplined
Process
Standard,
Consistent
Process
Predictable
Process
Continuously
Improving
Process
Unpredictable and
poorly controlled
Can repeat previously
mastered tasks
Process characterised,
fairly well understood
Process measured
and controlled
Focus on process
improvement
5.Optimised
Project
Management
Integrated
Engineering
Process
Product and
Process Quality
Managing
Change
2. Repeatable
1. Initial
3. Defined
4. Managed
Disciplined
Process
Standard,
Consistent
Process
Predictable
Process
Continuously
Improving
Process
Unpredictable and
poorly controlled
Can repeat previously
mastered tasks
Process characterised,
fairly well understood
Process measured
and controlled
Focus on process
improvement
5.Optimised
Project
Management
Integrated
Engineering
Process
Product and
Process Quality
Managing
Change
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.
August 2004 Page 24 of 39
Processcapability
Goals
Implementation orinstitutionalisation
Infrastructure orActivities
Maturity Levels
Key Process Areas
Common Features
Key Practices
Contain
Organised by
Contain
Indicate
Achieve
Address
Describe
Processcapability
Goals
Implementation orinstitutionalisation
Infrastructure orActivities
Maturity Levels
Key Process Areas
Common Features
Key Practices
Contain
Organised by
Contain
Indicate
Achieve
Address
Describe
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
2. REPEATABLE
a. Software Requirement Management
b. Software Project Planning
c. Software Project Tracking & Oversight
d. Software Sub-Contract Management
e. Software Quality Assurance
f. Software Configuration Management
3. DEFINED
a. Organisational Process Focus
b. Organisational Process Definition
c. Training Program
d. Integrated Software Management
e. Software Product Engineering
f. Inter-Group Co-ordination
g. Peer Review
4. MANAGED a. Quantitative Process Management
b. Software Quality Management
5. OPTIMISED
a. Defect Prevention
b. Technology Change Management
c. Process Change Management
August 2004 Page 25 of 39
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
Software
Requirement
Management
Goal 1: System requirements allocated to software are controlled to establish a baseline
for software engineering and management use
Goal 2: Software plans, products, and activities are kept consistent with the system
requirements allocated to software
Software Project
Planning
Goal 1: Software estimates are documented for use in planning and tracking the
software project
Goal 2: Software project activities and commitments are planned and documented
Goal 3: Affected groups and individuals agree to their commitments related to the
software project
Software Project
Tracking &
Oversight
Goal 1: Actual results and performances are tracked against the software plans
Goal 2: Corrective actions are taken and managed to closure when actual results and
performance deviate significantly from the software plans
Goal 3: Changes to software commitments are agreed to by the affected groups and
individuals
Software Sub-
Contract
Management
Goal 1: The prime contractor selects qualified software subcontractors
Goal 2: The prime contractor and the software subcontractor agree to their commitments
to each other
Goal 3: The prime contractor and the software subcontractor maintain ongoing
communications
Goal 4: The prime contractor tracks the software subcontractor's actual results and
performance against its commitments
Software Quality
Assurance
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
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
Software
Configuration
Management
Goal 1: Software configuration management activities are planned
Goal 2: Selected software work products are identified, controlled, and available
Goal 3: Changes to identified software work products are controlled
Goal 4: Affected groups and individuals are informed of the status and content of
software baselines
August 2004 Page 26 of 39
LEVEL 3: DEFINED
Organisational
Process Focus
Goal 1: Software process development and improvement activities are coordinated
across the organisation
Goal 2: The strengths and weaknesses of the software processes used are identified
relative to a process standard
Goal 3: Organisation-level process development and improvement activities are planned
Organisational
Process Definition
Goal 1: A standard software process for the organisation is developed and maintained
Goal 2: Information related to the use of the organisation's standard software process by
the software projects is collected, reviewed, and made available
Training Program
Goal 1: Training activities are planned
Goal 2: Training for developing the skills and knowledge needed to perform software
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
Integrated
Software
Management
Goal 1: The project's defined software process is a tailored version of the organisation's
standard software process
Goal 2: The project is planned and managed according to the project's defined software
process
Software Product
Engineering
Goal 1: The software engineering tasks are defined, integrated, and consistently
performed to produce the software
Goal 2: Software work products are kept consistent with each other
Inter-Group Co-
ordination
Goal 1: The customer's requirements are agreed to by all affected groups
Goal 2: The commitments between the engineering groups are agreed to by the affected
groups
Goal 3: The engineering groups identify, track, and resolve intergroup issues
Peer Review Goal 1: Peer review activities are planned
Goal 2: Defects in the software work products are identified and removed
LEVEL 4: MANAGED
Quantitative
Process
Management
Goal 1: The quantitative process management activities are planned
Goal 2: The process performance of the project's defined software process is controlled
quantitatively
Goal 3: The process capability of the organisation's standard software process is known
in quantitative terms
Software Quality
Management
Goal 1: The project's software quality management activities are planned
Goal 2: Measurable goals for software product quality and their priorities are defined
Goal 3: Actual progress toward achieving the quality goals for the software products is
quantified and managed
LEVEL 5: OPTIMISED
Defect Prevention
Goal 1: Defect prevention activities are planned
Goal 2: Common causes of defects are sought out and identified
Goal 3: Common causes of defects are prioritised and systematically eliminated
Technology
Change
Management
Goal 1: Incorporation of technology changes are planned
Goal 2: New technologies are evaluated to determine their effect on quality and
productivity
Goal 3: Appropriate new technologies are transferred into normal practice across the
organisation
August 2004 Page 27 of 39
Process Change
Management
Goal 1: Continuous process improvement is planned
Goal 2: Participation in the organisation's software process improvement activities is
organisation wide
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
COMMITMENT TO
PERFORM
It describes actions the organisation must take to ensure that the process is
established and will endure. It typically involves establishing organisational
policies and senior management sponsorship
ABILITY TO PERFORM
It describes the preconditions that must exist in the project or organisation to
implement the software process competently. It typically involves resources,
organisational structures, and training
ACTIVITIES
PERFORMED
It describes the roles and procedures necessary to implement a KPA. It
typically involve establishing plans and procedures, performing the work,
tracking it, and taking corrective actions as necessary
MEASUREMENT AND
ANALYSIS
It describes the need to measure the process and analyse the measurements. It
typically includes examples of the measurements that could be taken to
determine the status and effectiveness of the Activities Performed
VERIFYING
IMPLEMENTATION
It describes the steps to ensure that the activities are performed in compliance
with the process that has been established. It typically encompasses reviews
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.
August 2004 Page 28 of 39
Maturity level:
2, Repeatable
Maturity level:
2, Repeatable
KPA:
Software project planning
KPA:
Software project planning
Common feature:
Activities performed
Common feature:
Activities performed
Key practice:
Activity 9. Estimates for the size of the
software work products (or changes to the
size of software work products) are derived
according to a documented procedure
Key practice:
Activity 9. Estimates for the size of the
software work products (or changes to the
size of software work products) are derived
according to a documented procedure
Process capability:
Disciplined process
Goal 1:
Software estimates are
documented for use in
planning and tracking the
software project
Implementation or
institutionalisation:
Implementation
Infrastructure or
activities:
Activity
Indicates Contains
Achieves Organised by
Address Contains
Describes
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.
August 2004 Page 29 of 39
Table 14. S-CMM level 4 and 5 organisations.
COUNTRY NUMBER OF S-CMM LEVEL 4
ORGANISATIONS
NUMBER OF S-CMM LEVEL 5
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%.
August 2004 Page 30 of 39
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.
August 2004 Page 31 of 39
There are five defined maturity levels in the P-CMM:
Table 16. P-CMM levels.
LEVEL DESCRIPTION
1. INITIAL No processes initiated
2. REPEATABLE Processes focus on establishing basic workforce practices and eliminating problems that
hinder work performance. The intent is to instil basic discipline into workforce activities
3. DEFINED
Processes address organisational issues, as the organisation tailors its defined workforce
practices to the core competencies required by its business environment. The intent is to
identify primary competencies and align workforce activities with these competencies
4. MANAGED
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
of performance across different levels of the organisation. The intent is to quantitatively
manage organisational growth in workforce capabilities and establish competency-based
teams
5. OPTIMISED
Processes cover issues that both the organisation and individuals must address in
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
DEVELOPING
CAPABILITIES
The trend starts with identifying current training needs within a unit, progresses to the
identification of core competencies developed by the organisation, and evolves to
having individuals being able to establish their own program of professional
development
BUILDING TEAMS
AND CULTURE
The trend in building teams and culture begins with establishing basic communication
skills, grows to developing a participatory culture, and continues on into formal team-
building and continuous improvement of team capabilities
MOTIVATING AND
MANAGING
PERFORMANCE
The trend in motivating and managing performance begins with establishing basic
performance management and compensation practices, then improves these practices
through adaptation to competency development and team building. From this level,
the trend optimises by looking for constant sources of innovation
SHAPING THE
WORKFORCE
The trend in shaping the workforce begins with establishing basic staffing practices,
grows to developing plans for workforce development, sets and tracks objectives for
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.
August 2004 Page 32 of 39
Table 18. KPA necessary to address each of the four Themes of the P-CMM.
MATURITY
LEVELS
PROCESS
CATEGORIES
THEME 1:
DEVELOPING
CAPABILITIES
THEME 2:
BUILDING TEAMS
AND CULTURE
THEME 3:
MOTIVATING AND
MANAGING
PERFORMANCE
THEME 4:
SHAPING THE
WORKFORCE
LEVEL 5:
OPTIMISED
Coaching
Personal Competency
Development
Continuous Workforce Innovation
LEVEL 4:
MANAGED Mentoring Team Building
Organisational
Performance
Alignment
Team-Based
Practices
Organisational
Competency
Management
LEVEL 3:
DEFINED
Competency
Development
Knowledge and
Skills Analysis
Participatory
Culture
Competency-Based
Practices
Career
Development
Workforce
Planning
LEVEL 2:
REPEATABLE
Training
Communication Communication
Compensation
Performance
Management
Work Environment
Staffing
LEVEL 1:
INITIAL No process categories
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
August 2004 Page 33 of 39
Table 19. Example for the Training KPA.
GOALS COMMITMENTS
TO PERFORM
ABILITIES TO
PERFORM
ACTIVITIES
PERFORMED
MEASUREMENT
AND ANALYSIS
VERIFICATION OF
IMPLEMENTATION
Training in
the critical
skills
required in
each unit is
provided
Organisation
follows a
documented
policy for its
training
activities
Within each
unit, an
individual(s) is
assigned
responsibility
for ensuring
that training
activities are
conducted
Critical
skills
required for
performing
critical tasks
are
identified in
each unit
Measurements
are made and
used to
determine the
status of
training
activities within
each unit
A responsible
individual(s)
verifies that
training activities
are conducted
according to the
unit’s plan and the
organisation’s
documented
policies
Individuals
receive
timely
training that
is needed to
perform
their
assignments
An
organisational
role(s) is
assigned
responsibility
for assisting
and advising
units on
training
activities
Adequate
resources and
funding are
provided for
implementing
the planned
training
activities
The training
needs for
each unit are
identified
Unit measures
of training
status are
collected and
aggregated at
the
organisational
level
Executive
management
periodically
reviews the
organisation’s
training activities
to determine if
they comply with
its documented
policies
Training
opportunities
are made
available to
all
individuals
Training time
is made
available to
each
individual
according to
the
organisation’s
training policy
Each unit
develops and
maintains a
plan for
satisfying its
training
needs
Individuals
responsible for
identifying
training needs
are trained in
methods
relevant to
their
responsibilities
Individuals
and/or
groups
receive the
training they
need to
perform
their
assigned
tasks
Individuals
developing or
providing
training have
the necessary
training and/or
experience
required to
perform their
responsibilities
Relevant
training
opportunities
are
identified
and made
available to
support each
individual’s
development
Training is
tracked
against the
unit’s
training plan
August 2004 Page 34 of 39
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.
August 2004 Page 35 of 39
4 COMMUNICATION PROCESS WITHIN AN IT PROJECT
4.1 SUMMARY
Communication is the cornerstone of how work gets done among different parties within a
project. Communication is not an easy task and requires a great effort of the parties to achieve
it.
In order to get and approach of how communications should be managed in an IT project
development, in what follows will be developed two main topics: elements of a
communication plan and some communication strategies.
4.2 ELEMENTS OF A COMMUNICATION PLAN
Successful IT projects are achieved through a combination of effective, timely decisions,
actions and strategies. Projects are rarely completed by a single person working alone in a
vacuum. Most IT projects are completed by a team of individuals with varied roles and
responsibilities. Depending upon the size and nature of the project, these teams can include,
among others, any combination of (see Section 1.2.1):
The project team;
Customers (both internal and external) of the product/service created;
Project sponsor;
Stakeholders.
Each project team member may bring different levels of technical and project management
expertise, and may even have different attitudes and opinions about overall project direction
and eventual goals. Keeping this diverse group fully informed and working as a unit is a
challenge that can only be met by a carefully crafted set of creative, yet practical,
communication strategies. When formed into policy and action, these strategies become a
Project Communications Plan. And, to achieve project completion and ultimate success, this
plan must be enforced from the first day of a project through to the last.
While the details of any project communications plan will vary in accordance with project
complexity, size and duration, every plan should address the following three basics elements:
Table 20. Basic elements to be considered for any communication plan.
BASIC ELEMENT MEANING
PURPOSE The goals of formal and informal project communication
METHODS The mechanisms and formats for project communications
FREQUENCY The timing and frequency of formal communications activities
With these goals in mind, an effective Project Communications Plan can serve several key
purposes:
To ensure that important information gets to the right parties on a timely basis;
August 2004 Page 36 of 39
To identify and raise potential problems via scheduled, consistent status reporting;
To generate excitement and enthusiasm for a project;
To facilitate decision making and change control;
To provide a specific process for feedback and conflict resolution;
To ensure appropriate transition upon project closure;
To enhance and facilitate teamwork, cooperation and collaboration.
4.3 COMMUNICATIONS STRATEGIES
To begin planning any communications strategy, it must be first considered the specific
requirements of the project at hand. The approach to communications planning will vary
based upon project needs, complexities and sizing. For example, formal communications
activities will take on far more significance in a large, organisation project, than in an internal
IT initiative, having a more limited focus and smaller group of players.
There are four key planning variables to be considered for developing the appropriate
communications strategies:
Project Characteristics and Requirements;
Communications Requirements;
Technical Capabilities;
Staff Considerations.
4.3.1 PROJECT CHARACTERISTICS AND REQUIREMENTS
To create a realistic and effective communications plan, it should first be considered the
requirements and characteristics of the project at hand. Every project has its own personality,
formed by a combination of several key factors. In order to facilitate and plan for effective
project communications, it must first be considered the needs presented by each of these
factors:
Table 21. Key factors for every project.
KEY FACTOR DESCRIPTION
PROJECT TYPE The specific type of project to be completed (i.e., migration, rollout, application
development, relocation, etc.)
PROJECT SIZING The number of phases and tasks involved
EXPECTED DURATION The length of the project
PROJECT RISKS The degree of risk to the business and the sponsoring organisation
TECHNICAL
COMPLEXITY
The extent to which multiple systems are involved and degree of complexity in
the technical solution
PROJECT
ORGANISATION
The size and structure of the resource organisation required to complete and
support the project
COSTS AND BUDGETS The cost of the project in terms of deliverables project execution
BUSINESS VALUE The value and significance of the project to the business
August 2004 Page 37 of 39
Costly, complex projects, of a substantial duration and notable risk, will require a greater
attention to detail, and as such, will likely require more extensive communications programs.
On the other hand, smaller, simpler projects will still depend on communication for success,
but that communication can be less structured and more informal.
4.3.2 COMMUNICATIONS REQUIREMENTS
When analysing project communications requirements, it should be considered two primary
issues:
The parties involved in the project. With whom is it needed to communicate?
The purpose of the intended communications. Why is it needed to communicate?
When exploring the first of these two questions, it is needed to look beyond name and title,
and give full consideration to a broader perspective, considering roles, responsibilities,
politics, and communications requirements.
The following series of questions can be used as a guideline through this analytical process
Who has a vested interest in the project, either in terms of process or outcome?
Who has information or expertise to contribute?
Who has functional responsibility for the project or its outcome?
Who is needed to make project decisions?
Who has the authority to approve project expenditures and purchases?
Who would benefit from participation or observation (i.e. for staff development)?
Who needs to be involved from an organisational or political perspective?
Having considered the players, it is now needed to review the communications purpose: What
are the communications goals and how can those goals best be realised?
The following chart lists and defines seven elements of project communication, designed to
help in the evaluation of communication needs according to “purpose”.
Table 22. Communications requirements analysis: The purpouse.
ELEMENT OF PROJECT
COMMUNICATION PURPOSE
GENERAL
COMMUNICATIONS
Keep all project participants informed of project activities, decisions, and
events
STATUS REPORTING Keep the project team and stakeholders informed of overall status providing
key information for further planning and corrective actions
MEETING MANAGEMENT Plan and schedule effective, productive meetings
ISSUES MANAGEMENT Organise and track technical and operational issues
PROBLEM ESCALATION Track and escalate problems and delays
FEEDBACK MANAGEMENT Provide mechanisms for effective feedback
CHANGE MANAGEMENT Allow for and facilitate the communication and control of project change
requests
August 2004 Page 38 of 39
As this list demonstrates, project communication can serve multiple goals, and some may be
more important than others depending on the nature of the project at hand, and the parties
involved. As project communications strategies are planned, it will be needed to keep a
watchful eye on following question: Of the seven basic communications elements, which ones
must be addressed by this project communications plan, and to what degree and proportion?
The answer will determine the framework of the resulting plan. Depending on the project, it
may be needed to address all seven (7) elements, or it may be focused on some more than
others. As previously noted, project communication is a complex combination of factors, and
as a result, communication plans will vary from project to project.
4.3.3 TECHNICAL CAPABILITIES
Effective communication is a key element of project success. To keep all parties informed,
and to maintain positive working relationships, every available mechanism for
communication must be utilised to the fullest extent possible. Communication systems
provide the technical means by which project information is distributed, progress is reported,
and feedback is solicited and acquired.
To develop effective communications strategies, it must be understood both the availability
and capabilities of these various systems. Based on the individual environment, the choice of
project communications tools may include any or all of the following:
Project management software;
E-mail;
Discussion databases & GroupWare;
Calendaring and scheduling systems;
Telephone conferencing;
Videoconferencing;
Wireless communications;
Web sites.
As it is planning the communications strategies and activities, it will be need to consider the
availability of these various communications systems, and how they can be best used to meet
project needs in view of project characteristics and communications requirements.
4.3.4 STAFF CONSIDERATIONS
While the rewards and results are well worth it, formal project communications activities
require a good deal of time and effort, both in terms of planning and execution. Therefore,
when planning communications strategies and activities, it is important to consider project
schedules, resource constraints, and overall IT workload. It will be needed to balance
informational requirements against time spent in actual communication activities, such as
status reporting and meeting participation.
Status reporting activities should not be allowed to interfere with actual project activities, and
it must be kept in mind the time spent in meetings and report preparation.
August 2004 Page 39 of 39
4.4 CONCLUSIONS
Effective communications plans will be born out of a careful balancing of project needs,
communications requirements, technical capabilities, and staff considerations.
Each of these four elements will be combined differently as projects and business
circumstances change. However, with the use of a structured process for requirements review
and communications planning, these elements can be easily identified and analysed as needed,
to be utilised as the very foundation upon which the communications plans are built (see next
Figure).
Project
manager
Client, sponsor, or
project director
Provides requirements,
guidance and funding
Project team members,
contractors, and
subcontractors
Requires leadership,
planning, and coordination
Line managers of other
departments, staff people,
and other project managers
Requires negotiation
and coordination
Top management
Provides organisational
support and encouragement
Informal
communication
Formal
communication
Direction and
clarification
Progress
reports
Project
directives
Progress reports
and forecasts
Organisational
policies
Status reports
and forecasts
Project
direction
Status
reports
Figure 10. Project communication channels.
4.5 BIBLIOGRAPHICAL REFERENCES
Edman, E. G. The IT Project Communications Planner: Communications Strategies for
Information Technology Projects. Right Track Associates, Inc. www.ittoolkit.com.
USA, 2001-2002.
Project Management Institute. A guide to the project management body of knowledge:
PMBOK Guide. 2000 Edition. www.pmi.org. Visited August 2003.
Wideman, Max. Project Info/Coms Links. Issues and Considerations (ISSACONS)
http://www.maxwideman.com/issacons4/iac1439/sld003.htm. Visited August 2003.