3.6 Summary

3.6 Summary

Chapter 3 introduced the processes necessary to coordinate and support project work and assigned responsibility for them to a new line function, the PO. In practice this framework, like any other framework, must be tailored to the needs and culture of the organization in which it is going to be deployed; this can be done through the use of a responsibility matrix in which the key decisions that must be made through the life of a project are listed and responsibility for them assigned to the various stakeholders.


  1. Archibald, R. D., Managing High-Technology Programs and Projects, 2nd ed., New York: Wiley, 1992.

  2. Goldratt, E. M., and J. Cox, The Goal: A Process of Ongoing Improvement, 2nd rev. ed., Great Barrington, MA: North River Press, 1992.

  3. Capability Maturity Model Integration for Systems Engineering and Software Engineering (CMMISM), Version 1.1,Software Engineering Institute, 2001.

  4. Meyer, M. H., and A. P. Lehnerd, The Power of Product Platforms: Building Value and Cost Leadership, New York: Free Press, 1997.

  5. Reinertsen, D. G., Managing the Design Factory: A Product Developer's Toolkit, New York: Free Press, 1997.

Chapter 4: Processes


Common processes provide the foundation upon which the PO operates. A multiproject environment requires the establishment of common processes for a variety of reasons: First and foremost, they provide the common language indispensable to communication across projects and disciplines and they facilitate the training and integration of new personnel. Second, processes capture the collective knowledge developed through the experience and insight of the PO staff. Third, commonality is essential for the effective use of forecasting models, tools, and databases.

Processes and tools are intertwined. Processes to a large extent determine the choice of tools, but in order to take advantage of a powerful tool, processes that do not provide a definitive benefit must be changed. Both processes and tools are embodiments of the collective knowledge of the organization, and as such their value as a competitive advantage must not be underestimated. As the organization learns, processes, practices, and tools must be changed to reflect new understandings and insights.

In the previous chapter we introduced the main PO processes and interfaces, and the roles necessary to execute them. This chapter will discuss the goals that these processes must achieve and how they can be described.[1] The next chapter will deal with the tools required.

[1]This chapter will discuss the control arrow labeled "process definition" in the Chapter 3 diagrams. Chapter 5 will address the mechanism arrow labeled "information system services".

4.1 PO process definitions

In the previous chapter, we recommended that the PO owns those processes that clearly fall under its area of responsibility and those that enable it to stay in the loop; that is, those processes by means of which it is decided which projects will be initiated, what changes must be made to the project scope, and how time and expenses will be reported. Its involvement will prevent the PO from being bypassed in these important decisions. Some of these processes might involve adaptations to the project work derived from more general corporate processes, such as purchasing or budgeting.

Process descriptions ought to be written at different levels of detail and using different formalisms. For example, processes like the project portfolio management process, which need to express the flexibility required at the business level, are better served by a description of the policies to be considered in selecting and prioritizing projects than by a prescriptive, step-by-step decision procedure. The opposite is true when it comes, for example, to the CM process. The level of detail present in any process description should be limited to what is needed to achieve the organizational goal of commonality, while preserving the flexibility needed to run projects effectively and efficiently. Overly detailed corporate processes are a barrier to learning and innovation. Table 4.1 presents a process architecture based on these ideas.

Table 4.1: Process Architecture

Process Description



Project life-cycle management

Project formulation
Project startup
Project execution
Project closure
Project reviews
Tollgate reviews

Project auditing
Risk and opportunity management
Quality assurance

Project portfolio management

Project portfolio planning
Project oversight
Project portfolio control

Risk and opportunity management


Production of rough and
refined estimates





Requirements management

Change management


Risk and opportunity management



Project audit



Quality assurance

Evaluation of work products and process compliance
Communication and resolution of noncompliance issues
Maintenance of quality records

Project audit

Procurement management

Market survey
Procurement specification
Capability evaluation and quality assurance
Procurement close-out


Project accounting
Validation of expenses
Transaction analyses
Posting of entries to GL, AP, AR


Measurement process

Planning of measurement
Performing of measurement
Production of performance statistics


Configurations management

Change management


Human-resources management

Workforce planning
Work environment
Performance management
Career development
Coaching and mentoring





Process management

Identification of process constraints
Minimization of constraints
Deployment of process improvements


4.1.1 Project life-cycle management

The project life-cycle management process defines how projects are formulated, planned, executed, and closed. Specifically, this process defines the following:

  • How projects are to be organized and controlled;

  • Standardized work breakdown structures and activities;

  • Which project elements should be reviewed before work is authorized to proceed.

The goals of this process are as follows:

  • To establish a common vocabulary known to all stakeholders, which enables the use of common tools and reporting routines and the sharing of knowledge across the organization;

  • To define the interfaces among the various parties involved in a project.

In order to exercise business control over the project, its life cycle will be divided into phases (see Table 4.2), with well-defined checkpoints or tollgates at which the decision to continue or stop the work is formally reviewed. Decisions about the continuation, termination, or change of direction concerning the project work are made by the project's steering committee (see Figure 4.1), made up of senior management, the project sponsor, the PO manager, and the project manager.

click to expand
Figure 4.1: Roles in project life-cycle management.

Table 4.2: Project-Management Model







To understand the scope of the project and produce order-of-magnitude estimates necessary for evaluating its feasibility

To produce the detailed plans necessary for project execution

To execute the project as planned with respect to time, cost, quality, and scope

To hand over the results, dismantle the project organization, compile a record of all experiences, and bring to a close all outstanding matters


Customer or sales requirements
Business case

Project charter
Historical data
Applicable standards

Project specification
Applicable standards

Project deliverables
Team feedback
Customer feedback


Establish scope of work
Define work approach
Produce order-of-magnitude estimates
Evaluate risks
Confirm scope of work
Produce budgeting estimates
Produce detailed plans
Evaluate risks

Conduct kickoff meeting
Authorize work
Monitor progress and expenditures
Update plans
Communicate project status

Hand over results
Document unresolved issues
Participate in postmortem reviews
Dismantle team
Thank those involved



Project charter

Project specification

Project deliverables

Lessons learned
Updated records



Depending on the duration of the project, there might be more than one tollgate during execution



The business case remains current
The expected project results are in accordance with company strategy
The expected project results justify its cost

The business case remains current
The expected project results are in accordance with company strategy
The expected project results justify its cost

The business case remains current
The expected project results are in accordance with company strategy
The expected project results justify its cost

All handover has been performed
All accounts are closed


The selected approach is feasible
Scope of work

The selected approach is feasible
Requirements stability
Risk identification

The selected approach will produce a system that meets expectations
Progress is being made according to the plan
Requirements stability
Risk identification

The results meet expectations
Final report is written

Use of resources

There are enough resources to execute the project

There are enough resources to execute the project

Staff and equipment availability
Resources are consumed according to the plan
Estimates to complete are within limits


When it comes to defining standardized phases and work breakdown structures (WBS) for the purpose of establishing common reporting routines, a balance must be struck between the need for commonality and the uniqueness of the project work. As shown in Figure 4.2, the push for standardization should not exceed the level of visibility needed by the PO or any other project stakeholder, leaving to the project team the freedom to further adapt their activities, within the prescribed categories, according to their own needs and idiosyncrasies.

click to expand
Figure 4.2: Standardized WBS. (After: [1].)

Project reviews are an important component of the project life-cycle process. A project review should not be confused with a project audit. A project review is a planned risk-reduction activity; a project audit, on the other hand, is an activity imposed on the project when the circumstances, usually bad, mandate. The goals of the review are as follows:

  • To mitigate risk by finding problems before moving on to the next project phase;

  • To generate buy-in among the project's stakeholders;

  • To identify opportunities that might have been missed in the past.

In order to be effective, project reviews should be based on in-process and final work products, and not on materials generated especially for the review. A good practice is to use a questionnaire or checklist to guide the inquiry, similar to the one shown in Figure 4.3, and to follow up with the following queries [2]:

  • How do you know?

  • What does that mean?

  • Can you show me?

click to expand
Figure 4.3: Project review lines of inquiry concerning requirements, management, and work climate. (After: [3].)

During the review, any issues that could not be resolved within the project should be brought to the attention of the sponsor and the PO manager, and agreed-upon mitigation strategies for near- and long-term risks should be identified.

4.1.2 Project portfolio management

The purpose of project portfolio management is to advance the goals of the organization by making decisions that take into consideration all, rather than individual, projects that the organization intends to pursue. Principal considerations include the following:

  • Which combination of projects will maximize benefits?

  • Which will minimize risk?

  • Which will most closely align with the company's strategic goals?

  • Which projects need to be started and when?

  • Which ones need to be terminated?

Specifically, this process addresses the following:

  • How project requests are received and evaluated;

  • The criteria to be applied in deciding whether or not to incorporate or remove a project from the portfolio;

  • The preparation of the master plan, the strategic resource plan, the financial forecast, and the requirements dependency matrix;

  • How projects are started and terminated;

  • The leeway or margin of maneuver that the PO has in addressing deviations in the project portfolio.

Rather than defining painfully detailed procedures unlikely to be followed by senior management and project sponsors in their decision-making process, this process must clearly state the business and project information required to support well-thought-out portfolio decisions. It must also define the latitude, in terms of the projects' scheduling and effort windows, that the PO manager has in making decisions without approval from senior management and project sponsors. If there is little latitude and the PO manager is forced to go back to management and sponsors every time a decision needs to be made, the PO loses much of the reason for its existence.

Since the consequences of many of the decisions made at the portfolio level will take months or maybe years to be felt, it is critical that the process be supported by decision aids such as system dynamics [4] to evaluate the long-term consequences of decisions, the analytical hierarchical process [5] to help in the selection of projects based on multiple criteria, and Monte Carlo simulation techniques to deal with uncertainty [6]. These techniques and others for portfolio planning will be explained at length in Chapter 6.

4.1.3 Estimation

The estimation process defines the method or methods used to size and estimate the time and effort required to do a job. The estimates produced become the basis for project scheduling and resource allocation. Estimates are revisited throughout the project's life cycle, typically at major milestones or when significant changes to requirements or project constraints impose a revision of the original plans.

The estimation process involves the following:

  • Sizing the job;

  • Finding the cost drivers;

  • Forecasting the time and effort required;

  • Conducting sensitivity analysis.

The goals of this process are as follows:

  • To produce accurate estimates of the resources and time required to complete a given work element;

  • To have documented estimates that can be reviewed and scrutinized by others.

A thorough discussion of the estimating process would require a separate book. However, for our purposes we will focus on two key observations. The first is that estimates are invariably required before all the necessary information is available; the second is that no matter how much effort is put into an estimate, there will always be variances as a result of the number of variables that can influence the effort and time required to perform a task. Project work is after all a stochastic rather than a deterministic process. The corollary to these two assertions is that there will be multiple estimates along the life cycle of a project, each with different degrees of accuracy as a function of the information available (see Table 4.3), and that every estimate should be qualified with a probability statement (see Figure 4.4) that reflects the likeliness of achieving it. We will return to this in Chapter 6.

click to expand
Figure 4.4: Two projects with identical best-case (10 months) and most likely (15 months) duration scenarios, but different worst-case duration scenarios (25 versus 40 months), have very different on-time probabilities (in the first project, the probability of finishing within or before 15 months is 34%, and in the second, it is 18%).

Table 4.3: Different Types of Estimates


Type of Estimate

Level of Detail (WBS level of decomposition)

Estimating Method

Accuracy (%)

Feasibility, prestudy

Order of magnitude


Parametric, analogy, paired comparisons




2, 3

Successive principle, analogy, parametric, Paired comparisons




4, 5, 6

Successive principle, engineering buildup


4.1.4 Budgeting

The budget prepared by the PO is derived from the level of project activity that the organization is planning to sustain in the budgeting period. The budget will identify the source and destination of the funds administered by the PO. The structure associated with the budget process in shown in Figure 4.5.

click to expand
Figure 4.5: Budget structure.

Similar to the financial forecast described in Chapter 3, a budget is a plan expressed in monetary terms covering a specified period of time, usually 1 year. However, unlike the financial forecast, which is merely a prediction of what people think might happen used for decision-making purposes, the budget carries the implicit commitment of the PO manager and the project managers to take positive steps toward making sure that the budgeted events actually happen.

To keep the master plan and the budget consistent, the PO will maintain a rolling budget. This means that every quarter, a new budget will be prepared by dropping the amounts for the quarter just completed, reviewing the amounts for the succeeding three quarters, and then adding the amounts corresponding to the fourth succeeding quarter. The goals of the budgeting process are as follows:

  • To give the PO manager a say in major project decisions.

  • To delegate authority to project managers and PO manager, enabling them to spend budgeted funds without seeking approval.

  • To establish a yardstick against which the actual performance of the project managers and the PO manager will be measured.

Project managers are responsible for producing and administering the project budgets, while the PO manager prepares and administers the total budget and the management reserve. The rationale for putting the management reserve under the control of the PO manager instead of under the control of each project manager is that by spreading the risk across the portfolio, individual projects are afforded a given level of protection at a lower cost [7, 8]. This will be explained in detail in Chapter 6.

4.1.5 Requirements management

Requirements management involves establishing and maintaining an agreement between the project sponsor and the supplier organization. The agreement includes business, technical, and performance information about the work products that will be delivered as a result of the project work. The agreement forms the basis for estimating, planning, performing, and tracking project' activities. As new requirements are added or existing requirements deleted or modified, the project budget and its schedule are revised.

The requirements management process addresses the following:

  • Definition, documentation, and verification of the scope of work;

  • Requirements metadata (ancillary information that is an aid to understanding, prioritizing, and controlling the requirements);

  • Traceability between business cases, scope of work, and work products;

  • Handling of changes in the scope of the work.

The goals of this process are as follows:

  • To assure that there is a known baseline for engineering and management use;

  • To assist in the identification of items, whether business cases or work products, likely to be affected by a change.

In addition to the traditional practice of maintaining traceability between requirements and work products, the PO maintains traceability between requirements and between requirements and business cases (see Figure 4.6). The traceability between requirements enables the PO to evaluate the consequences to the rest of the portfolio of dropping or postponing the fulfillment of a requirement. The traceability between requirements and business cases allows the PO to determine which projects are likely to be affected in case the assumptions on which the business cases rest do not hold.

click to expand
Figure 4.6: Requirements management schema.

4.1.6 Risk and opportunity management

Traditionally, risk management in projects has been concerned with avoiding the risks that might jeopardize success from within the project. The portfolio approach, however, presents new possibilities. Today, the project portfolio approach opens the door to a different interpretation of risk management, an interpretation that, as in finance, reflects the connection between risk and returns. This new interpretation focuses not on avoidance, but on actively managing the risks that must be taken in the pursuit of opportunity and, ultimately, profit.

From the project perspective, the risk-management process establishes how project risks are evaluated, documented, and mitigated (see Figure 4.7). The risk-management process involves the following activities:

  • Risk planning: This is the up-front activity necessary to execute a successful risk-management plan. The planning should assign responsibility for specific risk-management functions and establish risk reporting and documentation requirements. Should the conditions in the project change drastically, it may be necessary to replan the riskmitigating actions.

  • Risk assessment: This activity includes the identification of critical issues that might have an adverse impact on the project, and an analysis to determine the likelihood of occurrence and its consequences. The riskassessment method is shown in Figure 4.8.

  • Risk handling: After the project's risks have been identified and assessed, the approach to handling each significant risk must be developed. There are essentially four strategies for handling risk: avoiding it, controlling it, transferring it, or assuming it. For all identified risks, the best strategy should be evaluated by looking at its feasibility, expected effectiveness, cost and schedule implications, and the effect on the system's technical performance.

  • Risk monitoring: This is the systematic tracking and evaluation of the performance of the risk-handling actions. Essentially, it compares predicted results of planned actions with the results actually achieved to determine status and the need for any change in risk-handling strategy.

click to expand
Figure 4.7: Risk-management process.

click to expand
Figure 4.8: Risk-assessment method. (After: Risk Management Guide for DoD Acquisitions, 4th Edition, Defense Acquisition University Press, Feb. 2001)

From a portfolio perspective, the PO must address two types of risks:

  1. Private or diversifiable risks (i.e., schedule slip, unreliable technology, staff turnover, misunderstood business);

  2. Market or nondiversifiable risks (i.e., economic health, competing standards, war).

The PO addresses private or diversifiable risks by spreading them across the project portfolio (for example, by charging insurance premiums proportional to the risk exposure of the projects). Risk spreading not only reduces the cost of capital, as the organization's immobilized capital is abridged and the need for last-minute funds is minimized, but could also be converted into a competitive advantage by using it in bidding work or by including price incentives in contracts. In order to work, the process must produce fair and consistent assessments of the true project risks. This could be achieved, for example, by applying risk taxonomies such as the ones presented in Tables 4.4 and 4.5, in combination with a quantitative assessment of the probability of occurrence of a given risk and its impact in monetary terms on the project budget.

Table 4.4: Risk as a Function of Technology Maturity





NASA's Technology Readiness Level (TRL)

Highest risk

Papers published, university originated tools

Synthesis and extraction

TRL1—Basic principles observed and reported


Books and commercial tools available (Release 1)

Biological screening and pharmacological testing

TRL2—Technology concept and/or application formulated


Books and commercial tools available (Release 2+)
At least one commercial product exists that uses the technology

Pharmaceutical dosage formulation and stability testing

TRL3—Analytical and experimental critical function and/or characteristic proof-of-concept


Industry and/or institutional standards start to be developed
Training becomes widely available

Toxicology and safety testing

TRL4—Component and/or breadboard validation in laboratory environment


Predominant design established

Investigational new drug (IND) application

TRL5—Component and/or breadboard validation in relevant environment


Phase I clinical evaluation

TRL6—System/subsystem model or prototype demonstration in a relevant environment


Industry and/or institutional standards are accepted

Phase II clinical evaluation

TRL7—System prototype demonstration in a space environment


Implementation feasibility is high
Technology is scaleable, replicable, and extensible

Phase III clinical evaluation

TRL 8—Actual system completed and "flight qualified" through test and demonstration (ground or space)


Process development for manufacturing and quality control
Bioavailability studies


New drug application (NDA)

TRL 9—Actual system "flight proven" through successful mission

Lowest risk

Technology vendors start to add "proprietary features" to the standard implementations (Release 3+)

Postapproval research

Table 4.5: Software Risk Taxonomy (After: [3])

Product Engineering

Development Environment

Program Constraints


Development process
    Process Control
    Product Control


    Hardware constraints
    Nondevelopmental software

Development system
    System Support

    Type of contract

Code and unit test
    Coding and Implementation

Management process
    Project organization
    Management experience
    Program interfaces

Program interfaces
    Associate contractors
    Prime contractor
    Corporate management

Integration and test

Management methods
    Personnel management
    Quality assurance
    Configuration management


Engineering specialties
    Human factors

Work environment
    Quality attitude


The tollgate model by which the project is authorized to proceed addresses the market or nondiversifiable risk arising from the uncertainty with respect to the project's payoff. By breaking down the development into phases, the tollgate model provides management with the flexibility to delay committing funds until the uncertainty is resolved at a minimum cost. Similar to a financial option, which management might exercise but is not obliged to if the circumstances are not favorable, at each tollgate management would decide whether to continue, kill, or redirect the project in response to new information not available at the beginning of the project. This greatly enhances the project's value by improving its upside potential while limiting its losses to the cost of the preceding project phases.

Project insurance and real option valuation will be explained in more detail in Chapter 6.

4.1.7 Project audits

The project audit process establishes the steps to be followed and the artifacts—documents and deliverables—to be inspected with the purpose of establishing the true and fair status of a project with the goal of independently assessing the extent to which the original business objectives could be achieved and the cost of recovery.

Despite their procedural similarity, reviews and audits are quite different. Reviews are scheduled activities, established with the purpose of finding inconsistency or missing items before they cause problems. Audits on the other hand are unplanned activities performed when a project has gone awry and it is necessary to conduct a major replanning before deciding on the continuation or termination of the project.

The audit should, at a minimum, consider the following:

  • Business situation;

  • Critical-path status;

  • Milestone hit rate;

  • Deliverables status;

  • Requirements stability;

  • Critical technologies readiness;

  • Cost to complete;

  • Actual resources versus planned resources;

  • High-probability, high-impact risk events;

  • General disposition of the team;

  • Sponsor's commitment.

The audit process should include interviews with the people doing the work and the project sponsor. The audit process should also provide recommendations with respect to the composition of the audit team and the circumstances under which it should be initiated.

4.1.8 Quality assurance

The purpose of quality assurance (QA) is to provide management with oversight of the project process and the products being built. In subcontracting and outsourcing situations, the QA function will also be responsible for the qualification of subcontractors and external providers.

QA involves inspecting products and activities performed to verify that they comply with the applicable procedures and standards. Unlike a review, where the main question is "Are we doing the right things?" a quality inspection focuses on the question "Are we doing things right?"

Compliance issues must first be addressed within the project. If, for whatever reason, this is not possible the issue should be referred to the appropriate management level for resolution. Key elements of this process are the escalation procedure, which must be documented in order to prevent ill-feelings between QA and the project staff, and the existence of an independent reporting channel to the PO manager and senior management, as these are two of the few instruments the QA function has to leverage its authority. The following is a nonexclusive list of activities to be performed by the QA group.

  • Ensure that the work is conducted in accordance with the standards and procedures established by the project and as described in the project charter; raise and follow up on noncompliances;

  • Ensure that life-cycle documents and the requirements dependency matrix are prepared and kept current and consistent;

  • Verify that relevant life-cycle documents are updated and based on approved requirements change;

  • Identify defects, verify resolution for previously identified defects, and ensure change control integrity.

  • Selectively review and audit the content of system design and other project documents.

  • Ensure that action items resulting from reviews of the software requirements analysis are resolved in accordance with these standards and procedures.

As quality is built into the product rather than added at the time of project completion, the QA work is an ongoing process that continues throughout the project life cycle.

4.1.9 Procurement management

Many of today's projects and products are so complex that few organizations have all the necessary product and process knowledge required to completely design and manufacture them in house. As a result, most companies are dependent on others for crucial elements of their corporate offerings. Typically, however, companies have some choice as to which providers they become dependent upon and for what sorts of products, skills, and competencies [9].

Procurement management is the process that deals with the procurement of goods and services from third parties. The major issues addressed by this process are make/buy decisions, vendor solicitation and selection, and contract negotiation and awards. Specifically this process addresses the following:

  • Market surveillance;

  • Market investigation;

  • Solicitation;

  • Contract tracking and oversight;

  • Evaluation;

  • Transition to support.

While certain process activities such as market surveillance and market investigation will be entrusted to technical specialists from the line functions, others like solicitation, because of its legal and financial implications, will be assigned to dedicated personnel with specialized knowledge. The knowledge required to perform this function ranges from the selection of the type of contract (e.g., fixed price, cost plus incentive) under which the work will be developed, to the negotiation of data rights, penalties, payment schedules, fee structures, scheduling of the deliveries, and warranties.

The goals of the external provisioning process are to do the following:

  • Select dependable suppliers and partners;

  • Minimize life-cycle costs;

  • Develop lasting relationship with suppliers and partners.

At the PO level, it is likely that the procurement process will be executed in the context of a higher-level acquisitions process that provides strategic direction concerning what should be outsourced, who the preferred partners are, and what conditions must be negotiated.

4.1.10 Project accounting

The aim of a specialized project accounting process is to eliminate the need for cumbersome subaccounts in the general ledger while giving the project personnel full access to critical cost and budget analysis information. Among the mismatches between corporate and project accounting, we can mention the annual accounting cycle versus the project life cycle, and the need to classify the expenses along dimensions other than responsibility center or job orders.

This is especially important in the case of effort data, frequently the largest cost element in R&D projects. Besides the obvious need to track expenditures for accounting purposes, effort data could be used for a variety of other purposes: to evaluate project progress, to estimate future work, to detect problems, to measure productivity, and to make end-of-life decisions. It is for this reason that it is essential that the employees working in projects report time in a consistent and timely manner and at a level of granularity that matches the planning detail [10].

For each reported hour it should be possible to identify the following:

  • Work product: This dimension serves not only progress and cost reporting purposes, but also has an important use as a normalizing factor in conjunction with other measurements such as deliverables size to calculate productivity and defect density numbers.

  • Activity: This refers to the type of activity (i.e., system design, coding, testing) to which the hours apply. The main purpose of this classification is to provide data for process improvement activities and estimation of future work.

  • Organization: This corresponds to the cost center to which the employee performing the work belongs and is mainly used for responsibility accounting.

  • Period: This attribute identifies the time interval, usually a week, in which the hours were worked. This categorization allows the calculation of a number of time-phased metrics such as earned value, but is also important when used jointly with production metrics such as number of line of code or installations performed to calculate the rate of progress.

  • Type of labor: This category is used to differentiate between direct or billable hours and indirect hours such as those devoted to process improvement, training, and other support activities. This division is important not only for the different accounting implications but as a measure of the slack or white space that exist in the organization. As we saw in Chapter 2, an organization with no or very little slack is likely to enter into a fire-fighting mode in response to minor disturbances.

  • Type of hours (i.e., regular or overtime): Independently of whether it is paid or not, overtime must be recorded. This is necessary in order to prevent other metrics from being biased because of inaccurate reporting of the actual time it takes to perform a certain activity or complete a product. Overtime is also a leading indicator of morale problems in the project team.

  • Main purpose of the work (i.e., development or rework): This helps to calculate the cost of quality and can be used for process-improvement purposes.

It goes without saying that employees should not be required to enter explanatory data according to each of these categories, but rather that the codes used to report time should contain sufficient information to identify them.

4.1.11 Measurement process

Measurements constitute the fact base on which portfolio management and process improvement rely. Without measurements, there is usually no way to know the status of a project along its many dimensions: cost, schedule, product performance, supportability, and quality. Thus, it is difficult to know what actions to take, what decisions to make, or how to correct unexpected outcomes. Measurement is also becoming increasingly important in two-party business agreements, where it provides a basis for specification, management, and acceptance criteria [11].

The use of measurements in portfolio management will be addressed at length in Chapter 7.

4.1.12 Configuration management

CM is a pervasive discipline that touches on every aspect of the project work. With respect to the project sponsor, CM deals with changes to the project scope; internally, it deals with the evolution of the project's work products. Simply stated, the purpose of CM is to maintain in a congruent state: plans, contracts, requirements, specifications, and deliverables.

Traditionally CM has involved four interrelated tasks:

  1. Identification, consisting of the selection of the work products to be controlled and a labeling schema;

  2. Change control, comprising all steps necessary to establish or change a baseline;

  3. Status accounting, which involves the recording and reporting of the information concerning the status of the work products as well as the changes requested;

  4. Audits, to verify the conformance of the work products to their reported status.

In this proposal we include two new efforts:

  1. Version control, to maintain a list of up-to-date work products to be utilized for everyday work;

  2. Communications, shared with the requirements management process, to ensure that all interested parties are informed of the disposition and consequence of proposed changes.

As shown in Figure 4.9, there can be up to three CM levels: the PO level, which deals with baselines and changes that have repercussions across the portfolio; the project level, which is responsible for the changes to its own development baseline; and the product level, which kicks in after the handover of the deliverables to the project sponsor. The existence of three CM levels does not imply in any way the existence of three different systems or three different CM tools. What the three levels do indicate is that there are different groups that will make decisions about different things, and that there are different procedures to respond to each group's needs.

click to expand
Figure 4.9: CM levels.

4.1.13 Human-resources management

Usually the human-resources management process will follow organization-wide practices, with the PO left to specify the competencies and skills required and the development of appropriate training plans and career paths. The main purpose of this process with regard to the PO is to continually enhance the ability of the PO workforce to perform their assigned tasks and responsibilities while ensuring that individuals are provided with opportunities that enable them to achieve their career objectives.

Specifically this process establishes the following:

  • Competency categories under which the knowledge and skills of the project managers are classified;

  • Work and development activities that contribute to the project manager's development and career growth;

  • Knowledge, to be acquired via training or self-actualization courses that correspond to each competence category.

Figure 4.10 shows the competence model developed by the Ericsson Project Management Institute, which requires certification by the Project Management Institute or equivalent formal training in the nine project management knowledge areas [12] for individuals wanting to pursue a project management career within Ericsson. This initial certification is later complemented with Ericsson's own training and through coaching and mentoring programs.

click to expand
Figure 4.10: Ericsson competence model. (Source:[13].)

Mentoring involves sharing experience and knowledge with others with less seniority through informal methods. A mentorship is a one-to-one relationship in which the mentor serves as a role model for his or her protégé and provides advice on work-related issues and on career development goals and strategies. Coaching is a similar activity but with emphasis on the group rather than on the individual. Coaching is normally done in the context of a supervisor-employees relationship.

4.1.14 Process management

Process management defines how all the other processes owned by the PO are to be defined, who has the responsibility for approving changes to existing ones, and more important, commits the organization to a practice of continuous improvements. The process management process usually follows the practices and formats established by the organization's management system, especially if the organization is certified under an international standard such as ISO 9000.

There is a tendency in the project management community to associate process work with bureaucracy and delays, as indicated by the not infrequently heard phrase, "Do you want me to follow the process or get the job done?" To counter this perception, processes should be written with the goal of providing a shared understanding about how work is organized, who does what, and how activities within the process interface. Large binders prescribing step-by-step behavior gather dust on the shelves of many organizations. Process descriptions should not become textbooks; they are not intended to replace training or thinking. The process descriptions should provide enough information to answer the questions raised in Tables 4.6 and 4.7. In addition, tailoring guidelines on how to adapt the generic processes to the needs of the individual projects must also be provided.

Table 4.6: Process Description Metadata





What is the name of the process?

Portfolio planning process


Why is the process performed?

To further the goals of the organization by taking decisions in light of all, rather than individual, projects


What work products are used?

Project charters, master plan, resource plan


What work products are used?

Updated master plan, updated resource plan


Who (or what) performs the activities?

PO manager calls and facilitates process. Senior management and project sponsors are responsible for the ultimate disposition of the projects


What is done?

Review progress for existing projects. Review new projects for inclusion in the portfolio. Project prioritization and resource balancing. Plans updates

Entry criteria

When (under what circumstances) can the process begin?

Quarterly or when a major variance forces a portfolio replanning

Exit criteria

When (under what circumstances) can the process be considered complete?

Agreed master and resource plans

Reviews and audits

List of reviews, checks, and audits performed during the process



Description of measurements applicable to the process

Time-to-market Pipeline index

Cost drivers

Factors that drive the expense of an activity or resource

Number of projects


List of required training for the process



List of tools that support the process

Expert choice; MS project

Best practices

List of the things that work, list of things that were tried and did not work

Analytical hierarchical process( AHP), risk planning

Table 4.7: Work Product Description Metadata





What is the name of the work product?

Project charter


What is the purpose?

To specify the project outcome in terms of time, costs, quality, and deliverables. It provides a complete description of the project and serves as a foundation for the project work. The project charter ensures that the business agreement between the project sponsor and the execution organization(s) is clearly defined and described.

Identification conventions

Unique identifier used within the company for CM and filing purposes.


Table of contents

Description of the information to be provided.

1. Business Direction
1.1 Project Goals
1.2 Business Opportunity
1.3 Project Background
1.4 Project Scope
2. Project Outcome
2.1 Deliverables
2.2 Quality Objectives
2.3 Included/Excluded
3. Plans
3.1 Time-Schedule
3.2 Milestone Definitions
3.3 Delivery Plans
3.4 Project Budget
4. Project Organization and Stakeholders
4.1 Project Management Function
4.2 Project Steering Function
4.3 Project Sponsor
5. Project Execution
5.1 External Suppliers
5.2 Connections to Other Projects
5.3 Reporting and Communication
5.4 Reviews
5.5 Support Activities
5.6 Security
5.7 Configuration Management
5.8 Quality Verification Model
5.9 Nonconforming Products
5.10 Risk Management
5.11 Subcontract Management
5.12 Document Control
5.13 Quality Records
6. Risks and Opportunities
7. Intellectual Property Rights
8. Project Handover
9. Other Matters


What process produces it?

Project formulation


What process consumes it?

Portfolio planning; project planning


Date on which work product was produced



Who has responsibility for the content of the work product?


Change history

When, why, who, and what was changed since the previous revision of the work product?



What is the current state of the work product?


As much as possible, process knowledge should be embedded in the tools used by the project staff so that process enactment becomes a byproduct of their use, not an intrusion into the staff's work. An example of this would be the replacement of a manual archive and distribution-list system by a central repository with e-mail notifications of all relevant changes, such as the addition of a new document or the creation of a new baseline, to a list of subscribers. Other examples would include the creation of pay or time reporting codes directly from the project plans, the preparation of progress reports from data collected as the result of work transactions such as checking-in or checking out a document from a repository, and the triggering of alerts as a result of the breaking of a predefined business rule associated with a project database, or a process description displayed as part of the Help function in a tool.