Tag: Information technology management

Process Area Capability Maturity Model Integration (CMMI)

The Capability Maturity Model Integration (CMMI) defines a Process Area as, “A cluster of related practices in an area that, when implemented collectively, satisfies a set of goals considered important for making improvement in that area.” Both CMMI for Development v1.3 and CMMI for Acquisition v1.3 identify 22 process areas, whereas CMMI for Services v1.3 identifies 24 process areas. Many of the process areas are the same in these three models.

In CMMI models, the process areas are organized in alphabetical order according to their acronym. However, process areas can be grouped according to maturity levels or process area categories.

There are Five maturity levels. However, maturity level ratings are awarded for levels 2 through 5. The process areas below and their maturity levels are listed for the CMMI for Development model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

The process areas below and their maturity levels are listed for the CMMI for Services model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined (this includes the process areas that make up the previous levels; Maturity Level 3 is made up of the process areas in Level 2 and Level 3)

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

The process areas below and their maturity levels are listed for the CMMI for Acquisition model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

There are two categories of goals and practices: generic and specific. Specific goals and practices are specific to a process area. Generic goals and practices are a part of every process area. A process area is satisfied when organizational processes cover all of the generic and specific goals and practices for that process area.

Generic goals and practices are a part of every process area.

Each process area is defined by a set of goals and practices. These goals and practices appear only in that process area.

CMMI for Development, Version 1.2 contains 22 process areas indicating the aspects of product and service development that are to be covered by organizational processes. For a summary of process areas for each model, see these quick reference documents available on the SEI website:

Purpose

The purpose of Agreement Management (AM) is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement.

Specific Practices by Goal

Purpose

The purpose of Capacity and Availability Management (CAM) is to ensure effective service system performance and
ensure that resources are provided and used effectively to support service requirements.

Specific Practices by Goal

Purpose

The purpose of Causal Analysis and Resolution (CAR) is to identify causes of selected outcomes and take action to improve process performance.

Specific Practices by Goal

Purpose

The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

Specific Practices by Goal

Purpose

The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

Specific Practices by Goal

Purpose

The purpose of Integrated Project Management (IPM) is to establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes.

Specific Practices by Goal

Purpose

The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability used to support management information needs.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets, work environment standards, and rules and guidelines for teams.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of current strengths and weaknesses of the organization’s processes and process assets.

Specific Practices by Goal

Purpose

The purpose of Organizational Performance Management (OPM) is to proactively manage the organization’s performance to meet its business objectives.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Performance (OPP) is to establish and maintain a quantitative understanding of the performance of selected processes in the organization’s set of standard processes in support of achieving quality and process performance objectives, and to provide process performance data, baselines, and models to quantitatively manage the organization’s projects.

Specific Practices by Goal

Purpose

The purpose of Organizational Training (OT) is to develop skills and knowledge of people so they can perform their roles effectively and efficiently.

Specific Practices by Goal

Purpose

The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, behaves properly (i.e., possesses the required functionality and quality attributes), and deliver the product.

Specific Practices by Goal

Purpose

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.

Specific Practices by Goal

Purpose

The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

Specific Practices by Goal

Purpose

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.

Specific Practices by Goal

Purpose

The purpose of the Quantitative Project Management (QPM) process area is to quantitatively manage the project to achieve the project’s established quality and process performance objectives.

Specific Practices by Goal

Purpose

The purpose of Requirements Development (RD) is to elicit, analyze, and establish customer, product, and product component requirements.

Specific Practices by Goal

Purpose

The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

Specific Practices by Goal

Purpose

The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

Specific Practices by Goal

Purpose

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers.

Specific Practices by Goal

Purpose

The purpose of Technical Solution (TS) is to select design and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product related lifecycle processes either singly or in combination as appropriate.

Specific Practices by Goal

Purpose

The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

Specific Practices by Goal

Purpose

The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.

Specific Practices by Goal

Only changes made to the set of Process Areas are considered here. For more information about the changes made to Version 1.2, see the Version 1.2 Release Notes or for the definitive list of changes, take the CMMI Version 1.2 Upgrade Training.

Some significant improvements in CMMI-DEV, V1.3 include the following:

For a more complete and detailed list of improvements, see http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/comparison.cfm. An overview of the changes is described in http://www.benlinders.com/2011/cmmi-v1-3-summing-up/.

Table: Process Areas, Categories, and Maturity Levels

Get More PRINCE2 Information by Clicking HERE

Project Portfolio Management (PPM)

Prince2 Certification
Image by/from Kokcharov

Project Portfolio Management (PPM) is the centralized management of the processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage current or proposed projects based on numerous key characteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organization’s operational and financial goals, while honouring constraints imposed by customers, strategic objectives, or external real-world factors. The International standard defines the framework of the Project Portfolio Management

PPM provides program and project managers in large, program/project-driven organizations with the capabilities needed to manage the time, resources, skills, and budgets necessary to accomplish all interrelated tasks. It provides a framework for issue resolution and risk mitigation, as well as the centralized visibility to help planning and scheduling teams to identify the fastest, cheapest, or most suitable approach to deliver projects and programs. Portfolio Managers define Key Performance Indicators and the strategy for their portfolio .

Pipeline management involves steps to ensure that an adequate number of project proposals are generated and evaluated to determine whether (and how) a set of projects in the portfolio can be executed with finite development resources in a specified time. There are three major sub-components to pipeline management: ideation, work intake processes, and Phase-Gate reviews. Fundamental to pipeline management is the ability to align the decision-making process for estimating and selecting new capital investment projects with the strategic plan.

The focus on the efficient and effective deployment of an organization’s resources where and when they are needed. These can include financial resources, inventory, human resources, technical skills, production, and design. In addition to project-level resource allocation, users can also model ‘what-if’ resource scenarios, and extend this view across the portfolio.

The capture and prioritization of change requests that can include new requirements, features, functions, operational constraints, regulatory demands, and technical enhancements. PPM provides a central repository for these change requests and the ability to match available resources to evolving demand within the financial and operational constraints of individual projects.

With PPM, the Office of Finance can improve their accuracy for estimating and managing the financial resources of a project or group of projects. In addition, the value of projects can be demonstrated in relation to the strategic objectives and priorities of the organization through financial controls and to assess progress through earned value and other project financial techniques.

An analysis of the risk sensitivities residing within each project, as the basis for determining confidence levels across the portfolio. The integration of cost and schedule risk management with techniques for determining contingency and risk response plans, enable organizations to gain an objective view of project uncertainties.

In the early 2000s, many PPM vendors realized that project portfolio reporting services only addressed part of a wider need for PPM in the marketplace. Another more senior audience had emerged, sitting at management and executive levels above detailed work execution and schedule management, who required a greater focus on process improvement and ensuring the viability of the portfolio in line with overall strategic objectives. In addition, as the size, scope, complexity, and geographical spread of organizations’ project portfolios continued to grow, greater visibility was needed of project work across the enterprise, allied to improved resource utilization and capacity planning.

Enterprise Project Portfolio Management (EPPM) is a top-down approach to managing all project-intensive work and resources across the enterprise. This contrasts with the traditional approach of combining manual processes, desktop project tools, and PPM applications for each project portfolio environment.

The PPM landscape is evolving rapidly as a result of the growing preference for managing multiple capital investment initiatives from a single, enterprise-wide system. This more centralized approach, and resulting ‘single version of the truth’ for project and project portfolio information, provides the transparency of performance needed by management to monitor progress versus the strategic plan.

The key aims of EPPM can be summarized as follows:

A key result of PPM is to decide which projects to fund in an optimal manner. Project Portfolio Optimization (PPO) is the effort to make the best decisions possible under these conditions.

Acquisition Initiation Within the Information Services Procurement Library (ISPL)

Uncategorized
Image by/from User:Mcalukin of the English Wikipedia

Acquisition Initiation is the initial process within the Information Services Procurement Library (ISPL) and is executed by a customer organization intending to procure Information Services. The process is composed of two main activities: the making of the acquisition goal definition and the making of the acquisition planning. During the acquisition initiation, an iterative process arises in which questions about the goal of the acquisition are usually asked. In response to these questions the Library provides details of the requirements, covering areas such as cost, feasibility and timelines. An example of such requirements is the “planning of the acquisition”, a component that may also lead to more questions about the acquisition goal (thus, it is reasonable to state that a relationship exists between the acquisition goal and the acquisition planning).

The process-data model shown in the following section displays the acquisition initiation stages. It shows both the process and the data ensuing from the process, and parts of the image will also be used as references in the body of this article. The concepts and data found in the model are explained in separate tables which can be found in the section immediately following the model. A textual, and more thorough, explanation of the activities and concepts that make up the Acquisition Initiation process can be found in the remainder of this article.

The draft acquisition goal is the description of the global goal that is to be achieved by starting procurement. It is inspired by the business needs or business strategy. It is similar, though simpler, to the concept of the project brief in PRINCE2. It is the first draft of the acquisition goal, containing at least a (short) problem definition and a (short) goal definition. The draft acquisition goal is meant to give the main reasons and the main goals to those people who will have to make the decision to actually start of the acquisition or not. It may thus also encapsulate items like a cost-benefit analysis, stakes & stakeholders and other items that will be further refined during the actual Acquisition Initiation.

It is, in this sense, not an activity of the acquisition initiation process, but it is the input for starting the process.

The problem definition is a statement about the problem that could be resolved by starting the acquisition process.

The goal definition is a statement about the goal that will have to be reached when the acquisition is executed:

The draft acquisition goal can be made as short or as long as is needed by the organization, as long as it serves to be a good basis to make the initial decision to start of an acquisition process.

When the decision is made to start an acquisition process, the first activity of the acquisition initiation is to define the acquisition goal.

The acquisition goal is the whole of defined systems and services requirements, attributed by costs & benefits and stakes & stakeholders, with a defined target domain serving as the boundary. The acquisition goal is the basis of the acquisition process and for formulating the acquisition strategy during the acquisition planning. Input can be the draft acquisition goal and the business needs (of the target domain). The business needs can be derived from strategic business plans or information system plans.

The target domain is that part of the customer organization that is involved in, or influenced by an information service. It is defined in terms of business processes, business actors, business information, business technology and the relations between these four aspects. The target domain is identified to ensure a fitting acquisition goal with fitting requirements for the systems and services to be acquired.

A limited description of a target domain can thus be, for example:The part of customer organization that uses the software program MarketingUnlimited (fictional), involving the marketing-process, several types of information related to the marketing-department of the customer organization, the employees working in the marketing department and the production platform for MarketingUnlimited consisting of an application server, several workstations, and tools related to MarketingUnlimited.

The acquisition goal is then described by system descriptions and service descriptions:

Other information on how ISPL defines the deliverables of the acquisition can be found in the general ISPL entry.

Cost-benefit analysis concerns the analysis of:

to successfully evaluate the investment issues of the acquisition.

It is important to identify all actors affected, and in what way they are affected (their stake), because a negative attitude of actors may negatively influence the success of the acquisition. ISPL proposes to perform a SWOT analysis (Strengths, Weaknesses, Opportunities and Threats) for the actors involved to properly and thoroughly identify the stakes of the actors. The results of this analysis can serve as input for the situation & risk analysis.

The information contained within the Acquisition Goal is used to produce the acquisition plan. The acquisition plan is the master plan of the entire acquisition. In this plan, delivery scenarios are determined and the situation and risks are evaluated. Based on the scenarios, situations, and risks, a strategy is formed to manage the acquisition. Furthermore, the acquisition plan will hold the main decision points, in which decisions are made about the deliverables within the acquisition and the acquisition organization (similar to a project organization) is formed.

On the basis of the acquisition goal, which contains among others the systems and services requirements and descriptions, scenarios can be formed for the deliveries of the information services to be acquired. Multiple scenarios may be built, which will then be evaluated and used in the design of the acquisition strategy. The scenarios are built with the priorities and interdependence of the deliverables in mind.

Priorities are related to the importance of each delivery: which delivery has time-preference over another.

Some deliveries may be dependent on each other, requiring one services to be delivered before the next one can be.

Example:

During a project to make ISPL more specific for generic product software implementations, a number of scenario’s were made. One of these was for an approach of a one-shot implementation. The below picture shows a diagram of the scenario that was made. An example of a scenario for the implementation of software is shown in the thumbnail on the right.

In this example, the general deliverables within an implementation of software are mentioned, executed and delivered differently as time goes by, mainly because of dependencies between deliverables. For instance, the actual go for the delivery of the software and the other related deliverables are dependent on the outcome of the deliverable “Proeftuin”. “Proeftuin” is an agreed period in which the software is extensively tested by the customer organization, provided and supported by the supplier. The customer organization can get a feel for the use of the software in the target domain, to guarantee that the software is a “fit” within the organization.

ISPL adheres to a situational approach to manage an acquisition. The situational approach takes into account properties of the problem situation, which are called situational factors. ISPL provides a number of these situational factors. Some of these situational factors affect events that have adverse consequences: the risks. Thus, the situational factors and risks within ISPL are related to each other. This makes it possible to provide a number of heuristics on which factors have an influence on certain risks.
First the situation is analysed, then ISPL proposes a number of risks which may arise from the situation at hand. With this information, an acquisition strategy can be formed to mitigate both the situation and risks in a number of areas.
Other information of the situation & risk analysis of ISPL can be found in the ISPL entry.

The acquisition strategy within ISPL acts as the design of a risk management strategy. The risk management strategy provides choices for options that reduce the probability and/or effect of risks. ISPL provides several options, divided over four classes:

Options are chosen based on their efficiency, costs and the related delay for delivery.

Based upon all the previous activities, the decision points planning is made. This is a time-set planning of decision points.

A decision point is described by:

An example of a decision points planning can be found through the thumbnail on the right. In this planning the decisions points are planned through time (top to bottom, left to right). This planning was taken from a study to make ISPL more specific for product software implementations. The decision points planning is thus aimed at a part of the process of a software implementation.

A shortened example of a decision point description can be found in the image below. This description was taken from the same study to make ISPL more specific for product software implementations.

The acquisition organization is set, which is similar to a project organization. Although the acquisition organization is more focused on the (legal) relationship that it has to maintain with the supplier organization.