Chapter 4 Project Management Relationships

Roles of Program Management and Functional Organization Management

4.0 Introduction

An Enterprise that has organized to support several major customers or product lines usually appoints program or project managers dedicated to meeting each customer's requirements. Usually, much of the work is performed by functional organizations that have expertise needed across many programs.

4.1 Purpose

This chapter describes the organizational relationships that I believe apply in the conduct of business, with particular emphasis on the role of the program manager as he or she relates to the customer, functional management, and general management within the Enterprise. (Functional managers and organizations in an Enterprise are defined here as those that have an activity as part of their title. Examples are Engineering, Manufacturing, Procurement, Marketing, Shipping and Receiving, Quality Assurance, Accounting, etc.). The context of this discussion is a complex project or program where substantial new development is required.

It is important to keep in mind that customer/contractor relationships exist at all levels of a program -- not just between the company and the ultimate customers. The program manager will act as customer to functional organizations performing work on the program, much as if the functional organizations were outside subcontractors. Therefore it is vital that the program manager and the functional managers negotiate a contract that is realistic and achievable, and that both sides commit to this contract.

4.2 Program Management Role

In preparing for a competitive or non-competitive business opportunity, it is incumbent on the company management to designate a proposal manager, who may also be the designated program manager. This individual will normally be chosen on the basis of his or her ability to organize pre-proposal activities, lead a proposal effort, conduct negotiations, and implement the work if the competition is successful. A small staff, experienced in these activities, forms the nucleus of the proposal manager's organization. The team will also include representatives from all activities that will be involved in implementation if the proposal is accepted.

4.2.1 The Program Manager's Charter

When our model Enterprise undertakes to develop and deliver a major product, the program manager's role is to act as the agent of both the customer to the company and the company to the customer. I like to think of the Program or Project Manager as the General Contractor within the company. This role is to assure that: 1.) an equitable business relationship is established in a contract that defines the work to be done; 2.) a mutually agreed-to cost is established for the conduct of the effort; and 3.) the necessary resources are brought to bear to accomplish the work in accordance with that contract.

In the typical development job, the developer creates a product disclosure. This data includes the necessary analyses, simulations, hardware, software, and tests to prove that the product-- when built in accordance with the design documents, tools and processes described in that disclosure -- will perform the required function in accordance with the requirements of the contract.

In this multi-project model, the program manager relies on the functional engineering organization for creating and validating the design part of the product disclosure. But there is more to the product disclosure than the design. The production or operations organizations have the responsibility for creating and validating the procurement, production processes, and quality assurance portions of the product disclosure. I use the term "operations" to define all those repetitive activities that create the end product.

The responsibility of the program manager in this model is to ensure the success of the program, the customer, and the company. While these are all musts, they are carefully stated in order of priority. Figure 4-1 shows a typical program management organization with three assistant program managers (APMs) reporting to the program manager. The program manager delegates responsibility to the APMs and individual members of the program management team, but it must be recognized that they are acting on behalf of the program manager.

Figure 4-1 Typical Program Management Organization

4.2.2 Assistant Program Managers

One APM position is shown as the Assistant Program Manager - Technical. This individual is the chief technical officer of the program. The technical system requirements for the product and evaluation of what is to be provided to meet those requirements are this individual's job. The "system requirements" part of systems engineering reports to this position, as do the operations analysis and technical performance measurement functions.

A second APM, shown in Figure 4-1 as the Assistant Program Manager - Operations and Plans, is typically responsible for what I will call "program anatomy." The contract delivery requirements usually define the need dates for the products to be provided. Therefore, the program anatomy is largely determined by the lead times of activities necessary to build and deliver the product by the required date given the design documentation, plus the time to design and develop that documentation. Various ground rules, based on program considerations such as risk and contract constraints, may govern those activities. Knowledgeable about how the product will be produced, the program anatomy APM is generally responsible for master scheduling, the work breakdown structure (see Chapter 7), operations planning, and the program milestones and system for reporting progress and accomplishment.

The program manager is the chief advocate for his or her program. In our model program organization, we believe that it is prudent to provide checks and balances to protect the fiduciary responsibilities of the Enterprise to its shareholders. To do this, we provide the program manager with an expert assistant in the financial management aspects of the activity. This person, who is shown in Figure 4-1 as the Assistant Program Manager - Finance and Controls is responsible for assuring that the financial and contract commitments are understood, proper pricing methods are used, and that controls are in place to measure costs incurred and progress of the work. This individual reports to the program manager, but also to the Enterprise CFO, assuring both independent assessment and necessary support from the Enterprise financial accounting organization during all phases of the program.

4.2.3 Program Responsibilities by Program Phase

As the program authority within the company, the program manager is responsible to general management for assuring that an equitable relationship exists between the company and the customer. He or she is responsible for the initial definition of the program in enough detail to allow the proper company resources to be assigned. This definition is often necessary for the proposal itself, as well as for the execution of contractual effort where definition and interpretation of contract requirements with respect to task, performance, cost and schedule must be provided. The program manager is responsible for seeing that the program definition is compatible with the funding plan on a multi-year basis where applicable. He or she is responsible for negotiating commitments with responsible functional managers along with securing the resources to fulfill these commitments.

In the pre-proposal period, the program management team is responsible for assuring that the proper work is done to enable writing a winning proposal. They are expected to have sufficient insight into the nature of the task or procurement to provide mature leadership, as well as recommendations where management support is required for:

1.) the amount of pre-proposal activity that should be authorized in view of the size and worth of the procurement.

2.) the kinds of talent that must be committed to prepare the proposal.

3.) recommendations on strategy for both winning and implementing.

During the pre-proposal and proposal periods, the program manager is responsible for all activities and for assuring that the necessary resources are brought to bear. As in other phases of program management, he or she is expected to draw on functional organizations as required to prepare the proposal in sufficient technical and business depth.

Also during the pre-proposal period, it is vital to determine what components of the product will be developed or produced by suppliers rather than internally as this will form the basis for the program plan and identify the types of resources required. This is called a make/buy strategy, and considers such factors as the skill-set and the cost structure of the Enterprise. The program manager is responsible for the make/buy plan, and must make decisions based on what is necessary to win and perform well on the program. The make/buy plan needs to encompass the engineering, test, manufacturing, operations, and services functions. While the program manager is responsible for the make/buy plan, and must make decisions based on what is necessary to win and perform well on the program, this is not a unilateral responsibility. Because there are often Enterprise policy considerations involved, the program manager must coordinate with the functional organizations and get agreement on the plan. The program manager must be prepared to justify the decisions concerning the make or buy plan. to general management.

Program definition requires the formulation of a program plan, including a master schedule, in sufficient detail to identify the key events for all required effort. It also requires an understanding of the interrelationships of tasks and milestones based on the objectives and characteristics of the program. From this understanding a program "anatomy" can be derived, starting from end-item delivery, and working backwards through all phases of production, development, and initial system definition.

In general, this task of system definition requires the efforts of people who have been through similar development programs and who are familiar with the types of lead times, schedule interactions and constraints that will influence the program anatomy. This expertise will often be centralized in a Program Plans and Controls organization. This organization will provide support for the program definition to each program in accordance with the program manager's guidelines and approval. It will also serve as the focal point for overall program status information, both to the program manager and to general management.

In the formative phases of a program, the program manager must strive to assure that optimism, either within the company or within the customer's ranks, is not allowed to damn the program with unacceptable technical and budgetary constraints. This means understanding what is required in performance and methodology to meet customer needs and how much it is worth to the customer to exceed the requirements, and matching these parameters up in a consistent set. Ideally, it means having a time-phased should-cost estimate with funding coverage. Because of the typical budget cycle, the program manager should be thinking at least 18 months ahead of everyone else.

As a general rule, the program manager should be in a position to know what should be done in a given situation, to make recommendations, and to be responsive to the customer's reaction to those recommendations.

The program manager's primary task is to assure the program's success and the customer's success. The program manager must assume the customer has not planned far enough ahead and therefore should prepare and provide recommendations to help the customer's planning. At the same time, the program manager should not be so foolhardy as to assume that the customer does not know what it needs.

The program manager is responsible for understanding the customer's or potential customer's budget plans and funding constraints. These will be used as a yardstick to determine both the viability of proposed or planned efforts and the program's success. The program manager may and should, where possible, influence and assist the customer in the formulation of those budgets. It is therefore incumbent upon the program manager, in the formulation of the initial estimates, to prepare a "should-cost" estimate, taking into consideration past performance on similar tasks, the effects of inflation using realistic assumptions, and differences in task complexity. Every major system, no matter how complex, can be broken down into elements, which are similar to elements of other previous systems. The funding plan is expected to provide sufficient front-loading and allowance for unforeseen events. Therefore, rough-order-of-magnitude program cost estimates should be conservative, meaning that any subsequent refinement of the numbers will be smaller.

The program manager is responsible to general management for assuring that company commitments are be met. To do this, he or she must assure that the necessary financial resources to do the job are made available and that the company resources are properly employed. This demands a continuity from definition through negotiation of the contract and, subsequently, through the period of performance on the contract. Having defined the program anatomy and proposal ground rules, then, the program manager must review them with the functional organizations that will do the work, resolving any disagreements prior to the proposal. These ground rules may well include a set of cost and performance targets based on knowledge of how much the customer wishes to spend, how much capability it wishes to buy, and the competitive environment. This implies that there may be varying degrees of risk associated with these cost and performance targets.

The program manager defines what must be done at each stage of the program, starting with the pre-proposal activity. In 95 percent of the cases, he or she will not define how the work is to be done, but will rely on functional organizations to define this within their functional expertise and responsibility. The program manager retains veto rights for his program -- a responsibility that is not to be taken lightly.

Given a set of program definitions and proposal ground rules, the program manager must negotiate with the organizations that will perform the work to arrive at an equitable contract during the proposal activity. The word "contract" is used here, because the functional organization is to be considered much as a subcontractor would be -- and the contract is every bit as binding. The contract takes the form of a negotiation of every element of the work breakdown structure to the lowest management level, and it requires responsible individuals who can commit for their functional organization. It requires a clear understanding and agreement on the degree of technical, schedule and cost risk embedded in the commitments. It requires a definition of tasks in sufficient depth to ensure that the job can be done for the money proposed at the recognized confidence factors. It follows, then, that the work breakdown structure must identify the work to be done and provide meaningful cost allocation within those elements. While the cost accumulations structure need not duplicate the work breakdown structure, it is very important that they be a consistent set compatible with the job from both a definition and a control standpoint.

Agreements on tasks and resources, once signed by the responsible manager, are commitments expected to be met. The manager's performance in meeting these commitments will be a primary yardstick of job performance. The extent of known risk to meeting these commitments will of course be recognized in the overall assessment of the manager's performance. It is also important to remember that the commitment is not just the functional manager's, but the program manager's as well. A program manager who makes arbitrary cuts in proposed effort without getting the agreement of those who quoted, and who will do the work, will end up carrying the banner with no army when the contract is signed.

Where subcontractor effort is required, commitments are needed from those subcontractors based on scope in the same manner as if they were an organization within the company. Agreements should be documented and signed by the subcontractor, the committing buying organization and the accepting program manager.

When the proposal is ready to be submitted to the customer, the contractor will hold an Enterprise Management Review. The purpose of this review is to get final approval to submit the proposal, to discuss the risks and what approaches are planned to mitigate those risks. Above all, in a high integrity Enterprise, it is the time that senior management of the Enterprise "gets in the boat" with the program manager and the proposal team. Any issues that remain should be addressed and dispositioned. This review must occur long enough before the submittal date to allow for changes that result from it, or Enterprise senior management will not get in the boat.

Programs should be planned on a realistic basis -- not on a "no-mistakes" basis. There should be time in the schedules to allow for the unforeseen and for corrections when things go wrong. There should be resources planned for correcting designs, repeating tests, repair or replacement of parts or assemblies, developing replacement sources of supply, etc. The difference between the "no- mistakes" resources and the actually expected resources will provide the initial management reserve ; this reserve must not be allocated when the program resources are budgeted.

In the allocation of resources for the performance of work, whether contract activity, independent development, or bid and proposal effort, the same negotiation process should occur. In the allocation of tasks and the funding of independent development work or other discretionary funded tasks, the same "subcontractor" approach applies: the functional organization is the subcontractor. There should be agreement and documentation of the task and resources required, together with a schedule of completion for each element. The organization doing the work, as well as the program manager, must sign off on this contract.

In the case of contract funds, it is expected that agreement will be reached based on the proposal ground rules as modified by contract negotiations. It is therefore incumbent on the program manager to document changes in scope and resource reduction agreements accepted during the course of the negotiations and in-house preparation of "best and final" offers. A representative from each functional "doing" organization, with the authority to speak for the organization manager, should participate in contract negotiations to justify raw resource requirements and technical effort.

It is incumbent upon the program manager to conduct evaluations of the worth of his or her program objectively. In the case of government programs, this means worth to the country, to the customer, and to the company. To do this, the program manager normally relies on a cadre of system analysts. Strong guidance, however, must come from the program manager, who along with general management and the customer must answer questions of system worth.

The program manager is expected to support an appropriate level of systems analysis to develop the models and tools necessary to answer these questions when they arise. Since systems analysis requirements tend to fluctuate by program, the basic analytical disciplines are often centralized in a functional organization to serve all programs. It is hoped that this will level the workload and maximize cross-fertilization in capability, techniques and study results.

4.3 The Role of the Functional Organization

4.3.1 The Internal Subcontractor Relationship

In my model of a multi-program Enterprise, program offices are the "general contractors" within the Enterprise who "subcontract" functional work such as engineering, test, and manufacturing to existing capable organizations within the Enterprise. They do not create separate projectized organizations other than those required for program management itself, unless special circumstances approved by general management require it.

A vital element of this subcontracting arrangement is the delegation of responsibility and authority for management of technical, schedule and cost performance for the job subcontracted. This relationship, as previously described, requires definition of the job starting with the proposal and mutual agreement on the resources required to accomplish it. Budget must be planned and visible for the term of the task to allow the functional organizations to do a proper job of task and manpower planning.

Implicit in this arrangement is the requirement that the functional organizations provide the technical and management excellence needed to fulfill their commitments. The functional manager negotiates the job and the resources with the program manager and is then held accountable for meeting this commitment. He or she must assure the assignment of needed talent and resources, plan and organize activities, assure clear assignment of responsibility for tasks and hardware, and review and approve the output. He or she is expected to provide guidance, when needed, both to the functional organization's representative to the program and to the program manager.. In short, the functional manager is a team member who is contractually bound to the program, and must be ready and willing to be a member of any project team.

The second necessary condition is in management's commitment to the employees. When an employee from a functional organization is assigned to and co-located with a program, there must be no "out of sight, out of mind" situation. The functional organization manager must stay abreast of what the employee is doing and how he or she is performing. Performance evaluations should be joint efforts between the program manager and the functional organization manager. The functional organization manager must also recognize that the employee's assignment is a binding commitment -- there can be no unilateral actions to change assignments.

With these guarantees in place, it should not matter where an employee reports on the organization chart. The commitment is to the program, not to a particular organization.

4.3.2 The Concept of Subsystem Manager

When the product mix of an Enterprise has common technologies required to implement the spectrum of product lines, those disciplines and technologies are probably best grouped in functional organizations that would support all products. In particular where design and development are required, engineering is generally organized along functional capabilities and expertise (i.e., mechanical, electrical) to match the end-product anatomy and is the initial formulator of solutions to meet the end-product requirements. In our model, an individual first level manager in engineering is assigned "ownership" for the successful conduct of the development and production of each major end item or group of items that relate or function together. In our model this individual is called a subsystem manager.

This section describes the assignment of responsibility to, and the authority of, an individual manager within the organization who takes the ownership of a subsystem or equipment to assure and be accountable for: 1.) development of the equipment or subsystem to meet the need specified and 2.) providing that item at the time and place required in a condition suitable for use as intended by the requirements at a cost consistent with expectations . This manager is called the subsystem manager.

4.3.3 Assignment of Subsystem Management Responsibility to Engineering

The subsystem manager has responsibility for determining and implementing the design solution to meet all of the contractual requirements of the program for his or her subset of the product. Because the engineering definition is required before most of the other activities of the organization can begin, the subsystem manager must take the lead. He or she must reach out beyond the immediate organizational tasks and take a broad programmatic view. He or she must consider the subsystem as a product that must be manufactured, tested and fielded. He or she must view the assigned activities in terms of the business environment and try to anticipate downstream problems. He or she must participate with manufacturing, product assurance and the field in production and usage. He or she may, and often will, take the lead in problem resolution with branches such as manufacturing, because the subsystem manager has the knowledge of the end-item requirements and of the program to initiate action or allow compromise that can ensure achievement of the larger product goals.

4.3.4 Subsystem Manager's Role and Responsibilities

The subsystem manager's responsibility goes further than simply establishing the design definition. Since the design definition initiates much of the activity of the rest of the organization in increasing magnitude as the program matures, the subsystem manager must continue to lead throughout the design process. He or she is also responsible for certifying that the necessary analysis, test and verification work has been done to assure that the end-item will meet the program requirement, whether it is a flight test or readiness for production. Thus, the subsystem manager has responsibility for all development testing and specimens needed to establish design confidence prior to release of the design. Because he or she must certify the end item's readiness for use, this manager is also responsible for evaluation of test results from end-item configuration hardware and software built to released documentation by suppliers or in-house.

4.3.5 Subsystem Manager's Role in Subcontract Management

When the subsystem manager's end-items are designed and built by a subcontractor, his or her overall role is nearly unchanged. The subcontract management team approach is discussed in detail in Chapter 6, along with the roles of each Enterprise organization. The subsystem manager is still the "owner" of the design, responsible personally or through a delegate for the technical direction of the subcontractor activities needed to secure development and production of the items for which he or she is responsible.

However, there is a fundamental difference between managing in-house design and manufacture and subcontracted design and manufacture. In the in-house case, the Enterprise infrastructure provides planning, status, integrated master schedule commitments, etc. When a supplier is to do this work, that subcontractor must provide the equivalent activity and data. The Enterprise subsystem manager must be fully aware of this situation and assure that the activities are performed and the data is supplied. This is accomplished through the contract statement of work and through the personal attention and knowledge of the subsystem manager and the rest of the subcontract management team.

Each subsystem manager will designate an individual who has responsibility for each subcontract under his purview. This designee is delegated subsystem management responsibility and will serve as the chairman of the management team for that subcontract through production design freeze. The subcontract management team will include designated members from materiel as subcontract administrator and business manager, product assurance for quality requirements, program controls where warranted and the program office for program requirements and integration. Other representatives from test, manufacturing and other areas may be required depending on the subcontract.

This subcontract management team is, in effect, a miniature program management function to integrate the management and performance assessment of that subcontracted effort. The subsystem manager thus functions as a program manager for his subsystem.

4.4 Organizational Relationships

Recall that in this management model, the program manager acts like a general contractor "subcontracting" the work (other than program requirements and integration) to entities that are skilled in the necessary disciplines to best perform the work required. Those "subcontractors" are the functional organizations. Normally, there are several programs going on at the same time as depicted in Figure 4-2. Moreover, within a given program a functional organization will have several major jobs on which to perform.

Figure 4-2

We have said that the ideal organization is configured to delegate the responsibility for the planning and conduct of work. Thus, it can be performed by organizations with the logical combinations of skills and resources to be accountable for and accomplish the work with minimum conflict with other activities. The work can be divided in several ways. This requires clear delineation of authority and interfaces with respect to that work. Typically this means a division of the work into similar types of functions and skills or by facility proprietorship, or to provide required checks and balances. In the operations branches (manufacturing, materiel, product assurance, field support) for instance, the organization tends to be by the type of work to be done or the location where it is to be done. In Engineering, on the other hand, it is end-product oriented because the disciplines required generally relate to the functions that the product performs rather than the process needed to produce it. Finally, test and validation functions may be assigned to a separate organization to preserve the objectivity of this function.

Every organization that adds value to the product during its creation and lifetime should be represented in all phases of the planning as well as implementation of the project. Ownership must be established for every activity involved. For example, make vs. buy decisions must have buy-in from the operations organizations. To assure that this happens, a make vs. buy evaluation is usually required by general management of the enterprise and chaired by the senior manager of operations. Care must be taken to assure that those decisions are based on sound business grounds and not driven by anyone's bias or ambitions. The end result of the planning process should be signed contracts between the program manager and all "subcontractors," both internal and external. The terms of those contracts should identify all the resources needed to fulfill the contracts, including any new facilities or capabilities to be acquired.

4.5. Performance against Commitments

The contracts just discussed between functional and program managers are commitments. A commitment made is a commitment expected to be met.

While it is recognized that problems may arise in the course of the execution of a job that may prevent a commitment from being met, every manager is expected to have visibility into the performance of his work. Thus, if a commitment appears to be in jeopardy, it must be made visible to the program manager to whom that commitment was made with sufficient lead-time to allow corrective action to be taken. This means having a meaningful plan for the work to be done, with meaningful measures of accomplishment and due-dates agreed to by all affected organizations.

It is unacceptable for a commitment to be found incomplete on the day it is due -- whether it is a scheduled event, a task completion, or an action item. On the other hand, where situations beyond the control of the responsible individual will result in a commitment not being met, the timely reporting and visibility of that condition is of vital importance. This is a measure of a manager's planning and control of the activities for which he is responsible. The same relationship must be maintained between the program manager, as the company's agent, and the customer. While no one likes bad news, it is much easier to take when there is time to react and take contingent action.

4.6 Overarching Disciplines Support Program Integrity

To be successful, any program or project must implement certain integration functions to tie the project together and assess its progress. . We call these overarching disciplines. To assure the integrity of the project, these disciplines provide checks and balances among the organizations involved. Often the people assigned to their project do not appreciate the need for these disciplines; sometimes their managers don't, either. But to ignore them is almost to assure failure.

A program or project can be described as three kinds of activities generally occurring in parallel. They are: 1) Program Definition and Planning, 2) Program Implementation, and 3) Program Evaluation. The overarching disciplines fit into one or more of these three categories and are applied across the project. The expertise for applying them usually resides in functional specialty organizations as direct support to the program management team, as discussed below. A more detailed discussion of the methodology involved in these integrating disciplines is provided in Chapter 7, Integration Arts.

4.6.1 Systems Engineering

This activity is really the technical arm of the program manager, disseminating and allocating program requirements to the design activities, and then evaluating the ability of the design to meet those requirements.

This is the design activity that establishes interfaces and allocates functionality among the segment design teams of the product.

4.6.2 Product Safety, Quality, Reliability and Maintainability

This activity applies the expertise of the end application and ultimate user of the product and establishes the philosophy for minimizing the user's cost of ownership. It audits the product during its design to assure that these elements are included in the product as it evolves.

4.6.3 Integrated Test and Evaluation

This activity is the independent test conductor and evaluator during development. The integrated test program plan gathers all testing requirements from all project activities and provides the vehicle for the efficient management of test resources and product test samples as well as consistency of testing philosophy.

4.6.4 Plans and Status

This activity creates and maintains the program anatomy, the work breakdown structure and its dictionary; gathers the performing activities' subordinate plans; coordinates master scheduling; and measures and assesses program progress against these plans. Being independent of the performing activities, it provides an important check and balance. The disciplines and tools of this activity are discussed in Chapters 7 and 9.

4.6.5 Finance and Controls

Finance and controls is the keeper of the Enterprise accounting systems that gather and store the financial database of all enterprise activities, establish and maintain pricing rates, and provide the appropriate output data from the comparison of time-phased budgets and accomplishment to each level of management. The disciplines involved are discussed in Chapters 7 and 9.

4.7 Total Quality Management and Continuous Improvement

The recent Total Quality Management (TQM) initiatives in industry and government have been a way to capture the techniques and ideas that successful organizations and projects have used to achieve their success. My company was one of those success stories. Concurrent engineering and integrated product development teams had been used in some form on well-run programs for more than 35 years. Customer satisfaction was the fundamental tenet of our business. The principles of examining our practices and finding better ways of meeting program objectives had also been a characteristic of our programs, but on a block-change basis --not continuously.

Our corporate response to TQM and similar 6-Sigma initiatives was called CQI or Continuous Quality Improvement. The tenets of these initiatives, which are the hallmarks of success, were familiar to our organization, so I have never been comfortable with slogans, trappings, and posturing to create a new initiative for TQM. (See discussion of fads in Chapter 11). That is in no way to suggest that we didn't need to examine how we were doing our job, look for minimum-value-added activities and ways to eliminate them and do better. In fact, an Enterprise can always improve and must to be competitive. I believe that this self-assessment is also consistent with the values of any high-integrity enterprise.

4.7.1 Separating Substance from Form

The end-measures of effective TQM, CQI and similar activities are results--not rhetoric. In many instances, there has been too much emphasis on process. Process is not a substitute for results. It is the means to achieve the results. If results are to be achieved, then it follows that the objectives to be achieved must be specific and measurable, and the results measured. One of the values of dividing responsibilities organizationally is to provide a point of measurement as a hand-off occurs. In teams, this relationship also exists.

One of the key tenets of TQM is the use of integrated product teams (IPTs) and concurrent engineering. Another is customer satisfaction. The approach described for implementing IPTs in this chapter is an extension of the relationships described in the previous chapters. It centers on the integrity of the people and the organizations that make up an enterprise. This philosophy is the very essence of empowerment, commitment and accountability. It applies whether between individuals, between organizations, or in Integrated Product Teams. It requires mutual respect if teamwork by any name is to be real.

4.7.2 Integrated Product Teams Rediscovered

I led my first integrated product team in 1962. It was a project called "Lifeboat". The job was to develop a back-up attitude control system for the early Discoverer Satellite program and to fly it six months from go-ahead. In today's vernacular, the goal was to reduce cycle-time. We assembled a team co-located in a building with the program team. Our team had all the ingredients of today's IPTs. We were a small group, empowered to do the job. We had representatives of all the necessary disciplines to synthesize, analyze, design, buy and build the flight and ground checkout hardware; these representatives had the full support of their home organizations. Manufacturing technicians and planners who would build the follow-on units were part of the development team from day one. We had program representatives to establish the necessary interfaces with the primary system. We met the challenge and the schedule.

My second experience with IPTs began in 1973 with the Trident C4 Fleet Ballistic Missile Program. Here the driver was not cycle-time, but unit production cost. These teams were called producibility teams, not IPTs. But the methodology was the same: for each segment of the system, we gathered representatives of all the organizations that add value to the end-item-- whether flight equipment, ground equipment, or software. Their job was to make everything work together -- to define the design, how it would be produced and tested, and to commit to schedule and cost for their part of the job, based on that definition.

The teams then implemented the plan and executed the tasks to deliver all development units, testing under operational conditions, feeding back the early results to changes where needed, while simultaneously planning and tooling for production. In other words, they were using concurrent engineering. Pilot production was part of the development contract. This required proofing of the production process and maintaining the continuity of manufacture right into the initial production run, while demonstrating the actual cost, performance and reliability as built to the product disclosure data.

The project's management responsibility was to define a framework for what Peter Drucker has called "price-based costing".5 This framework provided for allocation and negotiation of cost targets for each segment of the product and a means for providing continuing visibility to the cost estimates as the design and producibility decisions were made. The methodology is discussed in Chapter 8.

Appendix 1 is the program management memorandum that implemented that process. Note that part of the methodology is the independent allocation of requirements, target costs, and master schedule as well as assessment of the results that gives feedback to the team on costs, first with estimated and then with actual costs of early hardware.

These programs occurred long before these government quality initiatives were invented. Note that nowhere do you see a requirement for monthly progress reports on all the implementations. Our efforts were everyday, real activity aimed at one ultimate goal -- success measured by customer satisfaction.

These teams were motivated by one simple thing: a clear understanding of what it took to succeed. In this particular case, a well defined multiple incentive contract provided that understanding. First, it defined the performance and interface constraints for the product the customer desired, and what the key attributes were worth to him. Second, it empowered the contractor to take the actions necessary to define and deliver that product guided by incentives on performance and cost. Actions to provide what the customer wanted would maximize the contractor's profit if successful.

This type of contract is discussed in more detail in Chapter 12. The point here is that the contractual arrangement between buyer and seller, if it is integrity-based, causes the competent seller to find smart and innovative approaches on his own initiative that provide customer satisfaction, if customer satisfaction has been defined beforehand and codified in the contract incentive value statements.

4.7.3 Customer Satisfaction Comes in Several Flavors

What other ways does customer satisfaction relate to making Product Development Teams work? One approach is to invite the ultimate customer to be part of the process as a participant, but not as a director. When the customer is a participant and sees how the team is dealing with its problems and resolving them, and is part of the daily dialogue, satisfaction with the end result is almost assured. We used to call this "kitchen privileges."

If all members of the team share the same end-objective -- for example, to develop an aircraft flight hardware segment for production -- there are still conflicting objectives about the part of the task that each member must accomplish to meet his or her commitments. In making those commitments, each team member is the customer of the others. This is an example where customer satisfaction becomes a factor internally --where initiative, ownership of the task, commitment and accountability for success are demonstrated.

One counterproductive tactic is for team members to make very conservative commitments for their respective tasks. A more fruitful approach is to ask each other, "What is your objective and how can I help you meet your objective while I can still meet mine? What kind of information do you need from me and when, to get your part of the job done?" We would use the same approach to resolve conflicts between the program and the ultimate customer on occasion.

4.8 Expectations of Individuals Assigned to IPTs

If you recall the seven elements of integrity in a project from Chapter 1, you have the definition of what kind of people we want to have representing each function in an integrated product team. The relationships described in this chapter for a program or project also hold for IPTs, because IPTs are nothing but small projects.

I have seen IPTs succeed and I have seen them fail badly. The ones that failed did so because the members were overly impressed with their "empowerment". They were arrogant and chose to work in isolation, virtually excluding the overarching disciplines and the expertise of their home organizations, believing them to be a waste of precious resources. The chickens came home to roost -- big time! A proper IPT environment is one that functions within the framework of the organization structure, not in spite of it.

4.8.1 Empowerment Within Overarching System Disciplines

The empowerment of individuals and teams is consistent with our concept of integral management. But empowerment does not mean that there are no rules or constraints on the process. Nor does it mean that there are no system disciplines or constraint to an overall plan. I have seen these assumptions made with tragic results.

In order for IPTs to accomplish their objectives, it is crucial that the integrating disciplines, such as program planning, master scheduling, cost control, and systems engineering be represented on each team. These members are responsible to the team for determining the interfaces with other teams, as well as coordinating with the integrating functions that allocate requirements to each segment (and therefore each team) of the total system. Every team member must participate in planning and cost management for his or her activities.

4.8.2 The Role of Integrated Product Team Members' Home Organizations and Managers

If IPTs consist of representatives from each discipline who are empowered to speak and act for their area of expertise, then what, in the context of the organizational and managerial relationships described earlier, is the role of the home organization and its manager?

Just as checks and balances result from careful division of responsibility among organizations, that same division of responsibility on product teams helps assure that things don't get overlooked within the team. The skills and knowledge that each team member brings fulfill the functional need within the team. The hand-over to another team member at each appropriate point in the development cycle provides an objective measure of accomplishment, just as it does in functional organizational hand-offs.

The typical home organization manager will have several leaders and groups of people working on different program teams. That means that 1.) the manager must assure that each leader has available to him or her the necessary talent, facilities and other resources needed to meet the technical schedule and cost commitments made by his or her team leaders; and 2) the manager must act as a coach to each of those teams for his or her area of expertise. This includes helping to resolve bureaucratic conflicts, or helping to get bridges built with other organizations where needed.

The home organizations provide the expertise to implement the job, led by their representative on the team. Taking advantage of the home organization's participation in many projects provides a cross-flow of experience, technology and methods from those other projects.

The proper relationship of the IPT member and his/her home organization is easily understood through an analogy. Think of the product development team as a group of subcontractors working on a housing tract for a general contractor. A subcontractor will be hired to do one element of the job, such as the plumbing. Unless there are no other jobs, the owner of the plumbing company will send a foreman to the job site. The foreman will have the day-to-day responsibility for work on the site. He/she must, therefore, be a person the plumbing contractor trusts.

However, the fact that the plumbing contractor trusts the foreman and respects his or her capabilities does not mean that the plumbing contractor is going to simply forget about the foreman. The job is a commitment of the plumbing subcontractor's company to the general contractor. For that reason, the foreman consults with and reports to his or her boss regularly, and the boss frequently visits the construction site. That way, the boss can make his or her own assessment of job progress, recommend changes, and make sure the foreman gets all the help he or she needs. That help consists of trucks and equipment, assuring that the right skills are available to the foreman on the days they are needed, creating and later ordering the bill of materials, and possibly pre-assembly of some of the hardware back at the shop. The plumbing contractor will probably have several jobs going on at once, which require varying levels of support as a function of time.

The functional organization manager in the IPT environment on a program is in the same position as the plumbing contractor performing as a subcontractor to the general contractor. The success or failure of his or her organization will be reflected in the success or failure of the IPT. Each functional manager owes it to his or her organization, and the program, to assign a capable, trusted employee to be the foreman or representative on the IPT. The people assigned to the job are a team subset, and the leadership of that subset team is delegated --by the functional manager --to his or her foreman or IPT representative. But the manager's obligation extends further: to approve the subcontract and check regularly on the progress of the team and the functional organization's contribution to it.

4.9 Resolving Conflicts in Objectives

Because of the nature of organizational roles, conflicts can be expected from time to time. An unresolved conflict may occasionally occur between the program office and the functional organizations in the negotiation of an agreement about the cost or the performance of a job. If escalation to the program manager and the responsible major organization manager cannot resolve this conflict, it will be resolved at the general management level. It is of paramount importance to foster a team relationship, and not an adversarial relationship, in resolving problems, since the end goal for all parties is presumably the same.

Note: in almost every case of a new activity, some functional manager will test the power of the program manager. If the program manager is behaving in accordance with the guidelines discussed here, it is important that he or she prevail in these conflicts. If general management is not prepared to support the program manager's position, they should privately consult with that individual to come to a win-win solution or they must replace him or her.

4.8 Summary

In this chapter, the stress has been on laying the foundation and relationships involved in high-integrity project management. Understanding these relationships provides us the background for examining the management and organization of Enterprises of various types. Later in the book we will look at the specific management disciplines required for project and enterprise success. Before doing so, however, in Chapter 5, we will examine the issues of Enterprise organization.


5. Managing in a Time of Great Change by Peter Drucker, Truman Calley Books/ Plume Printing, 1998

Copyright © 2001 L. David Montague. All rights reserved.