Master of Business Administration-MBA Semester 2

Project Management – MB0049

Q.1 Comment on the following

a. Importance of DMAIS in project management cycle

The projectised mantras of production management can be broadly identified as -
Define Measure, Analyze, Improve, Standardize (DMAIS). These projectised mantras
help in identifying, evaluating, and selecting the right improvement solutions for
managing a project. The mantras also help in identifying the critical issues thus assisting
the organization to adapt to the changes introduced through the implementation of
different solutions.
The phases associated with each projectised mantra of production management are:
1. Define: benchmark, customer requirement, process flow map, quality function
deployment, project management plan
2. Measure: data collection, defect metrics, sampling
3. Analysis: cause and effect, failure modes and effect analysis, decision and risk
analysis, root cause analysis, reliability analysis
4. Improve: design of experiments, modeling, and robust design
5. Standardize: control charts, time series, procedural adherence, performance
management, preventive activities displays the various phases of DMIAS.

b. Knowledge areas of project management

There are nine knowledge areas in Project Management:

1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project Human Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management
Each of the nine knowledge areas contains the processes that need to be
accomplished within its discipline in order to achieve an effective project management
program. Each of these processes also falls into one of the five basic process groups,
creating a matrix structure such that every process can be related to one knowledge area
and one process group.

Q.2 Write few words on:

a. Project Characteristics
The word PROJECT comes from the Latin word PROJECTUM from the Latin
verb PROICERE; which means “to throw something forwards” which in turn comes from
PRO-, which denotes something that precedes the action of the next part of the word in
time and ICERE, “to throw”. The word PROJECT thus actually originally meant
“something that comes before anything else happens”.
A project in business and science is a temporary endeavor undertaken to create a
unique product, service, or result. Basically, it is planned to achieve a particular aim. The
aim of a project is to attain its objective and then terminate. Some of the reasons to start a
project can be:
· A customer request or market demand
· An organizational need
· A customer request
· A technological advance
· A legal requirement
· Projects and operations differ primarily in that operations are ongoing and
repetitive, while projects are temporary and unique. Generally, a project is a
means of organizing some activities that cannot be addressed within the normal
operational limits.
Project characteristics:
· It is temporary – temporary means that every project has a definite beginning and
a definite end. Project always has a definitive time frame.
· A project creates unique deliverables, which are products, services, or results.
· A project creates a capability to perform a service.
· Project is always developed in steps and continuing by increments – Progressive
Elaboration.
b. WBS
A work breakdown structure (WBS) in project management and systems
engineering, is a tool used to define and group a project's discrete work elements in a way
that helps organize and define the total work scope of the project..
A work breakdown structure element may be a product, data, a service, or any
combination. A WBS also provides the necessary framework for detailed cost estimating
and control along with providing guidance for schedule development and control.
Additionally the WBS is a dynamic tool and can be revised and updated as needed by
the project manager
The Work Breakdown Structure is a tree structure, which shows a subdivision of
effort required to achieve an objective; for example aprogram, project, and contract. In a
project or contract, the WBS is developed by starting with the end objective and
successively subdividing it into manageable components in terms of size, duration, and
responsibility (e.g., systems, subsystems, components, tasks, subtasks, and work
packages) which include all steps necessary to achieve the objective.
The Work Breakdown Structure provides a common framework for the natural
development of the overall planning and control of a contract and is the basis for dividing
work into definable increments from which the statement of work can be developed and
technical, schedule, cost, and labor hour reporting can be established.
A work breakdown structure permits summing of subordinate costs for tasks,
materials, etc., into their successively higher level “parent” tasks, materials, etc. For each
element of the work breakdown structure, a description of the task to be performed is
generated.This technique (sometimes called a System Breakdown Structure ) is used to
define and organize the total scope of a project.
The WBS is organised around the primary products of the project (or planned
outcomes) instead of the work needed to produce the products (planned actions). Since
the planned outcomes are the desired ends of the project, they form a relatively stable set
of categories in which the costs of the planned actions needed to achieve them can be
collected. A well-designed WBS makes it easy to assign each project activity to one and
only one terminal element of the WBS. In addition to its function in cost accounting, the
WBS also helps map requirements from one level of system specification to another, for
example a requirements cross reference matrix mapping functional requirements to high
level or low level design documents.

c. PMIS
Project Management Information System (PMIS) are system tools and techniques
used in project management to deliver information. Project managers use the techniques
and tools to collect, combine and distribute information through electronic and manual
means. Project Management Information System (PMIS) is used by upper and lower
management to communicate with each other.
Project Management Information System (PMIS) help plan, execute and close
project management goals. During the planning process, project managers use PMIS
for budget framework such as estimating costs. The Project Management Information
System is also used to create a specific schedule and define the scope baseline. At
the execution of the project management goals, the project management team collects
information into one database. The PMIS is used to compare the baseline with the actual
accomplishment of each activity, manage materials, collect financial data, and keep a
record for reporting purposes. During the close of the project, the Project Management
Information System is used to review the goals to check if the tasks were accomplished.
Then, it is used to create a final report of the project close. To conclude, the project
management information system (PMIS) is used to plan schedules, budget and execute
work to be accomplished in project management.

d. Project Management strategies-Internal & external

Effective Internal Project Management Strategies
Projects fail for many internal reasons, some of them technical, some of them
managerial. However, even the technical failures can often be traced back to a failure on
the part of the project's executive management to recognize and deal with these inherent
managerial risks. On the other hand, probably the majority of apparently successful
projects do not reflect their optimum potential either.
As a matter of project experience, a number of prerequisites have been identified
with the successful project. While these prerequisites do not necessarily guarantee
success of future projects, their absence may well lead to sub-optimal success, if not
outright failure. The Project's Executive has a vital role to play in achieving project
success and should therefore insist on the following:
· Executive Support - The Executive must clearly demonstrate support for the
project management concept by active sponsorship and control.
· External Authority - The project manager must be seen as the authoritative agent
in dealing with all parties, and be the responsible and single formal contact with
them.
· Internal Authority - The project manager must have the necessary managerial
authority within his organization to ensure response to his requirements.
· Commitment Authority - The project manager must have the responsibility and
authority to control the commitment of resources, including funds, within
prescribed limits. The results of these decisions must be both accountable and
visible.
· Project Manager Involved in All Major Decisions - No major technical, cost,
schedule, or performance decisions should be made without the project manager's
participation.
· Competence - The project manager and his team members must be competent.
Other functional personnel assigned to the project must also be competent.
· Project Team - The project manager should have a say in the assembly of his
project team, which will help him to obtain their personal commitment, support
and required quality of service.
· Management Information Systems - Effective project management information
and control systems must be in place.
Effective External Project Management Strategies
Prerequisites for avoiding internal project failure, or at least sub-optimal results,
were discussed earlier. However, it has also been noted earlier that external conditions
and events also represent uncertainty and risk to the successful accomplishment of the
project. These conditions have been linked to the external stakeholders of the project.
Therefore, it is essential to develop a sound stakeholder environment.
Developing a Sound Stakeholder Environment
Just as the means of influencing the project's cultural environment, as described
above, was one of developing the right attitude, so it is with developing a sound
stakeholder environment. Perhaps this attitude is best reflected by adopting a mind set
that reverses the traditional organization chart hierarchy. In other words, place the project
stakeholders at the top of the chart, followed by the front-line project team members, and
on down to the project manager at the bottom. Perhaps the project team will then be
better visualized as a truly service organization, designed to serve the best interests of a
successful project outcome, both perceived and in reality.
Some suggested steps in this process include:
· Learn how to understand the role of the various stakeholders, and how this
information may be used as an opportunity to improve both the perception and
reception of the project
· Identify the real nature of each stakeholder group's business and their consequent
interest in the project
· Understand their behavior and motivation
· Assess how they may react to various approaches
· Pinpoint the characteristics of the stakeholders' environment and develop
appropriate responses to facilitate a good relationship
· Learn project management's role in responding to the stakeholders drive behind
the project
· Determine the key areas which will have the most impact on the successful
reception of the project
· Remember always that even a minor stakeholder group may discover the fatal
flaw in the project and which could bring the project to a standstill

Q.3 what are the various SCMo soft wares available in project
management? Explain each in brief.
The process documentation system is intranet based to provide immediate access
to current, up-to-date process documentation. The system allows users to navigate
through graphical structures to relevant documentation and processes which were created
with the ARIS-Toolset.
The content of the process documentation system includes the area supply chain
management from the Odette Supply Chain Management Group. The system includes
graphical process documentation, in the form of process chains, as well as the entire
range of documentation related to the processes. The Process Documentation System
gives, according to its objectives, an overview and a detailed view of the relevant
processes for SCMo.
The entry point in the documentations system is the model “Process Overview
SCMo”. This model is the starting point for the navigation to other models. The
navigation between models is done via the assignment symbol. The assignment symbol of
a function / process Interface indicates that there is a link to another model. The linked /
assigned models can be opened by double-clicking on the assignment symbol.

a) Vertical Navigation: The vertical navigation is the navigation on different

levels. Starting on the work package level and going downwards into more detail, the first
models of processes are found on the sub-process level.
In the model “Process Overview SCMo” those processes are assigned to the
functions on Level 2. In the models there can be assignments for some functions, e.g. for
a Function Allocation Diagram or a sub-process that describes that function. These two
examples are currently the models on the lowest level.
b) Horizontal Navigation: The horizontal navigation is on the same level. Some
processes have a link to other processes, which can be at the start or end or even in the
process itself, when another process is imbedded in the process. Those links are
represented by Process Interfaces.
Microsoft has a team project management solution that enables project managers
and their teams to collaborate on projects. The Microsoft Project 2002 products in these
solutions are:
· Microsoft Project Standard 2002
· Microsoft Project Server 2002
· Microsoft Project Server Client Access License (CAL) 2002.
Support Software
Having learnt the basics of application software, you would have a fair idea of
how and to what extent project management processes could be automated. However, the
challenge of “making things work” remains unchanged. While software vendors are
confident of “making it work”, two yawning gaps still remain:
1. Business processes which are not covered in such software
2. Integration of multi vendor supported software applications
The enterprise is normally in a dilemma – whether to look at the same vendors to
support such customization or not. This normally works out too expensive for their
comfort or within their tight budgets.
Several software vendors have seized the opportunity with offerings that
substantially fill these gaps effectively at a fraction of the costs quoted by the major
vendors. The other carrot which these vendors offer is a unilateral transfer of the facility
to customize themselves which is seen as a huge advantage. The various support software
that may be used for managing projects are:
· ARROW
· FEDORA
· VITAL
· PILIN
· MS EXCHANGE SERVER 2003
Q.4 List the various steps for Risk management. Also explain GDM and its
key features.
Risk management may be classified and categorized as:
1. Risk assessment and identification The assessment and identification focuses on
numerating possible risks to the project. Methods that can aid risk identification include
checklists of possible risks, surveys, meetings and brainstorming and reviews of plans,
process and work products. The project manager can also use the process database to get
information about risks and risk management on similar projects.
2. Risk prioritization – focus on the highest risk. Prioritization requires analyzing the
possible effects of the risk event in case it actually occurs. This approach requires a
quantitative assessment of the risk probability and the risk consequences. For each risk
rate the probability of its happening as low, medium or high. If necessary, assign
probability values in the ranges given for each rating. For each risk, assess its impact on
the project as low, medium, high or very high. Rank the risk based on the probability.
Select the top few risk items for mitigation and tracking.
3. Risk Control: The main task is to identify the actions needed to minimize the risk
consequences, generally called risk mitigation steps. Refer to a list of commonly used
risk mitigation steps for various risks from the previous risk logs maintained by the PM
and select a suitable risk mitigation step. The risk mitigation step must be properly
executed by incorporating them into the project schedule. In addition to monitoring the
progress of the planned risk mitigation steps periodically revisit project. The results of
this review are reported in each milestone analysis report. To prepare this report, make
fresh risk analysis to determine whether the priorities have
Risk Analysis
The first step in risk analysis is to make each risk item more specific. Risks such as,
“Lack of Management buy in,” and “people might leave,” are a little ambiguous. In these
cases the group might decide to split the risk into smaller specific risks, such as,
“manager Jane decides that the project is not beneficial,” “Database expert might leave,”
and “Webmaster might get pulled off the project.” The next step is to set priorities and
determine where to focus risk mitigation efforts. Some of the identified risks are unlikely
to occur, and others might not be serious enough to worry about. During the analysis,
discuss with the team members, each risk item to understand how devastating it would be
if it did occur, and how likely it is to occur. For example, if you had a
risk of a key person leaving, you might decide that it would have a large impact on the
project, but that it is not very likely. In the process below, we have the group agree on
how likely it thinks each risk item is to occur,using a simple scale from 1 to 10 (where 1
is very unlikely and 10 is very likely). The group then rates how serious the impact would
be if the risk did occur, using a simple scale from 1 to 10 (where 1is little impact and 10
is very large). To use this numbering scheme, first pick out the items that rate 1 and 10,
respectively. Then rate the other items relative to these boundaries. To determine the
priority of each risk item, calculate the product of the two values, likelihood and impact.
This priority scheme helps push the big risks to the top of the
list, and the small risks to the bottom. It is a usual practice to analyze risk either by
sensitivity analysis or by probabilistic analysis. In sensitivity analysis a study is done to
analyse the changes in the variable values because of a change in one or more of the
decision criteria. In the probability analysis, the frequency of a particular event occurring
is determined, based on which it average weighted average value is calculated.
Each outcome of an event resulting in a risk situation in a risk analysis process is
expressed as a probability. Risk analysis can be performed by calculating the expected
value of each alternative and selecting the best alternative.
Ex: Now that the group has assigned a priority to each risk, it is ready to select the items
to mange. Some projects select a subset to take action upon, while others choose to work
on all of Project the items. To get started, you might select the top 3 risks, or the top 20%,
based on the priority calculation.
GDM –
The Global Delivery Model (GDM) is adopted by an Industry or Business such that it
has a capability to plan design, deliver and serve to any Customers or Clients Worldwide
with Speed, Accuracy, Economy and Reliability. The key Features of GDM are ·
Standardization
Modularization
Minimum Customization
Maximum Micro structure
Adoption of a Combination of the Greatest Common Multiple and the Least Common
Factor of a Large Mass of Microbial Componentsa)
Standardization - Ingenious Design and Development of Components and
Features which are like to be accepted by 90% of Worldwide Customers. Global
Standards of Design focusing on highly standardized Methods and Processes of
manufacture or Development. Adopt Plug and socket Concepts with minimum
adaptable joints or Connections.
b) Modularization - Product or Solution split up into smallest possible individual
Identifiable Entities, with limited Individual Functioning Capability but powerful
and robust in Combination with other Modules.
c) Minimum Customization - Minimum Changes or Modifications to suit Individual
Customers.
d) Maximum micro structuring - Splitting of the Product Modules further into much
smaller entity identifiable more through characteristics rather than application
Features. Approach through Standardization of these Microbial Entities even
across Multiple Modules. Application of these Microbial Entities to rest within
multiple Projects or Products or even as add-ons suit belated Customer Needs.
Special Features of GDM
Some of the special features of GDM are ·
· Cuts across Geographical and Time Zone Barriers
· Unimaginable Speeds of Response and Introduction.
· Common Pool of Microbial Components
· Largely Independent of Skill Sets required at Delivery Stages
· Highly automated Processes
· Quality Assurance as a Concurrent rather than a Control Process
· Near Shore Development, Manufacture and Delivery for better Logistics
· Mapping of Economical Zones rather than Geographic Zones
· Continuous Floating virtual Inventory to save Time and Efforts.

Q.5 Answer the two parts:

a. Importance of data management in project management-Comment.

The Role of Effective Data Management in the Success of Project Management

Data management consists of conducting activities which facilitate acquiring data,
processing it and distributing it. Acquisition of data is the primary function.
To be useful, data should have three important characteristics – timeliness, sufficiency
and relevancy. Management of acquisition lies in ensuring that these are satisfied before
they are stored for processing and decisions taken on the analysis.
There should be data about customers, suppliers, market conditions, new technology,
opportunities, human resources, economic activities, government regulations, political
upheavals, all of which affect the way you function. Most of the data go on changing
because the aforesaid sources have uncertainty inherent in them. So updating data is a
very important aspect of their management. Storing what is relevant in a form that is
available to concerned persons is also important. When a project is underway dataflow
from all members of the team will be flowing with the progress of activities. The data
may be about some shortfalls for which the member is seeking instructions. A project
manager will have to analyse them, discover further data from other sources and see how
he can use them and take decisions. Many times he will have to inform and seek sanction
from top management.
The management will have to study the impact on the overall organisational goals and
strategies and convey their decisions to the manager for implementation. For example,
Bill of Materials is a very important document in Project Management. It contains details
about all materials that go into the project at various stages and has to be continuously
updated as all members of the project depend upon it for providing materials for their
apportioned areas of execution. Since information is shared by all members, there is an
opportunity for utilising some of them when others do not need them. To ascertain
availability at some future point of time, information about orders placed, backlogs, lead
times are important for all the members. A proper MIS will take care of all these aspects.
ERP packages too help in integrating data from all sources and present them to individual
members in the way they require. When all these are done efficiently the project will have
no hold ups an assure success.
b. What is the significance of reviewing ROI?
ROI - Return on Investment (ROI) is the calculated benefit that an organization is
projected to receive in return for investing money (resources) in a project. Within the
context of the Review Process, the investment would be in an information system
development or enhancement project. ROI information is used to assess the status of the
business viability of the project at key checkpoints throughout the project’s lifecycle.
ROI may include the benefits associated with improved mission performance, reduced
cost, increased quality, speed, or flexibility, and increased customer and employee
satisfaction. ROI should reflect such risk factors as the project’s technical complexity, the
agency’s management capacity, the likelihood of cost overruns, and the consequences of
under or nonperformance. Where appropriate, ROI should reflect actual returns observed
through pilot projects and prototypes.
ROI should be quantified in terms of dollars and should include a calculation of the
breakeven point (BEP), which is the date when the investment begins to generate a
positive return. ROI should be recalculated at every major checkpoint of a project to se if
the BEP is still on schedule, based on project spending and accomplishments to date. If
the project is behind schedule or over budget, the BEP may move out in time; if the
project is ahead of schedule or under budget the BEP may occur earlier. In either case, the
information is important for decision making based on the value of the investment
throughout the project lifecycle. Any project that has developed a business case is
expected to refresh the ROI at each key project decision point (i.e., stage exit) or at least
yearly.
Exclusions
If the detailed data collection, calculation of benefits and costs, and capitalization data
from which Return on Investment (ROI) is derived was not required for a particular
project, then it may not be realistic or practical to require the retrofit calculation of ROI
once the project is added to the Review portfolio. In such a case, it is recommended that a
memorandum of record be developed as a substitute for ROI. The memorandum should
provide a brief history of the program, a description of the major benefits realized to date
with as much quantitative data as possible, and a summary of the process used to identify
and select system enhancements.
Some of the major benefits experienced by sites that installed the information system that
would be important to include in the memorandum are:
a) Decommissioning of mainframe computers
b) Reduction/redirection of labour
c) Elimination of redundant systems
d) Ability to more cost effectively upgrade all sites with one standard upgrade package.
In each case above, identify the specific site, systems, and labour involved in determining
the cited benefit. Identify any costs or dollar savings that are known or have been
estimated. The memorandum will be used as tool for responding to any future audit
inquiries on project ROI.
For the Project Management Review, it is recommended that the project leader replace
the text on the ROI document through -
1) a note stating which stage of its cycle the project is in;
(2) A bulleted list of the most important points from the memorandum of record; and
(3) a copy of the memorandum of record for the Review repository.
In subsequent Reviews of the information system, the ROI slide can be eliminated form
the package. There is one notable exception to this guidance. Any internal use software
project in the maintenance phase of its lifecycle that adds a new site or undertakes an
enhancement or technology refresh that reaches the cost threshold established by
Standard will need to satisfy capitalization requirements. It requires all agencies to
capitalize items acquired or developed for internal use if the expected service life is two
or more years and its cost meets or exceeds the agency’s threshold for internal use
software. The standard requires capitalization of direct and indirect costs, including
employee salaries and benefits for both Federal and Contractor employees who materially
participate in the Software project. Program managers are considered to be the source of
cost information for internal use software projects. If capitalization data is collected for
the project in the future, the project would be expected to calculate and track its ROI.
Q.6 XYZ Company implements CMMI level-03. To make further changes it
decides on starting a new division in the organization. It decides to advance the
existing project management. What are the steps to be followed by the
organization to drive project management to a new horizon?

Capability Maturity Model Integration (CMMI) is a process improvement approach

that helps organizations improves their performance. CMMI can be used to guide process
improvement across a project, a division, or an entire organization.
CMMI in software engineering and organizational development is a process improvement
approach that provides organizations with the essential elements for effective process
improvement. CMMI is a trademark owned by Software Engineering Institute of
Carnegie Mellon University.
According to the Software Engineering Institute (SEI, 2008), CMMI helps "integrate
traditionally separate organizational functions, set process improvement goals and
priorities, provide guidance for quality processes, and provide a point of reference for
appraising current processes."
CMMI currently addresses three areas of interest:
1. Product and service development — CMMI for Development (CMMI-DEV),
2. Service establishment, management, and delivery — CMMI for Services (CMMISVC),
and
3. Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).

CMMI was developed by a group of experts from industry, government, and the Software
Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide
guidance for developing or improving processes that meet the business goals of an
organization. A CMMI model may also be used as a framework for appraising the
process maturity of the organization.
CMMI originated in software engineering but has been highly generalised over the years
to embrace other areas of interest, such as the development of hardware products, the
delivery of all kinds of services, and the acquisition of products and services. The word
"software" does not appear in definitions of CMMI. This generalization of improvement
concepts makes CMMI extremely abstract. It is not as specific to software engineering as
its predecessor, the Software CMM.
CMMI was developed by the CMMI project, which aimed to improve the usability of
maturity models by integrating many different models into one framework. The project
consisted of members of industry, government and the Carnegie Mellon Software
Engineering Institute (SEI). The main sponsors included the Office of the Secretary of
Defense (OSD) and the National Defense Industrial Association.
CMMI is the successor of the capability maturity model (CMM) or software CMM. The
CMM was developed from 1987 until 1997. In 2002, CMMI Version 1.1 was released.
Version 1.2 followed in August 2006.
CMMI representation
CMMI exists in two representations: continuous and staged. The continuous
representation is designed to allow the user to focus on the specific processes that are
considered important for the organization's immediate business objectives, or those to
which the organization assigns a high degree of risk. The staged representation is
designed to provide a standard sequence of improvements, and can serve as a basis for
comparing the maturity of different projects and organizations. The staged representation
also provides for an easy migration from the SW-CMM to CMMI.
CMMI model framework
Depending on the CMMI constellation (acquisition, services, development) used, the
process areas it contains will vary. Key process areas are the areas that will be covered by
the organization's processes. The table below lists the process areas that are present in all
CMMI constellations. This collection of eight process areas is called the CMMI Model
Framework, or CMF.
Capability Maturity Model Integration (CMMI) Model Framework (CMF)
CMMI models
CMMI best practices are published in documents called models, each of which addresses
a different area of interest. The current release of CMMI, version 1.2, provides models for
three areas of interest: development, acquisition, and services.
· CMMI for Development (CMMI-DEV), v1.2 was released in August 2006. It
addresses product and service development processes.
· CMMI for Acquisition (CMMI-ACQ), v1.2 was released in November 2007. It
addresses supply chain management, acquisition, and outsourcing processes in
government and industry.
· CMMI for Services (CMMI-SVC), v1.2 was released in February 2009. It
addresses guidance for delivering services within an organization and to external
customers.
· CMMI Product Suite (includes Development, Acquisition, and Services), v1.3 is
expected to be released in 2010. CMMI Version 1.3—Plans for the Next Version
Regardless of which model an organization chooses, CMMI best practices should be
adapted by an organization according to its business objectives.
Appraisal
An organization cannot be certified in CMMI; instead, an organization is appraised.
Depending on the type of appraisal, the organization can be awarded a maturity level
rating (1-5) or a capability level achievement profile.
Many organizations find value in measuring their progress by conducting an appraisal.
Appraisals are typically conducted for one or more of the following reasons:
1. To determine how well the organization’s processes compare to CMMI best
practices, and to identify areas where improvement can be made
2. To inform external customers and suppliers of how well the organization’s
processes compare to CMMI best practices
3. To meet the contractual requirements of one or more customers
Appraisals of organizations using a CMMI model must conform to the requirements
defined in the Appraisal Requirements for CMMI (ARC) document. There are three
classes of appraisals, A, B and C, which focus on identifying improvement opportunities
and comparing the organization’s processes to CMMI best practices. Appraisal teams use
a CMMI model and ARC-conformant appraisal method to guide their evaluation of the
organization and their reporting of conclusions. The appraisal results can then be used
(e.g., by a process group) to plan improvements for the organization.
The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an
appraisal method that meets all of the ARC requirements.
A class A appraisal is more formal and is the only one that can result in a level rating.
Results of an appraisal may be published (if the appraised organization approves) on the
CMMI Web site of the SEI: Published SCAMPI Appraisal Results. SCAMPI also
supports the conduct of ISO/IEC 15504, also known as SPICE (Software Process
Improvement and Capability Determination), assessments etc.
Achieving CMMI compliance
The traditional approach that organizations often adopt to achieve compliance with the
CMMI involves the establishment of an Engineering Process Group (EPG) and Process
Action Teams (PATs).This approach requires that members of the EPG and PATs be
trained in the CMMI, that an informal (SCAMPI C) appraisal be performed, and that
process areas be prioritized for improvement. More modern approaches that involve the
deployment of commercially available, CMMI-compliant processes, can significantly
reduce the time to achieve compliance. SEI has maintained statistics on the "time to move
up" for organizations adopting the earlier Software CMM and primarily using the
traditional approach.[6] These statistics indicate that, since 1987, the median times to
move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is an additional
20 months. These statistics have not been updated for the CMMI.
The Software Engineering Institute’s (SEI) Team Software Process methodology and the
Capability Maturity Modeling framework can be used to raise the maturity level.
Applications
The SEI published that 60 organizations measured increases of performance in the
categories of cost, schedule, productivity, quality and customer satisfaction.[7] The median
increase in performance varied between 14% (customer satisfaction) and 62%
(productivity). However, the CMMI model mostly deals with what processes should be
implemented, and not so much with how they can be implemented. These results do not
guarantee that applying CMMI will increase performance in every organization. A small
company with few resources may be less likely to benefit from CMMI; this view is
supported by the process maturity profile (page 10). Of the small organizations (<25
employees), 70.5% are assessed at level 2: Managed, while 52.8% of the organizations
with 1001–2000 employees are rated at the highest level (5: Optimizing).
Interestingly, Turner & Jain (2002) argue that although it is obvious there are large
differences between CMMI and agile methods, both approaches have much in common.
They believe neither way is the 'right' way to develop software, but that there are phases
in a project where one of the two is better suited. They suggest one should combine the
different fragments of the methods into a new hybrid method. Sutherland et al. (2007)
assert that a combination of Scrum and CMMI brings more adaptability and predictability
than either one alone. David J. Anderson (2005) gives hints on how to interpret CMMI in
an agile manner. Other viewpoints about using CMMI and Agile development are
available on the SEI Web site.
The combination of the project management technique earned value management (EVM)
with CMMI has been described (Solomon, 2002). To conclude with a similar use of
CMMI, Extreme Programming (XP), a software engineering method, has been evaluated
with CMM/CMMI (Nawrocki et al., 2002). For example, the XP requirements
management approach, which relies on oral communication, was evaluated as not
compliant with CMMI.
CMMI can be appraised using two different approaches: staged and continuous. The
staged approach yields appraisal results as one of five maturity levels. The continuous
approach yields one of six capability levels. The differences in these approaches are felt
only in the appraisal; the best practices are equivalent and result in equivalent process
improvement results