Characteristics of a Project Phase

The completion and approval of one or more deliverables characterizes a project phase. A deliverable is a measurable, verifiable work product such as a specification, feasibility study report, detailed design document, or working Proto-type. Proto-types are an excellent way to demonstrate the technology to stakeholders and to prove certain methods without the expenditure of a full project. Some deliverables can correspond to the project management process, whereas others are the end products or components of the end products for which the project was conceived. The deliverables, and hence the phases, are part of a generally sequential process designed to ensure proper control of the project and to attain the desired product or service, which is the objective of the project.

 

In any specific project, for reasons of size, complexity, level of risk, and cash flow constraints, phases can be further subdivided into sub-phases. Each sub-phase is aligned with one or more specific deliverables for monitoring and control. The majority of these sub-phase deliverables are related to the primary phase deliverable, and the phases typically take their names from these phase deliverables: requirements, design, build, test, startup, turnover, and others, as appropriate. Each one of these major phases should have a formal sign-off with the stakeholders. Any change made to the scope of the project later on means that you need to re-open the previous phases to examine what changes occur to the schedule, resources, risks etc. because of the scope change.

 

A project phase is generally concluded with a review of the work accomplished and the deliverables to determine acceptance, whether extra work is still required, or whether the phase should be considered closed. A management review is often held to reach a decision to start the activities of the next phase without closing the current phase, for example, when the project manager chooses fast tracking as the course of action. Another example is when an information technology company chooses an iterative life cycle where more than one phase of the project might progress simultaneously. Requirements for a module can be gathered and analyzed before the module is designed and constructed. While analysis of a module is being done, the requirements gathering for another module could also start in parallel.

 

Similarly, a phase can be closed without the decision to initiate any other phases. For example, the project is completed or the risk is deemed too great for the project to be allowed to continue.

 

Formal phase completion does not include authorizing the subsequent phase.

For effective control, each phase is formally initiated to produce a phase-dependent output of the Initiating Process Group, specifying what is allowed and expected for that phase. A phase-end review can be held with the explicit goals of obtaining authorization to close the current phase and to initiate the subsequent one. Sometimes both authorizations can be gained at one review. Phase-end reviews are also called phase exits, phase gates, or kill points. Kill points are when the stakeholders decide that the project is not worth completing in its current state. It may be restarted with different criteria.

 

Project Life Cycle Relationships

Many projects are linked to the ongoing work of the performing organization.

Some organizations formally approve projects only after completion of a feasibility study, a preliminary plan, or some other equivalent form of analysis; in these cases, the preliminary planning or analysis takes the form of a separate project. For example, additional phases could come from developing and testing a prototype prior to initiating the project for the development of the final product. Some types of projects, especially internal service or new product development projects can be initiated informally for a limited amount of time to secure formal approval for additional phases or activities.

 

The driving forces that create the stimuli for a project are typically referred to as problems, opportunities, or business requirements. The effect of these pressures is that management generally must prioritize this request with respect to the needs and resource demands of other potential projects.

The project life cycle definition will also identify which transitional actions at the end of the project are included or not included, in order to link the project to the ongoing operations of the performing organization. Examples would be when a new product is released to manufacturing, or a new software program is turned over to marketing. Care should be taken to distinguish the project life cycle from the product life cycle. For example, a project undertaken to bring a new desktop computer to market is only one aspect of the product life cycle.  Additional projects can include a performance upgrade to the product. In some application areas, such as new product development or software development, organizations consider the project life cycle as part of the product life cycle.

 

[1] ©2005 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 5

 

Definitions of Project Phases

Projects and project management are carried out in an environment broader than that of the project itself. The project management team must understand this broader context so it can select the life cycle phases, processes, and tools and techniques that appropriately fit the project. This chapter describes some key aspects of the project management context.

 

Project managers or the organization can divide projects into phases to provide better management control with appropriate links to the ongoing operations of the performing organization. Collectively, these phases are known as the project life cycle. Many organizations identify a specific set of life cycles for use on all of their projects. I have found, in my experience, that it is best to have all of the stakeholders sign-off each phase. That way, if new requirements or more complex design work is needed on a module, the project should revisit each project phase to ensure that the completed project match all of the preceding documentation.

 

The project life cycle defines the phases that connect the beginning of a project to its end. For example, when an organization identifies an opportunity to which it would like to respond, it will often authorize a feasibility study to decide whether it should undertake the project. The project life cycle definition can help the project manager clarify whether to treat the feasibility study as the first project phase or as a separate, stand-alone project. Where the outcome of such a preliminary effort is not clearly identifiable, it is best to treat such efforts as a separate project. The phases of a project life cycle are not the same as the Project Management Process Groups.

 

The transition from one phase to another within a project’s life cycle generally involves, and is usually defined by, some form of technical transfer or handoff. Deliverables from one phase are usually reviewed for completeness and accuracy and approved before work starts on the next phase. However, it is not uncommon for a phase to begin prior to the approval of the previous phase’s deliverables, when the risks involved are deemed acceptable. This practice of overlapping phases, normally done in sequence, is an example of the application of the schedule compression technique called fast tracking.

 

NOTE: this practice of starting a phase before the other is complete is very normal, but does come with some risk that must be managed by the Project Manager. In some cases, rework has to be done.

 

There is no single best way to define an ideal project life cycle. Some organizations have established policies that standardize all projects with a single life cycle, while others allow the project management team to choose the most appropriate life cycle for the team’s project. Further, industry common practices will often lead to the use of a preferred life cycle within that industry.

 

NOTE: there are many ways to do a Life Cycle. Some projects are more aligned with the waterfall technique, while others benefit from a rapid development technique such as AGILE.

 

Project life cycles generally define:

 

• What technical work to do in each phase (for example, in which phase should the architect’s work be performed?)

• When the deliverables are to be generated in each phase and how each deliverable is reviewed, verified, and validated

• Who is involved in each phase (for example, concurrent engineering requires that the implementers be involved with requirements and design)

• How to control and approve each phase. Project life cycle descriptions can be very general or very detailed. Highly detailed descriptions of life cycles can include forms, charts, and checklists to provide structure and control.

Most project life cycles share a number of common characteristics.

• Phases are generally sequential and are usually defined by some form of technical information transfer or technical component handoff. Here is where I recommend formal sign-off to occur by all project stakeholders. Scope creep is one of the most prevalent things that slip a schedule, but if management knows what the added scope will do to the project schedule, they will be less likely to add functionality to the project.

• Cost and staffing levels are low at the start, peak during the intermediate phases, and drop rapidly as the project draws to a conclusion.

 

The level of uncertainty is highest and, hence, risk of failing to achieve the objectives is greatest at the start of the project. The certainty of completion generally gets progressively better as the project continues. This is because the hardest technical work is usually done (or well understood) and most risks have been mitigated.

 

The ability of the stakeholders to influence the final characteristics of the project’s product and the final cost of the project is highest at the start, and gets progressively lower as the project continues. A major contributor to this phenomenon is that the cost of changes and correcting errors generally increases as the project continues.

 

Although many project life cycles have similar phase names with similar deliverables, few life cycles are identical. Some can have four or five phases, but others may have nine or more. Single application areas are known to have significant variations. One organization’s software development life cycle can have a single design phase, while another can have separate phases for architectural and detailed design. Subprojects can also have distinct project life cycles. For example, an architectural firm hired to design a new office building is first involved in the owner’s definition phase while doing the design, and in the owner’s implementation phase while supporting the construction effort. The architect’s design project, however, will have its own series of phases from conceptual development, through definition and implementation, to closure. The architect can even treat designing the facility and supporting the construction as separate projects, each with its own set of phases.

 

In the next post, I will talk more about the characteristics of Project Phases.

 

 [1] ©2005 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 5

Announcement

I am avaliable for training people on Project Management with the express outcome of passing the PMP. Please contact me if you are interested:

dritter_2001@yahoo.com

Manage Your Stakeholders! The Key to Your Project’s Success!

 

Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion. Take it from me – these are the people you need to pay the most attention to. They need to be identified in your planning – especially in your communication plan.  They may also exert influence over the project’s objectives and outcomes. The project management team must identify the stakeholders, determine their requirements and expectations, and, to the extent possible, manage their influence in relation to the requirements to ensure a successful project. They can make or break a project!

 

Stakeholders have varying levels of responsibility and authority when participating on a project and these can change over the course of the project’s life cycle. Their responsibility and authority range from occasional contributions in surveys and focus groups to full project sponsorship, which includes providing financial and political support. Stakeholders who ignore this responsibility can have a damaging impact on the project objectives.

 

Likewise, project managers who ignore stakeholders can expect a damaging impact on project outcomes. Sometimes, stakeholder identification can be difficult. For example, some would argue that an assembly-line worker whose future employment depends on the outcome of a new product-design project is a stakeholder. Failure to identify a key stakeholder can cause major problems for a project. For example, late recognition that the legal department was a significant stakeholder in a year 2000 rollover (Y2K) software upgrade project caused many additional documentation tasks to be added to the project’s requirements.

 

Stakeholders may have a positive or negative influence on a project. Positive stakeholders are those who would normally benefit from a successful outcome from the project, while negative stakeholders are those who see negative outcomes from the project’s success. For example, business leaders from a community that will benefit from an industrial expansion project may be positive stakeholders because they see economic benefit to them community from the project’s success. Conversely, environmental groups could be negative stakeholders if they view the project as doing harm to the environment. In the case of positive stakeholders, their interests are best served by helping the project succeed, for example, helping the team to acquire the needed permits to proceed. The negative stakeholders’ interest would be better served by impeding the project’s progress by demanding more extensive environmental reviews. Negative stakeholders are often overlooked by the project team at the risk of failing to bring their projects to a successful end.

 

Key stakeholders on every project include:

 

• Project manager. This is the person responsible for managing the project.

• Customer/user. This refers to the person or organization that will use the project’s product. There may be multiple layers of customers. For example, the customers for a new pharmaceutical product can include the doctors who prescribe it, the patients who take it and the insurers who pay for it. In some application areas, customer and user are synonymous, while in others, customer refers to the entity acquiring the project’s product and users are those who will directly utilize the project’s product.

• Performing organization. This refers to the enterprise whose employees are most directly involved in doing the work of the project.

• Project team members. This is the group that is performing the work of the project.

• Project management team. These are the members of the project team who are directly involved in project management activities.

• Sponsor. This is the person or group that provides the financial resources, in cash or in kind, for the project.

• Influencers. People or groups that are not directly related to the acquisition or use of the project’s product, but due to an individual’s position in the customer organization or performing organization, can influence, positively or negatively, the course of the project.

• PMO. If it exists in the performing organization, the PMO can be a stakeholder if it has direct or indirect responsibility for the outcome of the project. In addition to these key stakeholders, there are many different names and categories of project stakeholders, including internal and external, owners and investors, sellers and contractors, team members and their families, government agencies and media outlets, individual citizens, temporary or permanent lobbying organizations, and society-at-large. The naming or grouping of stakeholders is primarily an aid to identifying which individuals and organizations view themselves as stakeholders. Stakeholder roles and responsibilities can overlap, such as when an engineering firm provides financing for a plant that it is designing. Project managers must manage stakeholder expectations, which can be difficult because stakeholders often have very different or conflicting objectives.

 

For example:

 

• The manager of a department that has requested a new management information system may desire low cost, the system architect may emphasize technical excellence, and the programming contractor may be most interested in maximizing its profit.

• The vice president of research at an electronics firm may define new product success as state-of-the-art technology, the vice president of manufacturing may define it as world-class practices, and the vice president of marketing may be primarily concerned with the number of new features.

Construtcing a Project Charter – the Beginning of the Project Scope

 

 

The project charter is the document that formally authorizes a project. The project charter provides the project manager with the authority to apply organizational resources to project activities. A project manager is identified and assigned as early in the project as is feasible. The project manager should always be assigned prior to the start of planning, and preferably while the project charter is being developed.

 

A project initiator or sponsor external to the project organization, at a level that is appropriate to funding the project, issues the project charter. Projects are usually chartered and authorized external to the project organization by an enterprise, a government agency, a company, a program organization, or a portfolio organization, as a result of one or more of the following:

 

• A market demand (e.g., a car company authorizing a project to build more fuel-efficient cars in response to gasoline shortages)

• A business need (e.g., a training company authorizing a project to create a new course to increase its revenues)

• A customer request (e.g., an electric utility authorizing a project to build a new substation to serve a new industrial park)

• A technological advance (e.g., an electronics firm authorizing a new project develop a faster, cheaper, and smaller laptop after advances in computer memory and electronics technology)

• A legal requirement (e.g., a paint manufacturer authorizing a project to establish guidelines for handling toxic materials)

• A social need (e.g., a nongovernmental organization in a developing country authorizing a project to provide potable water systems, latrines, and sanitation education to communities suffering from high rates of cholera).

These stimuli can also be called problems, opportunities, or business requirements. The central theme of all these stimuli is that management must make a decision about how to respond and what projects to authorize and charter. Project selection methods involve measuring value or attractiveness to the project owner or sponsor and may include other organizational decision criteria. Project selection also applies to choosing alternative ways of executing the project.

Chartering a project links the project to the ongoing work of the organization. In some organizations, a project is not formally chartered and initiated until completion of a needs assessment, feasibility study, preliminary plan, or some other equivalent form of analysis that was separately initiated. Developing the project charter is primarily concerned with documenting the business needs, project justification, current understanding of the customer’s requirements, and the new product, service, or result that is intended to satisfy those requirements. The project charter, either directly, or by reference to other documents, should address the following information:

Requirements that satisfy customer sponsor, and other stakeholder needs, wants and expectations;

 

• Business needs, high-level project description, or product requirements that the project is undertaken to address

• Project purpose or justification

• Assigned Project Manager and authority level

• Summary milestone schedule

• Stakeholder influences

• Functional organizations and their participation

• Organizational, environmental and external assumptions

• Organizational, environmental and external constraints

• Business case justifying the project, including return on investment

• Summary budget.

 

During subsequent phases of multi-phase projects, the Develop Project

Charter process validates the decisions made during the original chartering of the project. If required, it also authorizes the next project phase, and updates the charter.

 

Contract (When Applicable)

A contract from the customer’s acquiring organization is an input if the project is being done for an external customer.

Project Statement of Work:

The statement of work (SOW) is a narrative description of products or services to be supplied by the project. For internal projects, the project initiator or sponsor provides the statement of work based on business needs, product, or service requirements. For external projects, the statement of work can be received from the customer as part of a bid document, for example, request for proposal, request for information, request for bid, or as part of a contract. The SOW indicates a:

 

Business need – an organization’s business need can be based on needed training, market demand, technological advance, legal requirement, or governmental standard.

• Product scope description – documents the product requirements and characteristics of the product or service that the project will be undertaken to create. The product requirements will generally have less detail during the initiation process and more detail during later processes, as the product characteristics are progressively elaborated. These requirements should also document the relationship among the products or services being created and the business need or other stimulus that causes the need. While the form and substance of the product requirements document will vary, it should always be detailed enough to support later project planning.

• Strategic plan – all projects should support the organization’s strategic goals. The strategic plan of the performing organization should be considered as a factor when making project selection decisions.

 

Enterprise Environmental Factors:

When developing the project charter, any and all of the organization’s enterprise environmental factors and systems that surround and influence the project’s success must be considered. This includes items such as, but not limited to:

 

• Organizational or company culture and structure

• Governmental or industry standards (e.g., regulatory agency regulations, product standards, quality standards, and workmanship standards)

• Infrastructure (e.g., existing facilities and capital equipment)

• Existing human resources (e.g., skills, disciplines, and knowledge, such as design, development, legal, contracting, and purchasing)

• Personnel administration (e.g., hiring and firing guidelines, employee performance reviews, and training records)

• Company work authorization system

• Marketplace conditions

• Stakeholder risk tolerances

• Commercial databases (e.g., standardized cost estimating data, industry risk study information, and risk databases)

• Project management information systems (e.g., an automated tool suite, such as a scheduling software tool, a configuration management system, an information collection and distribution system, or web interfaces to other online automated systems.

 

Organizational Process Assets

When developing the project charter and subsequent project documentation, any and all of the assets that are used to influence the project’s success can be drawn from organizational process assets. Any and all of the organizations involved in the project can have formal and informal policies, procedures, plans, and guidelines whose effects must be considered. Organizational process assets also represent the organizations’ learning and knowledge from previous projects; for example, completed schedules, risk data, and earned value data. Organizational process assets can be organized differently, depending on the type of industry, organization, application area. For example, the organizational process assets could be grouped into two categories:

 

 Organization’s processes and procedures for conducting work:

·    Organizational standard processes, such as standards, policies (e.g., safety and health policy, and project management policy), standard product and project life cycles, and quality policies and procedures (e.g., process audits, improvement targets, checklists, and standardized process definitions for use in the organization)

·    Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria templates (e.g., risk templates, work breakdown structure templates, and project schedule network diagram templates)

·    Guidelines and criteria for tailoring the organization’s set of standard processes to satisfy the specific needs of the project

·    Organization communication requirements (e.g., specific communication technology available, allowed communication media, record retention, and security requirements)

·    Project closure guidelines or requirements (e.g., final project audits, project evaluations, product validations, and acceptance criteria)

·    Financial controls procedures (e.g., time reporting, required expenditure and disbursement reviews, accounting codes, and standard contract provisions)

·    Issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking

·    Change control procedures, including the steps by which official company standards, policies, plans, and procedures—or any project documents—will be modified, and how any changes will be approved and validated

·    Risk control procedures, including risk categories, probability definition and impact, and probability and impact matrix

·    Procedures for approving and issuing work authorizations.

 

Organizational corporate knowledge base for storing and retrieving information:

·    Process measurement database used to collect and make available measurement data on processes and products

·    Project files (e.g., scope, cost, schedule, and quality baselines, performance measurement baselines, project calendars, project schedule network diagrams, risk registers, planned response actions, and defined risk impact)

·    Information and lessons learned knowledge base (e.g., project records and documents, all project closure information and documentation, information about both the results of previous project selection decisions and previous project performance information, and information from the risk management effort)

·    Issue and defect management database containing issue and defect status, control information, issue and defect resolution, and action item results

·    Configuration management knowledge base containing the versions and baselines of all official company standards, policies, procedures, and any project documents

·    Financial database containing information such as labor hours, incurred costs, budgets, and any project cost overruns.

 

Develop Project Charter: Tools and Techniques

 

Project Selection Methods

Project selection methods are used to determine which project the organization will select. These methods generally fall into one of two broad categories:

• Benefit measurement methods that are comparative approaches, scoring models, benefit contribution, or economic models.

• Mathematical models that use linear, nonlinear, dynamic, integer, or multi-objective programming algorithms.

Project Management Methodology

A project management methodology defines a set of Project Management Process Groups, their related processes and the related control functions that are consolidated and combined into a functioning unified whole. A project management methodology may or may not be an elaboration of a project management standard. A project management methodology can be either a formal mature process or an informal technique that aids a project management team in effectively developing a project charter.

Project Management Information System

The Project Management Information System (PMIS) is a standardized set of automated tools available within the organization and integrated into a system. The PMIS is used by the project management team to support generation of a project charter, facilitate feedback as the document is refined, control changes to the project charter, and release the approved document.

Expert Judgment

Expert judgment is often used to assess the inputs needed to develop the project charter. Such judgment and expertise is applied to any technical and management details during this process. Such expertise is provided by any group or individual with specialized knowledge or training, and is available from many sources, including:

• Other units within the organization

• Consultants

• Stakeholders, including customers or sponsors

• Professional and technical associations

• Industry groups.

 

Project Quality Mangement

Project Quality Management is one of the most important processes in the Life Cycle to determine the project is on track. Tests performed during the quality process must map directly to a requirement. If not, the process needs to be re-examined. Quality processes include all the activities of the performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken. It implements the quality management system through the policy, procedures, and processes of quality planning, quality assurance, and quality control, with continuous process improvement activities conducted throughout, as appropriate. Quality Management is often managed another manager and care has to be taken to make sure your project has the quality engineering resources required to do the job. That is one reason I am strict about making good relationships with everyone in the project team. This goes double when your resources are in a matrix organization and not reporting to you.

 

Quality Planning: identifying which quality standards are relevant to the project and determining how to satisfy them.

 

Perform Quality Assurance: applying the planned, systematic quality activities to ensure that the project employs all processes needed to meet requirements.

 

Perform Quality Control: monitoring specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance.

 

These processes interact with each other and with the processes in the other Knowledge Areas as well. Each process can involve effort from one or more people or groups of people based on the needs of the project. Each process occurs at least once in every project and occurs in one or more project phases, if the project is divided into phases. Although the processes are presented here as discrete elements with well-defined interfaces, in practice they may overlap and interact in ways not detailed here.

 

The basic approach to quality management described in this section is intended to be compatible with that of the International Organization for Standardization (ISO). This generalized approach should also be compatible with proprietary approaches to quality management such as those recommended by Deming, Juran, Crosby and others, and non-proprietary approaches such as Total Quality Management (TQM), Six Sigma, Failure Mode and Effect Analysis, Design Reviews, Voice of the Customer, Cost of Quality (COQ), and Continuous Improvement.

 

Project Quality Management must address the management of the project and the product of the project. While Project Quality Management applies to all projects, regardless of the nature of their product, product quality measures and techniques are specific to the particular type of product produced by the project.

 

For example, quality management of software products entails different approaches and measures than nuclear power plants, while Project Quality Management approaches apply to both. In either case, failure to meet quality requirements in either dimension can have serious negative consequences for any or all of the project stakeholders. For example:

 

• Meeting customer requirements by overworking the project team may produce negative consequences in the form of increased employee attrition, unfounded errors, or rework

• Meeting project schedule objectives by rushing planned quality inspections  may produce negative consequences when errors go undetected.

Quality is “the degree to which a set of inherent characteristics fulfill requirements”. Stated and implied needs are the inputs to developing project requirements. A critical element of quality management in the project context is to turn stakeholder needs, wants, and expectations into requirements through Stakeholder Analysis, performed during Project Scope Management.

 

Quality and grade are not the same. Grade is a category assigned to products or services having the same functional use but different technical characteristics. Low quality is always a problem; low grade may not be. For example, a software product can be of high quality (no obvious defects, readable manual) and low grade (a limited number of features), or of low quality (many defects, poorly organized user documentation) and high grade (numerous features). The project manager and the project management team are responsible for determining and delivering the required levels of both quality and grade.

 

Precision and accuracy are not equivalent. Precision is consistency that the value of repeated measurements are clustered and have little scatter. Accuracy is correctness that the measured value is very close to the true value. Precise measurements are not necessarily accurate. A very accurate measurement is not necessarily precise. The project management team must determine how much accuracy/precision or both are required.

 

Customer satisfaction: Understanding, evaluating, defining, and managing expectations so that customer requirements are met. This requires a combination of conformance to requirements (the project must produce what it said it would produce) and fitness for use (the product or service must satisfy real needs).

• Prevention over inspection: The cost of preventing mistakes is generally a lot less than the cost of correcting them, as revealed by inspection. It is said that the cost of a bug rises exponentially as the project reaches completion. Think of how much more a problem costs if it reaches the field and a new release has to be manufactured to fix it. This not only costs in the obvious dollars but also in the reputation of the firm delivering the product, especially in shops that run 24*7.

• Management responsibility: Success requires the participation of all members of the team, but it remains the responsibility of management to provide the resources needed to succeed.

• Continuous improvement: The plan-do-check-act cycle is the basis for quality improvement (as defined by Shewhart and modified by Deming, in the ASQ Handbook, pages 13–14, American Society for Quality, 1999). In addition, quality improvement initiatives undertaken by the performing organization, such as TQM and Six Sigma, can improve the quality of the project’s management as well as the quality of the project’s product. Process improvement models include Malcolm Baldrige, CMM®, and CMMISM.

The cost of quality refers to the total cost of all efforts related to quality.

Project decisions can impact operational costs of quality as a result of product returns, warranty claims, and recall campaigns. However, the temporary nature of the project means that investments in product quality improvement, especially defect prevention and appraisal, can often be borne by the acquiring organization, rather than the project, since the project may not last long enough to reap the rewards.

Cost-Benefit Analysis: Quality planning must consider cost-benefits tradeoffs. The primary benefit of meeting quality requirements is less rework, which means higher productivity, lower costs, and increased stakeholder satisfaction. The primary cost of meeting quality requirements is the expense associated with Project Quality Management activities.

Benchmarking:

Benchmarking involves comparing actual or planned project practices to those of other projects to generate ideas for improvement and to provide a basis by which to measure performance. These other projects can be within the performing organization or outside of it, and can be within the same or in another application area.

Design of Experiments:

Design of experiments (DOE) is a statistical method that helps identify which factors may influence specific variables of a product or process under development or in production. It also plays a role in the optimization of products or processes. Think of the scientific method.

An example is where an organization can use DOE to reduce the sensitivity of product performance to sources of variations caused by environmental or manufacturing differences. The most important aspect of this technique is that it provides a statistical framework for systematically changing all of the important factors, instead of changing the factors one at a time. The analysis of the experimental data should provide the optimal conditions for the product or process, highlighting the factors that influence the results, and revealing the presence of interactions and synergisms among the factors. For example, automotive designers use this technique to determine which combination of suspension and tires will produce the most desirable results in the time given.

Cost of Quality (COQ):

Quality costs are the total costs incurred by investment in preventing nonconformance to requirements, appraising the product or service for conformance to requirements, and failing to meet requirements (rework). Failure costs are often categorized into internal and external. Failure costs are also called cost of poor quality.

Additional Quality Planning Tools

Other quality planning tools are also often used to help better define the situation and help plan effective quality management activities. These include brainstorming, affinity diagrams, force field analysis, nominal group techniques, matrix diagrams, flowcharts, and prioritization matrices.

 

As you can see quality is a main component of customer satisfaction and to the bottom line. A bug found early can save a company millions of dollars!

 

[1] ©2005 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 5

Quatatative Risk Analysis Tools and Techniques

Quantitative Risk Analysis is performed on risks that have been prioritized by the Qualitative Risk Analysis process.  The Quantitative Risk Analysis process analyzes the effect of those risk events and assigns a numerical rating to those risks. It also presents a quantitative approach to making decisions in the presence of uncertainty. Since it is more expensive, it is only done on those risks we already identified as potentially and substantially impacting the project’s competing demands.

 

This process uses techniques such as Monte Carlo simulation and decision tree analysis to:

 

·    Quantify the possible outcomes for the project and their probabilities

·    Assess the probability of achieving specific project objectives

·    Identify risks requiring the most attention by quantifying their relative contribution to overall project risk

·    Identify realistic and achievable cost, schedule, or scope targets, given the project risks

·    Determine the best project management decision when some conditions or outcomes are uncertain.

 

Quantitative Risk Analysis generally follows the Qualitative Risk Analysis process, although experienced risk managers sometimes perform it directly after Risk Identification. In some cases, Quantitative Risk Analysis may not be required to develop effective risk responses. Availability of time and budget, and the need for qualitative or quantitative statements about risk and impacts, will determine which method(s) to use on any particular project. Quantitative Risk Analysis should be repeated after Risk Response Planning, as well as part of Risk Monitoring and Control, to determine if the overall project risk has been satisfactorily decreased. Trends can indicate the need for more or less risk management action.

 

·    Interviewing. Interviewing techniques are used to quantify the probability and impact of risks on project objectives. The information needed depends upon the type of probability distributions that will be used. For instance, information would be gathered on the optimistic (low), pessimistic (high), and most likely scenarios for some commonly used distributions, and the mean and standard deviation for others. Documenting the rationale of the risk ranges is an important component of the risk interview, because it can provide information on reliability and credibility of the analysis.

·    Probability distributions. Continuous probability distributions represent the uncertainty in values, such as durations of schedule activities and costs of project components. Discrete distributions can be used to represent uncertain events, such as the outcome of a test or a possible scenario in a decision tree.

·    Expert judgment. Subject matter experts internal or external to the organizations such as engineering or statistical experts, validate data and techniques.

 

Quantitative Risk Analysis and Modeling Techniques:

 

·    Sensitivity analysis. Sensitivity analysis helps to determine which risks have the most potential impact on the project. It examines the extent to which the uncertainty of each project element affects the objective being examined when all other uncertain elements are held at their baseline values. One typical display of sensitivity analysis is the tornado diagram, which is useful for comparing relative importance of variables that have a high degree of uncertainty to those that are more stable.

·    Expected monetary value analysis. Expected monetary value (EMV) analysis is a statistical concept that calculates the average outcome when the future includes scenarios that may or may not happen (i.e., analysis under uncertainty). The EMV of opportunities will generally be expressed as positive values, while those of risks will be negative. EMV is calculated by multiplying the value of each possible outcome by its probability of occurrence, and adding them together. A common use of this type of analysis is in decision tree analysis. Modeling and simulation are recommended for use in cost and schedule risk analysis, because they are more powerful and less subject to misuse than EMV analysis.

·    Decision tree analysis. Decision tree analysis is usually structured using a decision tree diagram that describes a situation under consideration, and the implications of each of the available choices and possible scenarios. It incorporates the cost of each available choice, the probabilities of each possible scenario, and the rewards of each alternative logical path. Solving the decision tree provides the EMV (or other measure of interest to the organization) for each alternative, when all the rewards and subsequent decisions are quantified.

 

Modeling and simulation:  

 

A project simulation uses a model that translates the uncertainties specified at a detailed level of the project into their potential impact on project objectives. Simulations are typically performed using the Monte Carlo technique. In a simulation, the project model is computed many times (iterated), with the input values randomized from a probability distribution function (e.g., cost of project elements or duration of schedule activities) chosen for each iteration from the probability distributions of each variable. A probability distribution (e.g., total cost or completion date) is calculated.

 

For a cost risk analysis, a simulation can use the traditional project WBS or a cost breakdown structure as its model. For a schedule risk analysis, the precedence diagramming method (PDM) schedule is used.

 

 

Project Risk Qualitative Analysis

There are two cycles of analysis that can be done on risks after they have been identified before Risk Planning occurs. The first is Qualitative Risk Analysis which includes methods for prioritizing the identified risks for further action, such as Quantitative Risk Analysis or Risk Response Planning. Organizations can improve the project’s performance effectively by focusing on high-priority risks.

 

Qualitative Risk Analysis assesses the priority of identified risks using their probability of occurring, the corresponding impact on project objectives if the risks do occur, as well as other factors such as the time frame and risk tolerance of the project constraints of cost, schedule, scope, and quality. Stakeholder risk tolerances must be taken into account in this phase. Everyone knows that if you change one side of the triple constraint triangle (cost, schedule and scope/quality), then one of the other factors change. For example, if you add to the scope, either cost (hiring more engineers) or schedule will change. As the Project Manager, it is vital that you know which one of these factors drive the Stakeholders. It may be time to market (schedule), cost or functionality (scope/quality).

 

Definitions of the levels of probability and impact, and expert interviewing, can help to correct biases that are often present in the data used in this process. The time criticality of risk-related actions may magnify the importance of a risk. An evaluation of the quality of the available information on project risks also helps understand the assessment of the risk’s importance to the project.

 

Qualitative Risk Analysis is usually a rapid and cost-effective means of establishing priorities for Risk Response Planning, and lays the foundation for Quantitative Risk Analysis (a much more rigorous and expensive process)  if this is required. Qualitative Risk Analysis should be revisited during the project’s life cycle to stay current with changes in the project risks.

 

Qualitative Risk Analysis requires outputs of the Risk Management Planning and Risk Identification processes. This process can lead into Quantitative Risk Analysis or directly into Risk Response Planning.

 

Risk Probability and Impact Assessment

Risk probability assessment investigates the likelihood that each specific risk will occur. Risk impact assessment investigates the potential effect on a project objective such as time, cost, scope, or quality, including both negative effects for threats and positive effects for opportunities.

 

Probability and impact are assessed for each identified risk. Risks can be assessed in interviews or meetings with participants selected for their familiarity with the risk categories on the agenda. Project team members and, perhaps, knowledgeable persons from outside the project, are included. Expert judgment is required, since there may be little information on risks from the organization’s database of past projects. Using outside experts to help in the assessment is very helpful since they are experts and they are not as biased as the project team. I have found this technique to be very useful.

 

The level of probability for each risk and its impact on each objective is evaluated during the interview or meeting. Explanatory detail, including assumptions justifying the levels assigned, is also recorded. Risk probabilities and impacts are rated according to the definitions given in the risk management plan. Sometimes, risks with obviously low ratings of probability and impact will not be rated, but will be included on a watch-list for future monitoring.

 

Probability and Impact Matrix

Risks can be prioritized for further quantitative analysis and response, based on their risk rating. Ratings are assigned to risks based on their assessed probability and impact. Evaluation of each risk’s importance and, hence, priority for attention is typically conducted using a look-up table or a probability and impact matrix. Such a matrix specifies combinations of probability and impact that lead to rating the risks as low, moderate, or high priority.

 

Descriptive terms or numeric values can be used, depending on organizational preference. The organization should determine which combinations of probability and impact result in a classification of high risk, moderate risk and low risk.

 

Usually, these risk rating rules are specified by the organization in advance of the project, and included in organizational process assets. Risk rating rules can be tailored in the Risk Management Planning process to the specific project.

 

An organization can rate a risk separately for each objective (e.g., cost, time, and scope). In addition, it can develop ways to determine one overall rating for each risk. Finally, opportunities and threats can be handled in the same matrix using definitions of the different levels of impact that are appropriate for each.

 

The risk score helps guide risk responses. For example, risks that have a negative impact on objectives if they occur (threats), and that are in the high-risk zone of the matrix, may require priority action and aggressive response strategies. Threats in the low-risk zone may not require proactive management action beyond being placed on a watch list or adding a contingency reserve.

 

Similarly for opportunities, those in the high-risk zone that can be obtained most easily and offer the greatest benefit should, therefore, be targeted first. Opportunities in the low-risk zone should be monitored. Earned Monetary Value (EMV) is a good technique to use here.

 

Risk Data Quality Assessment

A qualitative risk analysis requires accurate and unbiased data if it is to be credible. Analysis of the quality of risk data is a technique to evaluate the degree to which the data about risks is useful for risk management. It involves examining the degree to which the risk is understood and the accuracy, quality, reliability, and integrity of the data about the risk.

The use of low-quality risk data may lead to a qualitative risk analysis of little use to the project. If data quality is unacceptable, it may be necessary to gather better data.

 

Risk Categorization

Risks to the project can be categorized by sources of risk (e.g., using the RBS), the area of the project affected (e.g., using the WBS), or other useful category (e.g., project phase) to determine areas of the project most exposed to the effects of uncertainty. Grouping risks by common root causes can lead to developing effective risk responses.

 

Risk Urgency Assessment

Risks requiring near-term responses may be considered more urgent to address. Indicators of priority can include time to affect a risk response, symptoms and warning signs, and the risk rating.

 

Identifying Risks in Your Project

All projects have risks. It is the job of the Project Manager to identify these risks as part of the Risk Management Planning Process. Risk Identification determines which risks might affect the project and documents their characteristics. Participants in risk identification activities can include the following, where appropriate: project manager, project team members, risk management team (if assigned), subject matter experts from outside the project team, customers, end users, other project managers, stakeholders, and risk management experts. While these personnel are often key participants for risk identification, all project personnel should be encouraged to identify risks. I worked on a project where we used several of these techniques. I will point those out to you in the following sections.

 

Risk identification is an integrative process. The frequency of iteration and who participates in each cycle will vary from case to case. The project team should be involved in the process so that they can develop and maintain a sense of ownership of, and responsibility for, the risks and associated risk response actions. Stakeholders outside the project team may provide additional objective information. Especially important is the risk tolerance of the Stakeholders. This is invaluable information in Risk Planning.

 

The Risk Identification process usually leads to the Qualitative Risk Analysis process. Alternatively, it can lead directly to the Quantitative Risk Analysis process when conducted by an experienced risk manager. On some occasions, simply the identification of a risk may suggest its response, and these should be recorded for further analysis and implementation in the Risk Response Planning process.

 

Documentation Reviews

A structured review may be performed of project documentation, including plans, assumptions, prior project files, and other information. The quality of the plans, as well as consistency between those plans and with the project requirements and assumptions, can be indicators of risk in the project.

 

Information Gathering Techniques

I worked on a project where we spent three days planning the project. We engaged several experts in our technology to help us with the Information Gathering Techniques. This helped the project a lot since we (the project team) were not experts at the time of the project. They were very helpful in the brainstorming and Delphi techniques. During each following phase of the project, the Risk list should be looked at to see if any further risks have been identified.

 

Examples of information gathering techniques used in identifying risk can include:

 

·    Brainstorming. The goal of brainstorming is to obtain a comprehensive list of project risks. Our project team performed the brainstorming with a multidisciplinary set of experts not on the team. Ideas about project risk are generated under the leadership of a facilitator. Categories of risk such as a risk breakdown structure can be used as a framework.  (see earlier post) Risks are then identified and categorized by type of risk and their definitions are sharpened.

·    Delphi technique. The Delphi technique is a way to reach a consensus of experts. We used Project risk experts as well as Technology experts to participate in this technique anonymously. A facilitator uses a questionnaire to solicit ideas about the important project risks. The responses are summarized and are then sent back to the experts for further comment. Consensus may be reached in a few rounds of this process. The Delphi technique helps reduce bias in the data and keeps any one person from having undue influence on the outcome.

·    Interviewing. We also interviewed experienced project participants, stakeholders and subject matter experts to identify risks. Interviews are one of the main sources of risk identification data gathering.

·    Root cause identification. This is an inquiry into the essential causes of a project’s risks. It sharpens the definition of the risk and allows grouping risks by causes. Effective risk responses can be developed if the root cause of the risk is addressed.

·    Strengths, weaknesses, opportunities, and threats (SWOT) analysis. This technique ensures examination of the project from each of the SWOT perspectives, to increase the breadth of considered. Our project team used this technique to more fully examine the risks that had been identified.

·    Checklist Analysis. Risk identification checklists can be developed based on historical information and knowledge that has been accumulated from previous similar projects and from other sources of information. This means you have to record project information at the end of the project to build the historical database. The lowest level of the risk breakdown structure can also be used as a risk checklist. While a checklist can be quick and simple, it is impossible to build an exhaustive one. Care should be taken to explore items that do not appear on the checklist. The checklist should be reviewed during project closure to improve it for use on future projects.

·    Assumptions Analysis. Every project is conceived and developed based on a set of hypotheses, scenarios, or assumptions. Assumptions analysis is a tool that explores the validity of assumptions as they apply to the project. It identifies risks to the project from inaccuracy, inconsistency, or incompleteness of assumptions.

·    Diagramming Techniques. Risk diagramming techniques may include:

o   Cause-and-effect diagrams. These are also known as Ishikawa or fishbone diagrams, and are useful for identifying causes of risks. We used these frequently in projects.

o   System or process flow charts. These show how various elements of system interrelate, and the mechanism of causation. Seeing the flow sometimes triggers someone to identify a risk that may have slipped through the cracks.

o   Influence diagrams. These are graphical representations of situations showing causal influences, time ordering of events, and other relationships among variables and outcomes.

 

You can never spend too much time in identifying risks. After the list is made, qualitative and quantitative analysis is done to figure out which risks you spend time and/or money on. Murphy’s law is always a good one!

Five Keys to Great Relationships!

Everyone has had the experience of “connecting” to someone almost immediately when you meet. This is the art of building solid relationships. When you feel this connection you are glued to the conversation and sometimes can finish each other’s sentences.

 

Just about everything you do relies on teamwork. It is vital to a well working Project team, a family, lasting friendships etc. These are five things to look for in a solid relationship:

 

1.   Respect: Everyone wants to feel important and that they matter. The key is that you show respect to others even before they have done anything to warrant it. You respect others because they are simply human beings. At the same time, you should have to expect to earn it from others. This makes working through conflicts much easier.

2.   Shared Experiences: Respect can lay the foundation for a good relationship, but it’s not enough. You can’t be rational with someone you don’t know. It takes shared experiences over time. This is easy in families, but if you have a project team with high turnover, you need to work at building those relationships.

3.   Trust: When you respect people, and build shared experiences, you are in a position to develop trust. It is essential to every relationship.

4.   Reciprocity: One sided relationships don’t last long. If one person is the giver and one person is the receiver, there is no win-win dynamic. You should ask your teammates, colleagues and friends about their dreams and hopes. Give people your full attention and look them in the eye when you are in conversation.

5.   Mutual Enjoyment: When relationships start to grow really solid, the people begin to enjoy each other. Just being together can turn unpleasant tasks into positive experiences. Becoming a master at building relationships brings individual and team success.