Process assessment: Assessors

Process assessment may be conducted by an external assessor, an internal Software Engineering Process Group (SEPG), the internal Software Quality Assurance (SQA) team, or an ad hoc group of managers and practitioners from within the organization.
Process assessment always requires the involvement of people within the organization; however, the degree of involvement of each of them varies. All the people within the organization are required to provide input about the processes through mechanisms such as questionnaires and interviews. People are trained on the model being used for process assessment, how the processes are being used, and how to measure them for effectiveness. This makes the people in the organization more receptive to changes and process improvement efforts.
Let us now discuss the second step in the generic model for process improvement.

Education

Education, the second step in the model, is necessary to make appropriate decisions. The people responsible for process improvement must have a thorough knowledge of software engineering practices and understand the impact of the assessment findings. Given below are some examples of the procedures, methods, and tools that are imparted through education.

• For practitioners: Analysis, design, implementation, and testing methods
• For managers: Estimation, scheduling, planning, and risk analysis
• For customers: Software concepts, communication techniques, and acceptance testing
• For SQA staff: Statistical methods, SQA methods, and auditing
• For all: Reviews, metrics, SQA issues, SCM, and customer communication

Areas of education

Given below is a list of some typical aspects addressed by education.

• Appreciation of the need to adopt software engineering practices and processes and quality-related approaches
• Imparting software engineering and project management skills needed for building the software and performing the umbrella activities
• Imparting skills required to define the processes of the organization
• Imparting soft skills such as people management and human relations
• Improving skills required for a specific project, application, or platform (These are part of specific project training and are separately planned and provided.)

Education for reducing resistance to change

Process improvement involves change, and a typical problem is that people resist change. Resistance to change is a natural response because:

• People are not convinced about the need to change as they do not appreciate the importance of the new processes, methods, and tools.
• People feel they lack the skills to work in the new desired manner.

Education can address both these concerns. It imparts the knowledge required for using the changed processes. It is also a means of explaining to people the importance of using the new processes.

Education can, therefore, help overcome resistance to change and help smoothen process improvement.

Strategy for education

Based on the process assessment results, a strategy is formulated for imparting the required education. This could be designed as a curriculum that achieves 'just-in-time' training.
Let us listen and find out how education is provided for process improvement.

People resist changes in culture because they are ignorant of the new culture, and that leads us to education. Education is a pivotal activity in software process improvement. We need to educate managers, practitioners or technologists, and customers so that they all understand just where software engineering fits into the big picture. Education is important for another reason as well. IT SELLS! So, it is important that we take a quick look at software engineering education and understand just how it fits into the broader software process improvement model.

The education activity begins by building on the results of the process assessment. During the process assessment, we develop an evaluation of a number of key process attributes, for example, software project management abilities or quality assurance capability, measurement, or methods.

In doing this, we create what we call a process footprint, indicating relative strengths and weaknesses within the software development process. We design a curriculum that achieves just-in-time training. We would hope that essential software engineering will do much of this for you. We then select appropriate knowledge delivery components for the needs of specific staff members, for example, some staff may need training and testing while other staff may need to become more knowledgeable in software quality assurance. When we teach specific software engineering methods such as structured analysis or structured design, we always attempt to integrate tools into the training process so that people will be going live, that is, using tools that are most appropriate to the particular method in hand. And, finally, we focus on the education of managers, practitioners, and customers so that everyone is on board with the software engineering process.

Selection

The third step of the generic model for process improvement is selection.
In order to make improvements in the process, we need to examine the components of software engineering. We need to select procedures, methods, and tools to improve processes because all the three work together to make a process effective.
An important aspect is that the process should be simple, practical, and suitable to achieve the desired results. A process that is elaborate and complex should be avoided because it is likely that it will not be used. Processes are effective only if they are convenient for the people who use them. People should have the desired skills and should be convinced that using the defined processes will help them perform their jobs better and meet the required targets.
The process framework is the foundation for software engineering. Organizations need to define a common process framework (CPF) and the adaptation guidelines that the project teams can use to adapt the CPF based on the project characteristics.
The CPF should be based on the selection of an appropriate software engineering paradigm (process model) as the abstract or conceptual base. The methods and tools are selected to suit this process framework. The selection of processes, methods, and tools should be concurrent and should 'fit' well to achieve the desired result.

Justification

The fourth step of the generic model for process improvement is justification.
Process improvement efforts cost money and take time. Therefore, they can only be undertaken with management support and commitment, so that adequate resources are available and the activities related to process improvement are given priority.
The management needs to be convinced that the process improvement efforts are worthwhile and should be willing to support them. Therefore, the management requires a justification such as a cost-benefit analysis. Such analyses provide a basis for reserving the resources required for process improvement.

Steps in justification

Given below is the sequence of steps that can be used to justify the costs associated with process improvement.

1.     Collect the cost and effort data from the past projects.

2.     Project the 'future demand' for software in the next few years

3.     Compute the cost of the future demand using the data collected from the past projects (as in item 1).

4.     Project the cost and effort benefits due to process improvement. (10 percent to 25 percent per year is typically considered good enough to proceed with the plans.)

5.     Re-compute the cost of the future demand using data from item 4.

6.     Compute the gross savings (item 3 minus item 5).

7.     Determine the cost of the process improvement activities.

8.     Compute the net savings (item 6 minus item 7).

A formal justification is essential to enable the management to set aside the resources and time for the process improvement work.

Justification: Benefits of process improvement

The benefits of process improvement are not always monetary in nature. However, the process improvement can still be justified if the benefits that it provides are worthwhile, even if not quantifiable.

For example, process improvement can be undertaken if:

• The organization will be able to provide greater service to the business.
• Throughput will be improved, resulting in satisfied customers.
• More projects will be completed per unit of time.

Installation

Let us recapitulate the steps in the generic model for process improvement before discussing the next step of the model—installation.

• Process assessment is required to understand the current status and the areas to be improved.
• Education prepares the practitioners, managers, customers, and others for the changes and equips them for making reasonable and effective decisions related to process improvement.
• Selection helps to choose the appropriate process framework, methods, and tools.
• Justification is required to obtain management commitment and the required resources.

Installation is the fifth step of the generic model for process improvement. The actual changes for process improvement are made during this step.
Successful installation starts with the creation of a comprehensive process improvement plan. For process improvement to succeed, we need to plan it well and then execute it as per the plan.
The process improvement plan contents are typical of any plan with defined objectives, resources, roles and responsibilities, activities, schedules, reporting, and controls.
One of the key aspects to remember while planning process improvements is to plan for small steps that are likely to be successful and risk only small failures.

Installation and the system assistants

An important factor for successful installation is identifying 'system assistants' or 'systants' (a term originally coined by Gerald Weinberg). Systants are the experts in an organization who help people in installing the new processes and technologies within the organization. They are available for answering questions and solving the problems faced by people while trying to change over to the new process.
One of the critical success factors for process improvement is the identification and training of committed systants. Therefore, while planning, we need to ensure that systants are available to support the changes being made in the process.

Evaluation

The sixth and last step involved in the generic model for process improvement is evaluation. Evaluation helps to assess the effort spent in process improvement and check whether the desired result has been achieved. It helps us clearly answer whether quality and productivity have really improved.
If, during evaluation, we find that some goals of process improvement have not been met, a different approach may need to be used for process improvement. Evaluation helps the management to check whether the resources that are used have yielded the expected results, as envisaged during the 'justification'.
Evaluation, therefore, is essential for tuning the process changes. Without evaluation, we have no basis for further action. Evaluation, to some extent, similar to process assessment. In both these steps, the type of input and the nature of questions asked are very much alike.

Cyclical nature of process improvement

The process improvement activity never ends in an organization that is serious about software engineering.
The process improvement cycle shown here begins with an assessment activity and then moves clockwise around the spiral through other process improvement steps.
Like the spiral process model for software, the cycle begins at the center of the spiral. Each clockwise revolution around the spiral passes through steps such as assessment, education, selection, justification, installation, and evaluation. The next cycle begins, once the evaluation is completed.
As we move outwards on the spiral, the number of passes increase and the software process becomes more mature and effective.
Small, visible, and successful cycles are an effective way of improving processes.

The cyclical nature of process improvement and evaluation

Every pass around the spiral may not include every step of process improvement. The first or innermost cycle is for performing the assessment. The later cycles are driven by evaluation, which helps to decide the next course of process improvement. However, a re-assessment may be performed at any time.
We may choose to have a full-fledged assessment after a number of smaller cycles, with evaluation leading back to the next iteration.
For example, if we are using CMM^® as a model for achieving process maturity, the full cycle leading from one level of maturity to the next could be over two years, which is when the assessment is done.
Within these, there may be many smaller cycles, in which small process improvements are made, evaluated, and fine-tuned.

Multiple process improvement initiatives

The generic cyclical model discussed in this section represents the six steps needed for process improvement as distinct and sequential steps. The model explicitly identifies the basic activities and their sequence.
Process improvement activities can be initiated in parallel for different areas that require improvement. For example, an organization could initiate improvement activities for the review process as well as for customer complaint processing at the same time.

The sequence of steps in process improvement

All process improvement activities include certain steps. The sequence of steps could be altered depending on the organization's needs.
For example, assessment may be followed by justification, and after the approval of the management, the rest of the activities—education, selection, and installation—may be performed. Alternatively, activities like justification, education, and selection could be included in the plan and 'installed' along with other activities.

Process improvement: Common problems

There are several problems faced while progressing through the process improvement cycle.

Some of the common problems faced during process improvement efforts are as listed below.

• Lack of management support and commitment for the process improvement initiative
• Lack of enthusiasm among the people within the organization
• Inertia from the management to get started with the process improvement initiative
• Inability to sustain momentum within the organization

Given below are some more problems faced during process improvement initiatives.

• Selection of inappropriate technology
• The 'no time' syndrome for process improvement activities
• People within the organization avoiding process improvement because of earlier failures

Process improvement: Critical success factors

Let us now consolidate the factors that contribute significantly to the success of process improvement efforts.

• Obtaining the commitment of the top management
• Ensuring that the people involved in process improvement are 'educated'
• Having a realistic process framework
• Aiming at a series of small visible successes
• Having a plan for the process improvement activities
• Using committed and trained systants to facilitate the implementation

Using measurement in a practical and effective way

SOFTWARE PROCESS IMPROVEMENT

Introduction

Software products are built using software engineering practices, which are applied within the context of a defined software process. The quality of the software process influences the quality of the product. A better process is more likely to result in high-quality products.
Each software project is different; therefore, it is important to have a good software process to produce a high-quality product. In order to continually improve the quality of its products, an organization must continuously improve its processes.
In this section, you will get an overview of the importance of software process improvement.

The software process

In every software project, a process is used to develop software. The process represents the approach to software work and is the framework that the project team uses for planning, managing, and executing the project. The process used for a project may be a mature and effective process or it may be ad hoc, haphazard, ill-defined, and/or inappropriate. The existence of a process is not in itself sufficient. To be effective for building quality products, the process must be:

• Appropriate for the work to be performed
• Adopted by the people doing the work and applied consistently by all the members of a project team

If the process used is inappropriate, poorly defined, or not followed by those who do the software work, the resultant product may be of low quality.

Defining a software process

A software process is based on a software process model that defines the overall flow and the philosophy of the process.
Some organizations develop a common process framework (CPF) that defines the framework activities and umbrella activities applicable to all the software projects regardless of project type or size. Each framework and umbrella activity is further detailed into 'task sets' that define the work tasks, the work products produced, the quality assurance (QA) checkpoints and the project milestones achieved throughout the process. The CPF establishes a foundation for the creation of high-quality software and acts as a generic framework that is adapted by each project team for defining its software process.
Whether the definition of the software process for a project is arrived at by adapting a CPF, or is developed afresh, it should be suitable for the project and should aim at building a high-quality product by following good software engineering practices.

Introducing processes

Once the software processes are defined, they need to be implemented successfully in an organization.
It is important to start with the implementation of simple processes that are practical and easy to understand because people take time to adjust to the use of processes. Complex and elaborate processes could be burdensome and discourage people from using processes.
After ensuring basic process discipline, the processes should be improved to produce better-quality products. Process improvement means making processes more effective. It is not synonymous with increased complexity and volume. Instead, it simplifies a process that is too cumbersome or impractical.

Need for process improvement

Now that you have some idea about processes, let us discuss the need to improve processes.
Processes should be assessed to find out how effective they are in producing high-quality software. They need to be improved continuously so that the quality of the products also keeps improving.
Organizations also need to improve processes to cater to the changing business environment, the technology, and customer expectations and needs. This enables them to continue building products that meet customer requirements. If processes remain static, they will not suffice in the face of the changes happening all around.

Making processes mature

Process improvement aims at making processes more 'mature'. If software engineering is to be adopted by an organization, a mature software process must be developed and implemented throughout all the software projects.

In a qualitative sense, the term, mature means that the process:

• Is appropriate for the work to be performed
• Addresses the best practices in software engineering
• Results in a high-quality product
• Is documented so that all the staff members have access to it
• Is understood and accepted by all people doing software work
• Makes projects easier to manage and control

Objectives of process improvement

Virtually every process can be improved. Each process element can be 'tuned' to cope with the changing requirements to help produce better-quality products. The objective of process improvement is to:

• Eliminate problem areas
• Improve efficiency and flow
• Eliminate redundancy and unnecessary work
• Increase the level of acceptance and usage
• Improve the elements that make up the process

Process improvement requires a cultural change, which is never easy in any organization. Therefore, process improvement is often resisted when it is introduced and also when it is in-progress.

Let us look at some of the approaches that organizations follow for process improvement.

Process improvement approaches

Organizations vary in the way they perceive the need for process improvement and in the way they address this need. The approaches used can be broadly categorized as given below.

• The denial approach
• The dictatorship approach
• The chaos approach
• The common sense approach

Let us now discuss each of the above-mentioned approaches.

The denial approach

In the denial approach, the organization simply denies the fact that any improvement is needed!
In such an organization, the management feels that everything is going fine and nothing really needs to change. This ostrich-like behavior of burying the head in the ground ensures that there is status quo in the organization.
An organization that follows the denial approach is unable to adapt to the changing business environment and customer requirements. Therefore, it starts facing severe problems.

The dictatorship approach

In this approach, a senior manager decides that things will change and specifies them by using authority. The software engineers are expected to do whatever the senior manager specifies because of the authority wielded by the manager.
This approach is usually unsuccessful because ultimately, the changes have to be made by the software engineers. They often resist imposed changes, which results in the failure of the approach.

The chaos approach

In some organizations, the best way to affect change is to allow the software engineers to decide and implement the changes themselves.
While this approach may work at times, it can also lead to chaos. For example, the engineers may assume that all the problems being faced can be solved by the use of new technologies. Based on this belief, they take a 'ready-fire-aim' approach to the acquisition and implementation of new technologies. However, new technologies are not always the best solution to process-related problems.
In the chaos approach, once a new technology is acquired and implemented, it is usually difficult to revert or re-orient the process as once you 'pull the trigger', it is difficult to redirect the bullet.

The common sense approach

This is a practical and systematic approach that involves all the people within the organization and results in effective process improvement. A common sense approach to process improvement does not rock the boat or cause trouble.
The software engineers are often overworked and under-appreciated. Introducing changes in the existing processes requires a cultural shift. This means that any improvement of the software engineering processes must be introduced in a manner that provides immediate benefit and does not appear as additional work

Identifying process improvement areas

Process improvement is driven by past experience. Here are some questions that help to understand the effectiveness of existing processes and identify the process improvements that are required.

• What quality problems have been encountered in recent projects?
• What kind of feedback is being received from customers?
• What do software engineers and managers have to say about the current processes? What do they like? What do they dislike?
• What cost and schedule issues have been encountered in recent projects?
• What metrics have been collected and what do they indicate about the processes?
• Which of the software engineering activities and tasks have worked well, and which of them have been problematic?
• Which work products provide short-term or long-term benefits? Which don't?
• Are the existing processes being followed uniformly across all projects?
• Can project managers control projects well using the existing process?

Cyclical Model for Software Process Improvement

Introduction

In order to build high-quality software products, it is necessary to use processes that are mature and capable. It is, therefore, important to know how to improve software processes so that the quality of the products can be improved.
Software process improvement is an on-going iterative process, because improvement is always possible.
Successful process improvement requires organizational commitment, resources, and a planned and systematic approach.
In this section, we will discuss a generic model for process improvement, which is cyclical in nature and has six steps.

Process improvement

Process improvement is cyclical because it is a continuous and ongoing process. For example, we check the current state of a process based on what we require. Then, we make some improvement in the process and evaluate whether the new process is effective. This set of activities can be repeated on an ongoing basis, resulting in continuous improvement.
Typically, each improvement cycle aims at a small chunk of improvement that will be accepted by the people within the organization comfortably and will take the organization a step forward. For a major improvement or change, many such incremental improvement steps are required.
There are various models available for process improvement, all addressing the same set of activities. However, the models may have different steps.
Let us look at the steps involved in the generic model for process improvement.

The six-step generic cyclical model for process improvement

There are six steps in the generic model for process improvement. These are as listed below.

1.     Process assessment: Understanding where we are

2.     Education: Educating people to sell the idea and imparting the required skills

3.     Selection: Selecting suitable processes, methods, and tools

4.     Justification: Justifying the cost and effort required for process improvement

5.     Installation: Performing the process improvement activities

6.     Evaluation: Evaluating the effectiveness of the improved process

Let us understand each of these steps in detail.

Process assessment

The first step in the generic model for process improvement is process assessment. Process assessment is necessary because it helps us understand where the organization stands with regard to its processes and helps us assess which areas in its processes need improvement.
Process assessment focuses on both strengths and weaknesses in the existing processes. While deciding on the improvements, areas of weakness are prioritized. Improvement efforts are focused on areas with the highest immediate priority. In many cases, improvement efforts build on existing strengths.
Assessment can be likened to taking a 'look in the mirror'— to do an objective examination of a process and to understand its strengths and weaknesses. The assessment gives an indication of the process maturity of the organization and provides the basis for developing the process improvement plan.
Process maturity gives an indication of how good or mature a process is. Software Engineering Institute (SEI) defines software process maturity as 'the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective'. Let us listen to an explanation and understand what this statement implies.

Our intent is to examine the existing software process, to determine where strengths and weaknesses lie, and from them, to develop an effective process improvement plan. First stage, process assessment, should be an objective examination of the current state of software development or software engineering practices. It should, unquestionably, be an indication of where you are strong and where you are weak, both in process issues and in technology issues. It will, if properly conducted, give you an indication of your software engineering process maturity, and finally, it is, in effect, a start towards developing an effective process improvement plan. It is not a goal in and of itself. Software process assessment is an effective start, and when done properly, it often leads to a definition of what is called software process maturity.

Process assessment models

Process assessment is done using a model. The choice of the model depends on what the organization wants to achieve internally as well as what it needs to show to its customers in terms of process capability. Process capability gives an indication of what to expect from the process.
The model selected should be one that gives the organization sufficient input for future actions. It should be relevant and understandable. If the demonstration of process capability to customers is important, the model chosen should be one that the customers understand and value.
A useful model for performing process assessment is Software Engineering Institute's Software Capability Maturity Model^® (Software CMM^®). The model has five maturity levels that represent different stages of process maturity. Another model that can be used for process assessment is, ISO 9001:2000.

Process assessment report

The outcome of process assessment is the preparation of an 'assessment report', containing the following items.

• Findings: These are the direct factual findings associated with the existing process and are derived using means such as questionnaires, meeting with software engineering teams, and assessment of software work products.
• Impact: This is the impact of the findings on project work, product quality, and overall team activities. Impact is assessed for each finding and the person assessing it must have significant experience in software engineering.
• Recommendations: These are actions suggested to address the findings, and thereby, improve the process. They are often stated in a form that later translates into a process improvement plan.

Levels of process assessment report

The assessment report is valuable because it is very useful for planning the future actions for process improvement. The report is often presented at two levels as given below.

• Summary findings: The summary findings rate the overall process maturity of the organization. Depending on the model used, this rating could be a simple pass or fail as used in ISO 9001:2000 or it could be a grading such as the five grades of the maturity levels in Software Engineering Institute's CMM^®.

Detailed findings: The detailed findings help in understanding the strengths and weaknesses of processes. This in turn helps in identifying what needs to be done to improve the processes. The detailed findings are also used to derive the summary findings along with the impact and recommendations. 

Project characteristic: Project type

Most software projects belong to one or more of the following generic project types.

• Concept development projects
• New application development projects
• Application enhancement projects
• Application maintenance projects
• Re-engineering projects
• Web application development projects

Project characteristic: Degree of rigor

Software projects differ in the required degree of formality, that is, the relative degree of formality with which software engineering tasks will be conducted.
For a short-lived software product that will be used by a limited number of people and is of relatively low business criticality, a casual approach to software engineering may be appropriate.
On the other hand, for a software product that is business-critical, expected to have a long life, likely to undergo many changes, and be used by hundreds or thousands of people, a strict approach to software engineering is indicated.
The four broad categories for the degree of rigor are casual, structured, strict, and quick reaction.
Let us see how these categories impact the adaptation of the CPF.

Adapting the CPF depending on the degree of rigor

There are four broad categories of the degree of rigor that are followed to select a task set. These are:

• Casual: In this category, the minimum tasks are used and documentation requirements are reduced. It is ensured that the basic principles of software engineering are applied.
• Structured: In this category, the tasks necessary to ensure high quality are applied. SQA, SCM, documentation, and measurement are implemented in a streamlined manner.
• Strict: In this category, the tasks are chosen to ensure the degree of discipline required for high quality. Robust documentation is produced.
• Quick reaction: In this category, an emergency-like approach is used and only the tasks that are essential for maintaining good quality are selected. This approach uses 'back-filling' (for example, developing complete documentation and conducting additional reviews) after delivering the product to the customer.

APM: Adaptation criteria

The APM uses ratings for a set of adaptation criteria to determine the recommended degree of rigor. It defines the following adaptation criteria.

• The size of the project
• The number of potential users
• Mission-criticality
• Application longevity
• The stability of the requirements from external customer
• Ease of communication between customers and developers
• The maturity of the applicable technology
• Performance constraints
• Embedded and non-embedded characteristics
• Project staffing
• Interoperability
• Re-engineering factors

Adaptation criteria: Applicability

The adaptation criteria applicable to a project depend on the project type. For example, for a 'concept development' project, the APM suggests using four of the eleven adaptation criteria. These are:

• Ease of communication between the customer and the developer
• Maturity of the applicable technology
• Embedded and non-embedded characteristics
• Project staffing

While adapting the APM, the project type is used to decide the applicable adaptation criteria. These criteria are then graded and given weights to determine the degree of rigor.

Let us see how the applicable adaptation criteria are graded.

Adaptation criteria: Grading

In the APM, each adaptation criterion is assigned a grade that ranges between 1 and 5.
The value, 1, represents a project that requires fewer tasks and in which the overall methodological and documentation requirements are minimal. This implies the lowest degree of rigor required.
The value, 5, represents a project that requires a larger number of tasks and in which the overall methodological and documentation requirements are also substantial. This implies the highest degree of rigor required.
To determine the appropriate grade for each adaptability criterion, a suggested set of project characteristics is provided. It is important to note that there is an overlap between these project characteristics.

An example of grading an adaptation criterion

Let us consider the size of the project as an example of an adaptation criterion.
The size of the project is an adaptation criterion because it impacts the degree of rigor of a project. We can estimate the size of a project in terms of the work units, such as person months, or in terms of product units, such as the number of lines of code (LOC) to be generated.
The given table shows the grades and characteristics of the size of the project used in the APM. The grades range from 1 (requiring the least rigor) to 5 (requiring the highest degree of rigor).

Grade	Characteristics
1	Less than 3 person months and/or 3,000 LOC (30 function points)
2	Between 3 and 9 person months and/or 3,000 and 6,000 LOC (30 to 60 function points)
3	Between 6 and 12 person months and/or 5,000 and 20,000 LOC (50 to 200 function points)
4	Between 9 and 24 person months and/or 10,000 and 30,000 LOC (100 and 300 function points)
5	Between 18 and 48+ person months and over 25,000 LOC (250 function points)

Grades and corresponding characteristics

The tabulation of grades and characteristics of each APM adaptation criterion makes it easy for the project team to determine the grade corresponding to that criterion. Given below is a list of the APM adaptation criteria with their characteristics and the corresponding grades on a scale of 1 to 5.

• The size of the project
• The number of potential users
• Mission-criticality
• Application longevity
• The stability of the requirements from external customer
• Ease of communication between the customer and the developer
• The maturity of the applicable technology
• Performance constraints
• Embedded and non-embedded characteristics
• Project staffing
• Interoperability
• Re-engineering factors

Adaptation criteria: Weights

In addition to providing a grade for each applicable adaptation criterion, a 'weight' is also assigned to each criterion.

The weight provides an indication of the relative importance of the criterion in determining the required degree of rigor. The weight can range from 0.8 to 1.2.

Therefore, the impact of an adaptation criterion on the TSS depends on the following two values.

• Grade (1 to 5, with 1 requiring least rigor and 5 the most)
• Weight (0.8 to 1.2, with 0.8 implying that the criterion is less important and 1.2 implying that it is more important)

Let us now look at the steps involved in the TSS computation.

Adaptation criterion	Grade (1 to 5)	Weight (0.8 to 1.2)
Ease of communication
Maturity of technology
Embedded and non-embedded
Project staffing

Computing the TSS

The APM uses the following steps to compute the TSS and obtain the degree of rigor.

1.     Compute the product of the grade and the weight (grade * weight) for each applicable adaptation criterion.

2.     Compute the TSS as the average of this product for all the adaptation criteria.

Let us now find out how the APM uses this computed TSS value to arrive at a suggested degree of rigor.

Selecting a task set

The selected degree of rigor is used to finally choose the recommended task set. The given table depicts the degree of rigor based on the TSS value.
Note that the range of TSS values corresponding to one degree of rigor overlaps the range for another degree of rigor. This overlap illustrates that sharp boundaries are impossible to define when selecting a task set.
The choice of the recommended task set takes into account the TSS value, past experience, and common sense.

Task set selector value	Task set category
TSS < 1.2	Casual
1.0 < TSS < 3.0	Structured
TSS > 2.4	Strict

Adapting a CPF

The APM implements a CPF to provide a generic process framework and a user-friendly way to adapt it based on the characteristics of a project. It allows users to change the recommended task set.

The organizations that consider using an available implementation of the CPF should ensure that the following are suitable for all its projects.

• The set of framework and umbrella activities
• The collection of task sets described for the framework and umbrella activities
• The method of specifying the project characteristics for adapting the CPF

The adaptation guidelines should be simple and should capture the best practices for using the project characteristics to select the recommended task set. In addition, the CPF implementation should be flexible enough so that project teams can override recommendations and fine-tune the task sets as required.