4.1 PO process definitions
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.
 |
| Process Description | Addresses | Invokes |
|---|---|---|
| | ||
| Project life-cycle management | Project formulation | Estimation |
| Project portfolio management | Project portfolio planning | Budgeting |
| Estimation | Production of rough and | |
| Budgeting | Itself | |
| Requirements management | Change management | |
| Risk and opportunity management | Itself | |
| Project audit | Itself | |
| Quality assurance | Evaluation of work products and process compliance | Project audit |
| Procurement management | Market survey | |
| Project accounting | ||
| Measurement process | Planning of measurement | |
| Configurations management | Change management | |
| Human-resources management | Workforce planning | |
| Administration | Itself | |
| Process management | Identification of process constraints | |
|
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.
Figure 4.1: Roles in project life-cycle management.
|
| Phase | Formulation | Startup | Execution | Closure |
|---|---|---|---|---|
| | ||||
| Purpose | 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 |
| Inputs | Customer or sales requirements | Project charter | Project specification | Project deliverables |
| Activities | Establish scope of work | Conduct kickoff meeting | Hand over results | |
| Outputs | Project charter | Project specification | Project deliverables | Lessons learned |
| Tollgate | Depending on the duration of the project, there might be more than one tollgate during execution | |||
| Business | The business case remains current | The business case remains current | The business case remains current | All handover has been performed |
| Progress | The selected approach is feasible | The selected approach is feasible | The selected approach will produce a system that meets expectations | The results meet expectations |
| Use of resources | There are enough resources to execute the project | There are enough resources to execute the project | Staff and equipment availability | |
|
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.
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?
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.
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%).
|
| When? | Type of Estimate | Level of Detail (WBS level of decomposition) | Estimating Method | Accuracy (%) |
|---|---|---|---|---|
| | ||||
| Feasibility, prestudy | Order of magnitude | 1 | Parametric, analogy, paired comparisons | 35 |
| Planning | Budget | 2, 3 | Successive principle, analogy, parametric, Paired comparisons | 15 |
| Execution | Definitive | 4, 5, 6 | Successive principle, engineering buildup | 5 |
|
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.
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.
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.
Figure 4.7: Risk-management process.
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:
-
Private or diversifiable risks (i.e., schedule slip, unreliable technology, staff turnover, misunderstood business);
-
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.
|
| Industry | |||
|---|---|---|---|
| | |||
| Software | Pharmaceutical | 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+) | 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 | 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 | 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 | |||
| 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 | |
|
|
| Product Engineering | Development Environment | Program Constraints |
|---|---|---|
| | ||
| Requirements | Development process | Resources |
| Design | Development system | Contract |
| Code and unit test | Management process | Program interfaces |
| Integration and test | Management methods | |
| Engineering specialties | Work environment | |
|
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:
-
Identification, consisting of the selection of the work products to be controlled and a labeling schema;
-
Change control, comprising all steps necessary to establish or change a baseline;
-
Status accounting, which involves the recording and reporting of the information concerning the status of the work products as well as the changes requested;
-
Audits, to verify the conformance of the work products to their reported status.
In this proposal we include two new efforts:
-
Version control, to maintain a list of up-to-date work products to be utilized for everyday work;
-
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.
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.
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.
|
| Attribute | Meaning | Example |
|---|---|---|
| | ||
| Name | What is the name of the process? | Portfolio planning process |
| Purpose | Why is the process performed? | To further the goals of the organization by taking decisions in light of all, rather than individual, projects |
| Input | What work products are used? | Project charters, master plan, resource plan |
| Output | What work products are used? | Updated master plan, updated resource plan |
| Role | 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 |
| Activity | 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 | N/A |
| Measurements | 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 |
| Training | List of required training for the process | N/A |
| Tools | 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 |
|
|
| Attribute | Meaning | Example |
|---|---|---|
| | ||
| Name | What is the name of the work product? | Project charter |
| Purpose | 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. | N/A |
| Table of contents | Description of the information to be provided. | 1. Business Direction |
| Producer | What process produces it? | Project formulation |
| Consumer/s | What process consumes it? | Portfolio planning; project planning |
| Date | Date on which work product was produced | |
| Approver | 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? | |
| Status | 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.
EAN: 2147483647
Pages: 81