Our QP (Quigley Pries) model (Figure 1.1) promotes the idea of project and program management as a control system; that is, we find from experience that the best project management is that which is self-regulating.

Ensuring product integrity and program quality (Click here to view on Amazon)

Chapter 1: Projects and Project Managers

1.1 Delivery

1.1.1 Overview of Program/Project Management

Many of the examples we present throughout this book come from the automotive supplier and customer world because we work in that environment every day. We suggest that most of the automotive development and production ideas have universal value—particularly the concept of process and design controls. In some cases, we will identify where a particular approach conveniently satisfies embedded development or, in other cases, service process development.

We distinguish automotive project management from general project management because the International Organization for Standardization (ISO) spells out the documentation and action requirements in an international standard (ISO/TS 16949). The Production Part Approval Process (PPAP) alone generates a minimum of 18 documents as a standard part of the package. Also, the stakes involved in automotive product release use large quantities of invested capital and expenses—a new vehicle runs into the tens of millions of dollars and sometimes more.

The automotive superset of ISO 9001:2000, the ISO standard ISO/TS 16949, regulates automotive project management.

Whatever the standards, we can generalize the automotive approach to nearly any industry. In fact, a little research reveals that the Hazard Analysis and Critical Control Point (HACCP) standard used by the food industry works as a direct analog of the automotive process control sequence.

1.1.2 Need for This Book

Currently, no book exists that promotes and generalizes the automotive project and program management approach in detail. General project management texts supply generic information and construction-oriented works support those disciplines. While these works perform well as references, they do not particularly help the project manager who is involved in capital-intensive projects or who desires to implement the variety of controls derived from automotive-style development and implementation.

Our QP (Quigley Pries) model (Figure 1.1) promotes the idea of project and program management as a control system; that is, we find from experience that the best project management is that which is self-regulating. Furthermore, the automotive approach is full of “controls” that keep bad things from happening. We think the idea of “control” generalizes nicely to a kind of project management that regulates itself. In the graphic below, the planning activities and organizational processes/procedures define the feedback and control loops. The sample frequency (meetings and communications) and the key variables to control (metrics) are identified and ongoing project actions respond according to the system design.

Successful projects of any stripe rely on the age-old concepts of anticipation, execution, and follow-through. We will show project managers how the tools we use every day provide benefits and success while reducing the nuisances and bypassing struggles.

1.1.3 Comparison of Approaches

We will demonstrate how the various approaches to project management relate to each other. Not only does the compare and contrast section have pedagogical value, but it should also encourage cross-pollination among project management approaches. This inter-approach exposition will occur throughout the book. We will also show—with the exception of the details— that the diverse approaches to program/project management behave as interpretations of the main theme of project management.

1.1.3.1 Automotive Industry Action Group

The Automotive Industry Action Group (AIAG) publishes a package of seven paperbound resources sometimes known as “the magnificent seven.”

These books define the following areas of automotive interest: 

• Quality management systems.
• Quality system assessment (QSA).
• Measurement system assessment (MSA).
• Production part approval process (PPAP).

Figure 1.1: The QP Model

Figure 1.2: AIAG development process

• Advanced product quality planning (APQP).
• Statistical process control (SPC).
• Failure mode and effects analysis (FMEA).

Figure 1.2 illustrates the project phases according to AIAG.1 However, while this figure implies time dependencies, we selected an arbitrary horizontal representation of the phases for illustration only. Specifically, it is not always desirable to have the product design and process design happen simultaneously, although the team may choose concurrent engineering for competitive reasons. The team considers the process from the beginning without dominating or stifling product design.

The AIAG also sells numerous other publications in support of automotive design, development, and production. One version evolved as a variant of FMEA: the machinery FMEA or MFMEA.

Of the seven principal works by AIAG, the APQP publication defines automotive design and development for new products. The phases of the APQP are:

1. Planning.
2. Product design and development.
3. Process design and development (manufacturing- or service-oriented).
4. Product and process validation.
5. Production.
6. Feedback assessment and corrective action (all phases).

APQP represents a useful template for program management. It presents a rational approach to product and process development and it generalizes to services and embedded development.

1.1.3.2 Department of Defense

The United States Department of Defense (DoD) approach to projects and programs uses significant milestones such as formal design reviews. MILSTD-1521B defines these reviews to be:

1. System requirements review (SRR).
2. System design review (SDR).
3. Software specification review (SSR).
4. Preliminary design review (PDR).
5. Critical design review (CDR).
6. Test readiness review (TRR).
7. Functional configuration audit (FCA).
8. Physical configuration audit (PCA).
9. Formal qualification review (FQR).
10. Production readiness review (PRR).

Clearly, if the development team works on a software-free subsystem, the software reviews disappear from the project plan.

1.1.3.3 Institute of Electrical and Electronics Engineers

The principal Institute of Electrical and Electronics Engineers (IEEE) document defining project management is IEEE-1220, an updated and more detailed version of MIL-STD-499B (draft), a military standard that never became a full standard. The typical organization of a project under IEEE-1220 is: 

1. System definition.
2. Subsystem definition.
3. Preliminary design.
4. Detailed design.
5. Fabrication, assembly, integration, and test.
6. Production.
7. Customer support.

1.1.3.4 Electronics Industry Association

Other standards for system development exist beyond IEEE-1220. These include Electronic Industries Alliance (EIA)-632, Processes for Engineering a System and ISO/IEC-15288, Systems Engineering: System Life Cycle Processes among others. Also, standards organizations seemed to have developed a penchant for further refining organization/process models into a new format called “Maturity Models.” These models define an aging/increase in wisdom approach to organization improvement. EIA-632 looks at programs such as:

1. Assessment of opportunities.
2. Investment decisions.
3. Systems concept development
4. Subsystems design and predeployment
5. Deployments, operations, support, and disposal.

1.1.4 Process Management Areas

The process management areas found in all project management approaches include many of the following:

• Project management processes – collecting management tasks.
• Requirements analysis – defining the scope.
• Functional analysis and allocation – further defining the scope, the divergence action.
• Design synthesis – taking ideas and putting them together, the convergence action.
• Verification and validation – ensuring we meet quality requirements.
• Process outputs – each step in development of a product, service, or embedded software has deliverables.
• Work breakdown structure – the heart of resource management and cost allocation.
• Configuration management – controlling hardware and software release so that we know what we have.
• Technical reviews and audits – keeping the program/project on track.
• Tradeoff analyses – are we checking all of our options?
• Modeling and simulation – wonderful when we can do them.
• Metrics – introducing objectivity.
• Risk management – managing the inevitable challenges that arise.
• Planning – schedule, cost, and quality.
• Product improvement strategies – during development and after.
• Integrating system development – putting all components together.
• Contractual considerations – managing commercial issues.
• Management oversight – part of any quality system.

We feel that configuration management and product improvement strategies specifically belong to quality management systems like ISO 9001:2000. During the course of this book, we will emphasize the items we know, from our experience, belong to project and program management.

This book has illustrations of all the major operations that must occur for successful project management to happen. These graphics do not present every input, output, and interaction, but rather the key concepts necessary to implement a project.

1.1.5 Staged-Gate Methods in General

1.1.5.1 What Is a Gate?

A gate occurs as a milestone in a project schedule where the project team reviews the contents or deliverables of the phase at the end of that phase to decide if the project moves on to the next phase. Then, the team observes, reviews, measures, quantifies, evaluates, and critiques the project to determine if the project is at a point where designated gatekeepers decide to move to the next phase or reject the project. The team reviews the output deliverables as a check to ensure they meet the input requirements of the next phase. Once the team completes a phase gate, the next phase commences with no reversal to the previous phase—a one-way trip.

1.1.5.2 Reasons for Gate Reviews

We also call the gate review “kill-points.” At the end of any particular phase, the team conducts a review to verify that project deliverables will fulfill the original needs defined by the development process. Frequently, the enterprise will wed the gate review with a business environment review as a means of verifying the relevance of the project. If the competitive landscape changed significantly, the program or project is no longer relevant and therefore merits discontinuation. Also, customers (internal and external) must know that gates function as kill-points and the program manager must not fear to inform the team that gates are kill-points.

Additionally, reviews allow for recalibration of the schedule. Even as the team evaluates actions that have taken place, they should consider the relevance of the existing project schedule. Difficulties occur during recalibration of the schedule if customers refuse to modify their schedules. Our experience suggests letting the customer become aware of schedule risk immediately rather than delay until the supplier or customer relationship degenerates.

Risk management generally includes the topics of management risk identification, planning, assessment, and handling (sometimes called “mitigation”), see Figure 1.3. We find an abundance of project management books that detail the techniques for handling risk. One such book, Project & Program Risk Management: A Guide to Managing Project Risks and Opportunities, by R. Max Wideman [Wideman 1992], is a good source for learning how to manage risk.

1.1.5.3 Objectives

If the reason for undertaking the project no longer remains valid or if the project output misses achieving project goals, then early awareness helps reduce the financial exposure of the project (that is, the amount that the enterprise loses on the project)

Figure 1.3: Risk management

Figure 1.4: Gate reviews

The goals of a review are Janus-like (see Figure 1.4) in that a review looks forward and backward. In the backward-looking portion of the review, the team, with the executive staff present, recapitulates the progress of the project to date and assesses the status of the project as it stands during the review. In the forward-looking portion of the review, the team assesses the reality of the schedule, performs risk analysis, and updates the budget.

The team executes these reviews with a critical eye and a willingness to terminate the project or program if necessary or prudent.

The team conducts these reviews in order to: 

• Ensure on-track project deliverables (schedule/scope/cost).
• Compare deliveries to date with the reason for the project and terminate if necessary.
• Ensure the next project phase identifies requisite inputs to promote success. 

1.1.5.4 Gate Targets

The program manager, in concert with the project or launch team, selects gate targets to improve the probability of success and to limit the financial damage to the organization if the project becomes a failure—they function as decision points. Many companies have a published launch process with predefined gate targets; for example, pilot runs, run-at-rate (simulated full production), and start of production. Other companies may use in-process reviews scheduled on a regular basis (e.g., biweekly) to measure progress and assess risk. In some cases, a gate target fiasco drives the gatekeepers to terminate the project during or before the review.

Any factor that leads to a disruption of program or project progress becomes a candidate for risk assessment. These factors derive from either internal sources of the enterprise or arise from an external source (e.g., government regulatory requirements). Gate targets function as a control mechanism to certify that action occurs regarding project continuation or termination.

For early gate targets, the team will want to test critical and highrisk product design features and test new manufacturing process techniques. Some gate issues revolve around mandatory industry certifications; for example, PCS Type Certification Review Board (PTCRB) for Groupe Special Mobile or Global System for Mobile communications (GSM) wireless devices.

1.1.5.5 Importance Of Gate Target Selection

The gate target approach lends structure to the project. Each segment of the process leading up to a gate target will have cost, quality, and schedule goals built into it. Frequently, program managers will define the gate targets in terms of entrance and exit criteria and record the results in a simple checklist. Where possible, the project manager defines the decision path on key gate targets before a project starts or well before a review is done on a specific target.

1.1.5.6 Measurement Of Targets (Statistics)

Keeping measurement on target dates and target spending favors future project managers by allowing for statistical analysis based on project histories. For a given project manager, each kind of scheduled activity begins to take on a characteristic probability distribution. In some cases—for example, software development—the model for the distribution of the level of effort becomes a log-normal distribution.

The beauty of this system lies in the ability to use the data later for modeling project plans. Even a simple spreadsheet—Excel, for example—evolves into a model for the progress of a plan. The development team can model each target using the historical probability distribution functions for that particular task and then feeding those times into the next dependent task. Indeed, this method of analyzing schedules and budgets mimics the Program Evaluation and Review Technique (PERT) method created almost 50 years ago for the U.S. Navy’s Nautilus submarine program. The Navy PERT planners used estimated values for pessimistic, nominal, and optimistic completion times and weighted them based on professional experience. The statistical approach—project simulation—we recommend relies on historical data and represents a better empirical model than educated guesses.

The following tools provide the power to build probabilistic models: 

• Mathcad.
• Mathematica.
• MapleTM.
• S-Plus.
• R.
• MATLAB.
• Scilab.

Any good quantitative tool allows the mathematically oriented program manager to build a simulation of the project. In turn, the simulation provides important data for decision support; for example, the variance in expected project completion dates.

1.1.5.7 Example Of A Phased Project

As we indicated, per APQP, automotive development projects always decompose into stages. In addition, the consensus management areas work within the automotive framework. A phase or stage gate provides the terminus for each stage. Each of the project segments illustrated below clarify and refine the project output. These segments reduce the risk to the organization by providing a map for the project team, a clear set of deliverable products, and criteria for project success.

Figure 1.5 provides one illustration for the gate review order. The review points may not happen as illustrated and sometimes evolve into a combined event; for example, after the product and process development phases when linked as shown.

Figure 1.5: Phased approach

We can structure the project phases in different ways. The phases and their purposes are the result of organization choices, such as: 

• Priority assessments.
• Product delivery processes.
• Cost control philosophies.
• Risk philosophies.
• Needs of other parts of the organization.
• Needs of end customers. 

For the sake of consistency, we present the project process described by AIAG, which has the following steps:

• Voice of the customer.
• Product development.
• Process development.
• Product verification.
• Process verification.
• Start of production.
• Launch.

Later chapters handle each of these phases. We discuss the objectives and typical actions to achieve those objectives within each chapter.

It is important to note, while a single project manager may have to handle each of these phases, it is equally possible that there are project managers for each phase in the project. For example, for the early project phases, having a project manager who is skilled in the art of generating a number of possible solutions to the design could be beneficial. Through the production phase, it may be worthwhile to have the project run by a person skilled in the production processes. The following sections illustrate an automotive model for phased approaches to delivering a project. However, any industry can benefit from this approach—including the service industries.

Concept Study: This phase provides multiple ideas for achieving market and organizational targets. This phase starts the creative phases— producing various concepts with the potential for achieving organizational goals and for identifying market constraints. We see examples of gate passing questions for this phase in what follows:

• What are the markets in which the proposed product will complete?
• What is the market size for the proposed product?
• Have we identified a particular market segment to achieve a focused effort?
• Are there competitors in these markets? who are they? what can be learn from them?
• Does one of the proposed concepts better meet these product objectives and market goals?
• Does the estimated development and piece cost fit targets?
• Does one of the concepts present lower risks?

Clearly, the team can tailor these questions for embedded development and services.

Detailed Development: During this phase, the engineering members of the team refine and document their design solution. Detailed development applies to both product and process design, as a process of progressive refinement occurs to produce the desired result. We reflect on the following examples of gate-passing questions for this phase:

• Do the specifications for the product fulfill product targets?
• Do the estimates for development meet available resources?
• Is the development time consistent with the product availability needs?
• Does the product meet organizational financial requirements?

Tailoring for embedded development and services is again very simple.

Final Development: During this phase, the team refines and documents the selected design solution. Final development applies to both product and process design, since the process of progressive refinement moves to closure and final product release. Examples of gate-passing questions for this phase are the following:

• Does the developed product meet design specifications?
• Does the product meet financial requirements?
• Does the estimated quality and reliability level meet the market requirement?

Manufacturing Development: In this phase, the manufacturing function uses the qualified design to exercise production line processes to verify they can deliver the product at required quality levels and production volumes. Much of the manufacturing process development can and should happen during the prototype, sample, and pilot units. Waiting until the qualified design to start the manufacturing process does not work. To qualify a design, the team will make a product with techniques and processes that represent production. Manufacturing or process development cannot be done in parallel; however, the team will want to minimize the variation.

In some enterprises, these steps include pilot runs, runs-at-rate (to determine cycle times), and start of production. In a service company, the development team exercises the service in a pilot market, executing the service in more than one market, and final launching of the service. Examples of gate-passing questions for this phase are the following:

• Does the production line manufacture products that meet specifications?
• Can the line produce the desired volumes?
• Can the line build the product that meets first run yield?

The team can tailor these questions also.

1.1.6 Project Management

Project management collects activities and tasks to achieve a set of goals.

These tasks go beyond the execution of design responsibilities to include plans, schedules, and maintenance. In the most general terms, project management behaves as a control system that includes monitoring and corrective actions designed to minimize the risk of failure while driving toward the goals.

Another view of project management asserts a discipline for defining and achieving targets, while ensuring the effective and efficient use of resources. These resources include skills, information, time, money, locations, tools, and people. Project development lies within the domain of a project manager who often has little responsibility for the identified activities that produce the result. The project manager makes headway by facilitating interaction of the assigned project resources, removing road blocks, and promoting the understanding of project goals by team members. These activities occur to reduce the risk of failure while achieving the targets for the project scope and for quality within schedule constraints. When the project manager also carries technical responsibilities or must produce deliveries for the project, risk increases. In short, we suggest the job of the project manager lies in managing the project rather than acting as a technical team member.

Frequently, the team will see significant effects from late delivery, particularly when the project supports a regulatory change. Delivering an engine that meets a new U.S. Environmental Protection Agency (EPA) requirement by the government-imposed date remains important to automotive enterprises, because they will have no revenue and no profit if legal restrictions forbid the sale of their products.

The project management triangle, shown in Figure 1.6, retains relevance through the life of the development: the project scope, schedule, quality, and cost contain the product development and delivery aspects. Should the volume of the product change (for example, new features), the schedule, quality, and cost boundaries will change.

Figure 1.6: Project scope triangle

The consensus approach identifies a management area, called planning, as illustrated in Figure 1.7. This area defines those project aspects that support managing and achieving the time-related goals of the project. Project schedule estimation lies within the domain of planning. The following figure shows the planning interaction with the project. The project manager and team must have schedule integrity. Figure 1.8 defines the process interactions that ensure the quality of the product. While this figure does not capture every input, it captures the major project process deliverables and interactions, including documentation to identify and ease the achievement of quality targets. The quality assurance plan documents the activities that maintain the quality of the project and subsequent product (applies to both services and manufacturing).

Figure 1.9 illustrates the management area for cost control. The actions executed in this area determine the resources required and the estimating and budgeting activities. The work breakdown structure (WBS) represents a key input element to this process since it defines required activities for each cost center. The cost control area uses earned value management techniques to monitor the state of the project toward the plan and budget.

The definition of the project boundary represents the project scope. The project scope defines the project objectives and the deliverable products— it is developed as a result of the initial requirements analysis and functional allocation. Figure 1.10 illustrates how we define processes for identifying and controlling the project. The project charter, scope statement, scope containment, and the WBS belong to the scope definition as key outputs.

Project scope, objective, and deliverables must be logical. The project manager cannot assign a task to a part of the team that does not have the capability to execute the task. For example, the team should see no logic in assigning a task that requires software development to a team member when the contract does not allow that person access to software. The project manager and the team should access and re-access realities when it comes to scope, objectives, and deliverables.

Figure 1.7: Planning/scheduling

Figure 1.8: Quality and product integrity

Figure 1.9: Cost control

Figure 1.10: Scope control

1.1.6.1 People

Resource allocation becomes a critical aspect of delivering a project because projects work within limited resources; that is, they are finite capacity processes and the team should understand and model them this way. Limitations range from monetary constraints to access to specialized resources (exotic skill sets).

1.1.6.2 Limited Resourch

In our experience, the resource issue grows into the most common stumbling block to achieving goals (see Figure 1.11). This issue seems to occur in situations where the enterprise has insufficient resources (capacity) and resources (people) must time slice their effort in order to provide deliverable products.

Figure  1.11: People and resources

Additionally, pressure to make efficient use of resources and reduce redundancy creates an environment from which it becomes difficult to recover when key people go on vacation or leave for other opportunities. Mature organizations try to manage the loss of knowledge by establishing succession plans that spell out the availability of skills and provide for stepping in by other individuals.

Resource Provision: This section of the standard requires that the compliant organization identify their resource requirements explicitly. Additional considerations relate to the allocation of resources once they have been identified. Na¨ıve identification of a resource does not make that resource available for tasking.

Human Resource Constraints: The program manager coordinates with human resources the moment he chooses a team for the project. At the onset of the project, the team behaves as a barely-unified collective than one might call a “team.” The bonding required to create an effective team takes time and, frequently, exertion. Additionally, common interests and shared experiences can hold teams together. Figure 1.12 provides an approach to managing human resource constraints.

Infrastructure: The resource infrastructure consists of the hardware, knowledge, and services that support the project members. The lack of proper tools—even something as ephemeral as knowledge—hamstrings project progress and increases quality, schedule, and cost risk.

Work Environment: The work environment must be conducive to producing a quality product. Everything from appropriate tools to human factors issues is under this heading. Tools can involve location and hardware software and services needed to accomplish tasks. If development work occurs outside the United States, the developers may find it difficult to purchase certain kinds of regulated software.

1.1.7 Project Manager’s Role

Project managers share the same responsibilities whether they work in automotive or nonautomotive industries. The primary difference in automotive project management lies in the plethora of quality documents and tasks demanded by the automotive marketplace and the ISO/TS 16949 quality standard. Figure 1.13 illustrates the project manager’s role within the organization. In the organization below, the management layer of the respective functions coordinates the project. The project manager does not bear the bulk of the burden to deliver the project.

A matrix models the organization as shown in Figure 1.14. In the matrix organization, the project manager has people who report to him from various parts of functional departments. These people report to both the project manager and the functional manager. This dichotomy can negatively affect the employee and requires much communication between the project manager and the functional managers. In this organization model, the project manager has more responsibility and a higher set of expectations than in models that favor functional management.

Figure 1.12: Managing human resource constraints

Figure 1.13: Functional organization

 

 

 

 

Figure 1.14: Matrix organization

 

 

 

 

Figure 1.15: Project organization

In the organization type in Figure 1.15, the project manager coordinates the project with the functional areas represented by those working on the project. The project manager has the responsibility of reporting the status of the project to management and has the majority of the control over the human resources of the project.

It is important to know where your organization and any supplying organization fit on this continuum (see Figure 1.16). These organizational structures identify and, to some extent, dictate authorities and responsibilities. Solving an issue via the project manager of a functional organization may not be the best approach for timely resolution of a project concern.

1.1.7.1 Organization & Integration

A good project manager establishes communication with all stakeholders and provides an update mechanism to keep them involved and aware of project progress—enhancing meaningful communication improves organization and integration of development. In January 1996 the Gartner Group, in its paper Project Management Skills: Avoiding Management by Crisis, identified insufficient involvement of stakeholders and infrequent communication with sponsors as leading causes of project failure.2 

Figure 1.16: Project organization

However, this does not mean that all communications or even the bulk should be focused upon the stakeholders. The project manager must be able to communicate throughout the project. The Little Black Book of Project Management [Thomsett 2002], by Michael C. Thomsett, identifies five areas of communications breakdown:3

1. Team member to team member.
2. Project manager to team member.
3. Project manager to outside department manager.
4. Manager to outside resource.
5. Manager to executive.

Communication challenges are not exclusive to automotive development. However, automotive development often requires input or project participation on a global basis, where the time zone differences alone provide added stress. The role of communications in project management finds expression in the 36 Hour Course Project Management [Cooke and Tate 2005], where you cannot automate the clarification of assumptions, integration of inputs, and the iterative process of analysis.4

Kim Heldman in her book Project Managers’ Spotlight on Risk Management [Heldman 2005] says, “communicating is the most important responsibility you have as a project manager. Ninety percent of your time is spent in this activity. I can think of no other activity that has a greater impact upon project success.”5

One model of communication [Shannon, 1948] pictures information flow traveling over a channel. An equation defines the number of communication channels (the number of interconnections) and the result relies on the number of people required to interact.

The communications plan articulates the communications requirements for the project. A communications plan helps to facilitate communications among the required parties, particularly when an issue needs escalation to a higher level of management. For small projects—those projects with few stakeholders—this formality dissipates. The project team should consider how information distributes among participants. The team specifies activities for creating and reporting decision documents and consults with customer and stakeholder for their responses. The project manager chooses procedures for creating, storing, accessing, and presenting information. These acts define what information the team needs and the format required by the project participants, including stakeholders.

The typical contents of a communications plan comprise the following:

• Information distribution: A description of the communications distribution method—often a chart detailing the communications responsibilities. ISO/TS 16949 requires the inclusion of customer specific documents.
• Information description: A description of the type of information for distribution, format content, and level of detail.
• Information schedule: Method for assessing and rates of delivery of information.
• Progress reporting: A description or reference of the process for collecting and reporting project status or progress reports.
• Communications plan revision: Method for revising, updating, and otherwise refining the communications management plans as the project progresses.
• Administrative Closure: Generating, gathering, and distributing information to formalize a phase or project completion. Administrative closure consists of documenting project results to formalize acceptance of the proposed or completed product by the sponsor or customer. It includes collecting project records, ensuring that they reflect the final specifications, analyzing project success, recording effectiveness and lessons learned, and archiving such information for future use.

The team’s organization and integration activities identify project requirements for each process of the project. Figure 1.17 illustrates the actions needed to fulfill the control of communications during a project, which leads to enhanced organization and integration of the team. Communications link the project, the customer, and the supplying organizations into a social network. It provides feedback (in the control process) to the organizations regarding the status of the project.

1.1.7.2 Customer Focus

The project manager focuses on the client or customer, particularly in customer-focused product lines. Getting to know the customer, communicating often and clearly, and cultivating a personal relationship with customer representatives functions as key methods for achieving goals due to increased opportunities for influence and persuasion. From the customer’s point of view, the project manager embodies the project and serves as the principal point of contact. One ultimate objective of strong personal relationships lies with the development of an organizational relationship with the customer. A project manager without a personal relationship with the customer metamorphoses into a note taker with little influence, which reflects poorly on the organization.

Figure 1.17: Using communications to integrate development

1.1.7.3 Brainstorming

Brainstorming and mind storming are, respectively, group and individual techniques for generating potential solutions for a designated problem or goal. Typically, the session facilitator solicits criticism-free suggestions in order to increase the quantity of ideas followed by a reorganization of ideas, most often in the form of an affinity diagram. The brainstorming team follows diagramming with idea selection.

1.1.7.4 Technical Solutions

The project manager possesses no role in solving all technical problems.The project manager ensures that a technical solution can be found and, if not, manages stakeholder expectations.

Often, management passes on projects to technical people with the belief that a technically competent individual performs equally well as a project manager. Technical prowess helps but does not guarantee success as a project manager. It seems that often this technical ability keeps the project manager in the realm of the technical, forcing or dictating solutions instead of performing project management work and evoking the best solution from technically responsible individuals.

1.1.7.5 Quality

The project manager accounts for the overall quality of the project and integrates this work with various functional departments. The challenge lies in balancing quality against cost and schedule without degrading the product. The quality scenario becomes more complicated when quality over time (reliability) derives from a customer requirement.

1.1.7.6 Facilitate Team Creation

While a project manager may receive a staff from management that does not mean that a team exists. Teams develop through a body of common experience and shared goals, and management cannot force a team to exist. The project manager enhances the probability of success and decreases project risk if he can grow a team from the assigned staff. Additionally, the project manager emphasizes the responsibility the team has regarding delivery of the final product.

Key characteristics of an effective team are:

1. Strong team identity: having a team name and the rest of the organization knows of the team.
2. Uniqueness: feeling like “we are extraordinary.”
3. Commitment: feeling ownership in a project—that is, buy-in.
4. Competency: acknowledging team competencies.
5. Fun: creating a fun-loving environment.

Bad teams may also happen. Neither type of team occurs randomly, but rather as the result of organization dynamics and managerial involvement. Some key attributes or conditions that spawn the creation of a poor team are:

1. Lack of trust among team members.
2. Unfocused time spent on multiple projects.
3. Incompetence and lack of appreciation for the capabilities of other individuals.
4. Arbitrary deadlines.
5. Misdirected communications.
6. Lack of respect for other teams or parts of the company.
7. Teams within teams (factions).

1.1.7.7 Conflict Resolution

Project managers may have to resolve intrateam conflicts. Not all conflict becomes counterproductive and not all conflict requires mediation from the project manager. Guffey [Guffey 2003] identifies two types of conflict: cognitive conflict and affective conflict.6 Cognitive conflict focuses on issues and on developing good creative solutions to problems as the dialectical interplay yields higher order reconciliations of ideas. Affective conflict focuses on feelings and personalities. The project manager understands when the conflict produces a negative effect on the team and facilitates resolution by:

1. Avoiding blame or scapegoating.
2. Clarifying and defining the issues.
3. Listening intently to each party.
4. Stating points-of-view clearly.
5. Working on points of mutual agreement.
6. Brainstorming or mindstorming alternate solutions.
7. Agreeing on a potential solution.
8. Documenting the agreement (making a contract).
9. Auditing the solution for efficacy.

1.1.8 Product Development Team Meetings

A good project manager includes more than the design engineering staff in the development of the project. With manufacturing input from the start, the team should find it possible to design the product in a way that takes advantage of the strengths and existing methods and tools of the manufacturing facility. Cross-functional team meetings lead to actions within the organization to coordinate delivery of project results to production. These actions occur in the final phases of the design when the design becomes solid and ready for production tooling.

Circumstances generally require some team involvement at each stage of the project or program for prototypes, samples, or pilot runs. The project manager balances design with manufacturing. During the commencement of the prototype build, manufacturing may review and provide feedback for consideration, but as the project advances manufacturing receives more weight. At the pilot stage, manufacturing should correspond with design.

Few programs today have the luxury of making design changes just for manufacturing. The manufacturing process may trod one step behind design, a situation not uncommon during concurrent engineering. Note that these situations can also affect service products when implementation and planning don’t synchronize.

Representatives from different functions of the organization make up a diverse team. Typically, the team members include the following:

1. Project manager from supplier (when applicable).
2. Internal project manager.
3. Supplier quality assurance (SQA).
4. Shipping and receiving (packaging).
5. Production line representative.
6. Design.
7. Documentation.
8. Manufacturing.

The project manager does not have to require all participants to attend all meetings; rather, each area of expertise participates in its action items.

The design of these meetings coordinates the controlled introduction of the product to the production line efficiently while minimizing disruption. The meeting should not evolve into a forum for solving problems. Occasionally, when a problem requires interactive collaboration, the meeting emerges as a tool for team problem-solving. Like most meetings, team members should collect the information before the meeting, distribute it during the meeting, decide on it, and follow with action.

1.1.9 Program Management

We define a program as a collection of projects executed concurrently.

These projects require coordination and simultaneous delivery to meet overall objectives. A master schedule helps synchronize these subproject schedules. The master schedule provides structure for the deliverables for the subordinate projects. Vehicles undergoing major changes or newly created vehicles require the coordination of components to one delivery schedule, a specified cost, and program and project quality requirements. The same approach would apply to any program designed to deliver a new service.

1.1.10 Embedded Development

This book adds an emphasis on development of embedded or software projects. With an embedded project, the development team has a significant portion of the development work in software located on the product itself (some form of nonvolatile memory). An embedded development project consists of software development for a microcontroller or microprocessorbased hardware. The features of the product developed reside in the software application. The software can consist of an operating system for a complex project along with an application code. Product-specific features reside in the application code. The software and the hardware differentiate poorly (hence the frequently used neologism “firmware”). Firmware weds the hardware and software because, on its own, the hardware has no function. The engineers work the hardware and the software development simultaneously (see Figure 1.18) in order to achieve a form of inorganic symbiosis; that is, the final product results from a dialectic exchange, a back and forth adaptation of each component to the other.

Software possesses its own problems; for example, the increase in complexity of the software product as the number of paths and variable values increases with added features. Version control, testing, and good configuration management (see Figure 1.19) help to verify, validate, and control embedded software.

1.2 Product Integrity and Reliability

With the idea of product integrity, we refer to a more general concept of integrity: a oneness, an entity with no discontinuities, a form of honesty. Reliability refers to quality expressed over some unit of time and typically has overtones of durability and robustness.

Figure 1.18: Configuration management

Figure 1.19: Configuration management

1.2.1 Product Integrity

Stage targets can promote product integrity and team integrity during every phase. The product and team retain their integrity when the team and management review the development work with ruthless rectitude, stripping out unnecessary features, defining realistic next steps, and controlling the scope of the work.

1.2.2 System-Level Testing

System-level testing normally occurs during the end game portion of a project or program. Then, the developers have enough production-level material to perform a meaningful test with all modules and submodules exercised. This event acts as the first real attempt to achieve a high level of verisimilitude. Individual components receive testing from tools that simulate the target system or from existing systems converging to the final product. Testing should occur as early as feasible and as often as possible. This approach applies to services as much as it does to hardware and software products.

1.2.3 Reliability

As mentioned above, reliability refers to quality over time. The product must meet requirements/specifications over a defined time. In some cases, parts of a product may degrade; for example, end users expect automotive tires to degrade with time—in effect, a consumable item.

1.3 Cost

Cost estimation begins with the purchasing function, sometimes called “acquisition,” especially during the formative phase of the project. The accounting function provides cost controls during the course of a project. Cost targets inform design decisions.

The delivered to estimates graphic, Figure 1.20, illustrates typical project expenditures and payback for those expenditures—part of the decision for accepting or rejecting the project. In short, when the results of the project add to the profitability of the organization.

Underestimating the needs for the project places the project at undue risk by potentially causing resource starvation. The estimating organization may lose credibility. Overestimating the project cost alienates the customer due to poor return on investment. Figure 1.21 illustrates a project that has a cost overrun. In this example, the situation has put a delay in the amount of time for the organization to recover the project investment. In reality, if the cost overrun becomes too high, the project may have no payback at all.

Figure 1.20 Delivered to estimates

Figure 1.22 illustrates a schedule overrun. Late delivery of the product delays payback for the organization, a condition frequently referred to as “opportunity cost.” In the example below, the team would see no associated cost overrun. In reality, if the situation delays the schedule, a high probability exists for a cost overrun. In this instance, the organization launches the product late, with some potential opportunity cost.

Figure 1.21: Cost overrun

Figure 1.22: Schedule overrun

In Figure 1.23, the product birthed on time and within development budget. However, the product cost ended up being higher than anticipated and the profit margin on each unit became lower than anticipated. This undesirable situation prolongs the time it takes for the company to pay off the development work and begin profiting from the project.

In order to know how much profit returns to the company when quoting a project, the team must understand the level of effort it takes to deliver the project and the product cost. If the enterprise makes money conducting the project, but not in selling the resulting product from the project, then product costs will not meet target values well enough to generate the anticipated margin. How does the value of the part change? In manufacturing enterprises, the project manager will invoice during-project parts at a prototype rate much higher than the actual material cost, while invoicing the production parts at a price set related to a corporate hurdle (e.g., internal rate of return (IRR), net present value (NPV), payback, or any combination of these). A fixed cost contract means the supplier owns the risk of producing the project results within the defined cost, since no opportunity for recovering the cost exists. Cost plus firm fixed-fee contracts, on the other hand, allow the supplier to recover development costs.

Figure 1.23: Component cost 

1. Development cost.

      a. The make or buy decision.

      b. Value engineering.

      c. Material composition.

      d. Development processes.

      e. Product specifications (can also apply to manufacturing).

                  i. Product standardization.

                  ii. Tooling cost.

                  iii. Material sourcing.

                  iv. Material substitution and obsolescence.

      f. Verification requirements.

2. Sourcing.

      a. Travel.

      b. Human resources.

3. Manufacturing cost.

      a. Manufacturing equipment.

      b. Manufacturing location and facility.

      c. Manufacturing material.

      d. Manufacturing process.

      e. Manufacturing verification requirements.

4. Maintenance cost.

      a. Extensibility/obsolescence.

      b. Product life cycle.

      c. Manufacturing material.

      d. Manufacturing process.

 1.4 Structure of Sections

This book lays out the program sequence analogously to the sequence specified for APQP. The chapters are:

1. Projects and Project Managers.
2. Technical Tools.
3. Concept.
4. Product Development.
5. Process Development.
6. Validation of Product and Process.
7. Release to Production.
8. Failure Reporting Analysis, and Corrective Action System (Phase).
9. Product Support.
10. Program Management.
11. Final Thoughts.

Excerpted from the book: Project Management of Complex and Embedded Systems by Kim H. Pries and Jon M. Quigley. © 2009 CRC Press. Reprinted with permission of the Publisher.

Click here to check out their latest book Scrum Project Management

About the Authors

Jon M. Quigley PMP CTFL is the Manager of the Electrical and Electronics Verification and Test group at Volvo 3P in Greensboro North Carolina.  He is also a principal of Value Transformation, product development training and cost improvement organization and a founding faculty member of Practical Project Management.  Jon has more then twenty years of product development experience, ranging from embedded hardware and software through verification and project management.  Jon has significantly improved product and process cost improvements

Jon has won awards such as the Volvo-3P Technical Award in 2005 going on to win the 2006 Volvo Technology Award. Jon has secured six US patents over the years with another one in the US Patent Office which is in the pre-grant stage.  These patents range from human machine interfaces to telemetry systems and drivers aides.  Jon has a Bachelor of Science degree in Electronic Engineering Technology from UNCC, an MBA in Marketing and a MS in Project Management from City University of Seattle.  Jon has membership in SAE, SAVE, AIAG and PMI (holding Project Management Professional Certification).  Jon also has the CTFL certification from ISTQB.  Jon is the co-author of the books:

• “Project Management of Complex and Embedded Systems” ISBN - 978-1-4200-7205-1
• “Scrum Project Management” ISBN 978-1-4398-2515-0
• “Testing of Complex and Embedded Systems” ISBN 978-1-4398-2140-4

In addition to these books, Jon is co-authoring with Kim two focus books for Software Test Professionals:

• “Saving Software with Six Sigma”, ISBN 978-0-9831220-0-5
• “5 Ways to Trample Testing Problems”

Jon and Kim are working on two additional book, Total Quality Management and Project Management and the second book Value Engineering.

Jon also with Kim is a Contributing Editor of Software Magazine with the Software Engineering Sages Column.  Additionally, with Kim H. Pries, he has written more then thirty magazine articles that appear in magazine such as:

• Embedded System Design
• EDN
• Software Development Times
• Software Test and Performance
• Product Design and Development
• Automotive Design Line
• All Business online
• Electronics Weekly
• Project Magazine
• Design Reuse
• DSP Design Line
• Quality Magazine
• Advanced Trading
• Food Manufacturing
• IMPO Magazine
• Manufacturing.net
• Tech Online India
• EDA Design Line
• Software Magazine
• Taylor and Francis news letter
• Villanova University Computer Science

He has also given numerous presentations at product development conferences about various aspects of product development and project management. Jon lives in Lexington North Carolina with his wife Nancy, and son Jackson. Email Jon at jon.quigley@valuetransform.com.

Kim H. Pries, APICS CPIM and, as a senior member of ASQ, the CQA, CQE, CSSBB, CRE, CSQE, CMQ/OE certifications. Kim was the Director of Product Integrity and Reliability for Stoneridge Corporation as well as being a principal with Value Transformation, LLC, a product development training and cost improvement organization and a founding faculty member of Practical Project Management. During his career in manufacturing, he was responsible for all test and evaluation activities including a hardware laboratory, instrument calibration, hardware-in-the-loop software testing, and automated production test equipment and, at other times, managing a software development team, the plant ISO organization, printed circuit board design, and engineering services. Kim earned a BA in History from University of Texas at El Paso (UTEP); BS and MS in Metallurgical Engineering from UTEP and an MS in Materials Science from Carnegie-Mellon University. Kim wrote a Six Sigma book and, with co-author Jon M. Quigley, a book on project management of complex and embedded systems. He also teaches the ASQ Six Sigma Black Belt Certification class at UTEP professional education; he has used the Six Sigma approach to save over $5 million for a company in a little over two years.  Also with Jon Quigley, he has written more than thirty magazine articles and seven presentations on various aspects of product development. Kim is the co-author of the books

• “Project Management of Complex and Embedded Systems” ISBN - 978-1-4200-7205-1
• “Scrum Project Management” ISBN 978-1-4398-2515-0
• “Testing of Complex and Embedded Systems” ISBN 978-1-4398-2140-4

In addition to these books, Jon is co-authoring with Kim two focus books for Software Test Professionals:

• “Saving Software with Six Sigma”, ISBN 978-0-9831220-0-5
• “5 Ways to Trample Testing Problems”

Jon and Kim are working on two additional book, Total Quality Management and Project Management and the second book Value Engineering.

Kim also with Jon is a Contributing Editor of Software Magazine with the Software Engineering Sages Column. Kim lives in El Paso, Texas with his wife and three dogs. Email Kim at kim.pries@valuetransform.com.

FIRST Update from Team 71, Team Hammond: And so it Begins…
Randy Weber of Team Hammond

Risky Business: Funding Medical Device Innovation
Rahul Sathe, Principal Mechanical Engineer, Surgical and Interventional Products, Cambridge Consultants

Extracting Nuggets from the Invention Mine
Tom Tuytschaevers, a member of our Patent Practice Group