PROJECT MANAGEMENT AND SYSTEMS ENGINEERING IN AN IPD ENVIRONMENT

PROJECT MANAGEMENT AND SYSTEMS

ENGINEERING IN AN IPD ENVIRONMENT

Charles L. Roe

The Johns Hopkins University Applied Physics Laboratory

Johns Hopkins Road, Laurel, Maryland 20723-6099

crea-tive new way to produce quality products in a prede-termined time within a set cost. The focus is on multifunctional teams working together and total integration of all products and processes (people, tools, and techniques). Within the team structure several potential pitfalls exist that can threaten the process. This paper suggests that two of the critical pitfalls involve (1) the project manager effectively executing new responsibilities that fall to him or her in the process and (2) the organization overcoming the difficulties of applying the systems engineering methodology to the products being developed by these concurrent teams.

INTRODUCTION

Integrated Product Development (IPD) is a man-agement technique that simultaneously integrates all essential acquisition activities through the use of multidisciplinary teams to optimize the design, manufacturing, and sustainment processes to meet cost, schedule, and performance objectives. Many American companies are embracing IPD and have documented their successes. The Defense Science Board and Defense Manufacturing Council strongly support IPD. They have noted that, in addition to the better teamwork between industry and government, an improved management focus and attention to the systems engineering process should ensue. As a result, Secretary of Defense William J. Perry has directed that the Department of Defense (DoD) adopt this new philosophy for the procurement of products and services.

Although the Integrated Product Development focus is relatively new, the underlying concepts are not. In the past, concurrent engineering, rapid product development, process value engineering, or even systems engineering were used to describe parts of IPD. Like the concepts before it, IPD seeks to im-prove the overall processes by integrating the func-tional and engineering disciplines from the beginning. The resulting teams then focus on devel-oping quality products within cost and schedule constraints.

Fundamentally, IPD is a different way of devel-oping complex systems. The customer’s, or sponsor’s, insight into the way the development is proceeding

has changed. The way the program (or project) is managed and responsibilities assigned to the project manager have changed. And the way that good sys-tems engineering practices are ensured has changed. That is not to say that these things cannot be done effectively in IPD. They may even be done better than in the past if the organization is careful in set-ting up the IPD procedures.

This paper briefly reviews Integrated Product Development and notes some of the potential pitfalls and weaknesses of the process. This is followed by a discussion of how these pitfalls and weaknesses can be overcome and the process strengthened by care-fully structuring the teams, getting the project man-ager more involved, and ensuring application of good systems engineering practices.

A CLOSER LOOK AT IPD

Product design and development has tradition-ally been characterized by different functional units or disciplines designing their part of the system and passing it on to the next functional area in the devel-opment process (Hunt 1993). Communication be-tween these work units or specialty groups was often very formal. Interdepartmental boundaries limited effective communication between the groups. Often different disciplines did not speak the same lan-guage, and little attempt was made to communicate or to keep the next group informed about what was coming. The next functional group saw the product design only after the preceding group was finished. So each functional group in turn focused on its effort with little regard to the whole.

In these traditional efforts, a systems engineering manager or lead engineer was usually assigned to make sure it all came together. He acted across organizational and functional lines to make sure that the product met the customer’s needs. Similarly, the project manager stayed in touch with the technical groups, principally through his systems engineering manager, to ensure that cost and schedule were maintained, and served as liaison with the customer (Roe 1995). These traditional relationships are shown in Figure 1.

Integrated Product Development may be thought of as a systems approach to integrated engineering of products (Figure 2). At the same time, related

proc-esses, such as business process, design process, manufacture process, and support systems, are also being integrated into the product. This approach allows the organization to consider all elements of the product life cycle from the concept definition all the way through maintainability in the field. This ensures that customer requirements, quality goals, cost restraints, and schedule drivers are all met.

IPD uses multidisciplinary teams called Inte-grated Product Teams (IPTs), as discussed in MIL-STD-499B (1992). Under this concept a team or several teams of people are responsible for the prod-uct throughout all phases of the development into manufacturing and fielding of the system. A typical IPT might be composed of technical engineering, production, testing, systems engineering, procure-ment, and specialty engineering (reliability, main-tainability, safety, human factors, integrated logistics, etc.), as well as including customer and management representatives. The intent of this in-volvement by all the disciplines is that the groups watch and ensure their own contribution at each stage in the development. Thus, the team, or teams, are working toward product-driven goals, decision-making is concurrent among the teams, and

integration with other teams’ products is planned and followed.

POTENTIAL PITFALLS IN THE IPD PROCESS IPD has a unique emphasis on people, process, and technology (Figure 3). The benefits are not achieved easily. First, top management must be committed. In many instances management will attend sessions where the benefits of IPD are touted. It is easy for them to go along with this (especially in light of the DoD mandate) and give verbal support while really failing to comprehend their critical responsibility to the process. To function effectively, IPTs must be empowered to make programmatic and technical decisions within specific product domains. Top management commitment to learn, understand, and lead the IPD effort with clear direction, in-volvement, and support of the IPT goals and charters is vital to the success of the process. Organizational policies that defeat the IPD process must be changed. Very often this involves changing the way management thinks about short-term profits, the structure of departments, assignment of responsibil-ity, employee evaluation, and the importance of teamwork.

Another difference in the IPD approach is that the customer is often invited to become a part of an IPT, thus becoming a part of the development team. The customer is expected to actively work with others on the team to reach consensus on design and development issues. This gives the customer visibil-ity into the process. In the case of government con-tracts it also complicates the process of award fee evaluation. Is the customer representative supposed to go before the board and snitch on teammates? To make the process work, the customer witnesses cannot be an integral part of the team. At the same

Upper Management Project Manager Systems Engineering Manager Project Office Sponsor (Customer) Technical Workers (Engineers) Functional Managers Status Reports Policy Progress Use of Resources Fiscal Administration

The Big Picture (Job, Money, Contract) Technical Facts Schedules Priorities Plans Designs Results Tasks People Skills Schedules Reports Professional Link 96-5463

Figure 1. Traditional Project Interrelationships. 96-5463 Project Management Systems Engineering Technical Disciplines Better, Cheaper, Faster Products Integrated Product Development

Figure 2. Integrated Product Development Overview.

time, how can customer representatives on teams ensure that their inputs are evaluated fairly rather than given undue consideration because of the per-ception that they speak for the customer?

The makeup of teams responsible for different components of a system can often complicate the work breakdown structure (WBS). Cost accounting is usually tracked by work packages. If work packages are not made up carefully so that they are assigned to particular IPTs, then it becomes difficult to deter-mine which of multiple IPTs is overspending on its particular piece of the work package.

Numerous other issues arise with the IPT proc-ess: how to ensure training for members of the IPTs; how to overcome technical language barriers among members who come from different disciplines; how to ensure adequacy of tools to support the IPTs; how to manage the growth and establish proper represen-tation on the teams, to name a few. To settle many of these concerns, initiative must be taken to define an expanded role for the project manager in the IPD process and to determine how the systems engineer-ing methodology is to be ensured through the struc-ture and workings of the IPTs.

BUILDING SUCCESSFUL INTEGRATED PRODUCT TEAMS

In basic terms, an Integrated Product Team is a cross-functional, or multidisciplinary, group of people who are tasked, empowered, and accountable for delivering a product internally to their organization or externally to a customer. The internal delivery occurs when a team is one of several teams working

on various components of a system. The IPD team approach requires a product teaming organizational structure characterized by open communication among team members, access to evolving design information, clear and concise communication chan-nels to management, and commitment to the project rather than commitment to the functional office. IPT activities in the IPD process are shown in Figure 4.

Tasking is determined by decomposing the sys-tem into “nodes” and assigning responsibility for each node to a separate IPT. The product should be decomposed until each node can be handled by a team of eight to twelve people. Thus, a complex development could involve a dozen or more such teams. If teams can be kept within a single engineer-ing discipline, so much the better in terms of good communications. Having the team responsible for a single work package or WBS item also facilitates project management.

Empowerment is important. The representatives of the disciplines assigned to the team must be able to speak for their area. They should communicate with their functional managers to ensure that their advice is sound, but their decisions and advice should not be overturned or second-guessed. Team members must be trained and educated so that they can properly contribute. A team leader, as well as roles and responsibilities for all team members, must be assigned. Each IPT must prepare a clean, concise team charter. One of their first jobs is to identify goals and milestones. Along with this they must formulate a strategy with regard to policies and procedures, make plans, define budgets, and set up clear metrics to measure progress.

The IPT is accountable for its part of the product. It is important to get the right membership, and it is important that members set up good communications and provide timely analysis and resolution of techni-cal issues. Each member brings a unique expertise to the team, and each member’s views must be equally weighed. There may be reasoned disagreement on approaches or solutions, but it must result in a plan 96-5463 Systems Engineering Management of Integrated Activities Multifunction Teams Integrated Product Development Quality Assurance Computer-Aided Tools

Figure 3. Integration of IPD Elements.

96-5463 Define Requirements Organize IPTs Identify Team Goals Resolve Technical Issues Apply Tools and Techniques Assign Requirements to IPTs Integrate the Products Ensure Systems Engineering Deliver Quality Product

Figure 4. Integrated Product Development Process.

of action or solutions that are backed by a consensus. Figure 5 shows possible IPT membership.

ENSURING THE SYSTEMS ENGINEERING PROCESS

Large system developments sparked the emer-gence of engineering discipline specialists. These specialists were expert in their engineering disci-plines, but tended to concentrate on the part of the system that they were responsible for, whether or not it worked well within the overall system design. This gave rise to the systems engineer, who had to be concerned with the overall system, taking a multi-functional approach to ensure that the system met overall project goals and user’s needs. Systems engi-neering techniques were developed and applied consistently in government procurements as well as large-scale commercial projects.

The question becomes, how can the systems en-gineering functions developed and proved over the past several decades be applied effectively in the IPD environment? As previously noted, IPTs bring in people from various disciplines. Thomas (1995) describes IPTs as being organized in tiers. How the systems engineering function is applied within or across IPTs can vary with the organization involved. Let us look at pros and cons of some of these approaches.

Systems engineering in the first tier. Figure 5 showed the makeup of a typical IPT. A systems engineering representative can be on the team. From this vantage point he can ensure systems engineering of the component part of the system. However, he cannot work in a vacuum. He must know how design and development of other components are planned and proceeding if his team’s component is to work synergistically with the whole. Moreover, a different systems engineer may not be available to sit on each of the IPTs; some may have to double up, which disperses their focus and responsibilities. In any case, the systems engineering discipline manager is re-sponsible for applying the systems engineering meth-odology evenly and effectively across the full range of lower-tier IPTs.

Systems engineering in the second tier. The first tier of IPTs contains all the IPTs to which component parts of the system have been assigned. Require-ments have been flowed down for each team’s part of the WBS. These IPTs may be overlaid by a second tier System Integration IPT, which brings in the systems engineering discipline in addition to quality management, external interfaces management, inte-gration and testing, support engineering, and produc-tion transiproduc-tion. At this level, systems engineering will develop and employ system simulations to perform systems engineering studies, trades, and analyses. This IPT will track the products of the lower-tier IPTs to ensure that their subsystem requirements have been met. It will also be responsible for any require-ments that have been allocated to it in the system decomposition.

Systems engineering in the upper tier. Some organizations apply an upper-tier IPT to the process. This is usually referred to as a Management IPT or a Program Management Team. A typical team charter would be “to manage the project using IPT principles in accordance with the contract and to deliver tech-nically compliant quality products on schedule and within costs, thereby achieving customer satisfaction as measured by high performance ratings.” This team is headed by the project manager but would also include the managers of the various disciplines (including systems engineering), representatives from business and contracts, second-tier IPT leaders, and a customer representative. In this case the sys-tems engineering flows down from a management perspective to the lower tiers of IPTs and is imple-mented in accordance with the systems engineering manager’s direction as affected by the overall man-agement perspective of the project. Such a structure might be chosen when it is perceived that the lower-tier IPTs are not well versed in systems engineering and close management attention is regarded as necessary. 96-5463 Technical Disciplines Specialty Engineering Quality Assurance Systems Engineering Test and Evaluation Manufacturing Integrated Product Team

The conclusion is that systems engineering must be applied at all levels of the IPD process. Figure 6 illustrates the multitier IPT concept and shows an approach that maximizes systems engineering in the project IPT structuring. The ability of the organiza-tion to adapt its systems engineering processes to IPD depends upon the emphasis and attention that it has placed on systems engineering in the past. As an organization moves into the IPD environment, sys-tems engineers do not spring up overnight. As a minimum, the training for IPTs should give attention to systems engineering methodology.

THE PROJECT MANAGER MUST BUY IN Integrated Product Development takes consider-able management attention. Canned solutions cannot generate the level of human commitment that is needed if the effort is to succeed. Teamwork is im-portant for successful IPD implementation. Both management and the organizational structure must promote the required teaming activities. This must be reflected in participative management and teamwork. Management must be a participant in the teams. In traditional developments the project manager was the principal interface to the customer. Now the

customer is invited onto the teams. To stay close to the customer, the project manager also must partici-pate. He still has integrative responsibility for the project. The project manager is challenged on all fronts if he is to successfully function within the constraints of IPD principles. He must embrace the process and become a participant. To survive the process, and to buy in to the process, managers must become students again, learning and dealing with emerging technology and keeping their team mem-bers working together and productive.

The project manager must support the IPTs’ ac-tivities, secure resources, and open communication lines between each team and the rest of the organi-zation. The project manager has a personal stake in the success of the IPD effort. He must control the resources needed to launch and sustain the effort and must have the authority to empower the teams and remove obstacles to their success. He can help the IPTs overcome inefficient processes embedded in the culture of the organization.

The project manager should encourage face-to-face interaction of the IPT team members in lieu of time-consuming and burdensome paperwork; should constantly be looking for ways to remove inefficien-cies; and should help IPTs streamline their processes.

96-5463 Corporate Management Customer Project Manager Discipline Managers Business and Contracts Systems Integration Leaders Systems Engineering Manager Engineering

Disciplines EngineeringSystems

Management IPT

System Integration IPT

Component IPT Component IPT Component IPT Component IPT

He must see that open communication is maintained between the IPTs and management during the proc-ess to prevent management objections later due to miscommunication or lack of communication.

The project manager must see that the project risks are fully understood and addressed. He must guard the cost accounting, implement change control to manage requirements changes, and identify long-lead events such as safety compliance and other certifications to be met to ensure the schedule. He must ensure that the teams are executing the project in accordance with the statement of work. And most of all, he must be willing and able to be part of the team(s). He is the one most able to get team mem-bers past company cultural hang-ups. He must dispel mistrust among and within the IPTs. He must take the lead in problem resolution. The project manager remains the focal point for the project within the organization and retains responsibility for delivering to the customer the product that the customer expects.

CONCLUSIONS

Integrated Product Development is replacing the conventional design and development processes, in which individuals in specialized functional areas worked in relative isolation and passed the product design on to the next area. In IPD the focus is on multifunction teams, quality-based design, process improvement, and total integration of all processes (people, tools, and techniques) so as to adapt to a customer who demands a better, faster, and cheaper product.

Even with workers who are highly skilled and multidisciplined, IPD demands a high degree of teamwork. The Integrated Product Teams are struc-tured so that representatives of all technical and specialty disciplines involved work together to solve technical problems throughout the various phases of the development process. The system must be de-composed so that each IPT has clear responsibilities (requirements to meet) and goals. These IPTs must be empowered with the responsibility for their part of the product, free of management interference and second-guessing.

Ensuring the systems engineering of the product is more complex under IPD, but by no means un-manageable. Systems engineering can be applied in different ways depending on how the IPTs are struc-tured. If the structure contains many tiers, then the best approach is to ensure the process at all levels. In any case, systems engineering must be applied uni-formly across all IPTs.

The project manager retains responsibility for the product in the customer’s eyes. His role in the process becomes more complex. The customer is

often invited to participate in the IPTs. Thus, to retain close ties with the customer, the project man-ager must similarly get involved. He must brush up his technical skills and become a participant. Then he can further facilitate the IPD process by running interference for the IPTs with upper management

Integrated Product Development is becoming a fact of life for companies doing business with the government, and for those who have found that it provides an edge in the modern global market. Suc-cess stories abound. But it has not come easy to any organization. Each has found it necessary to make fundamental changes and to convince upper man-agement that the rewards of undergoing the cultural shock of reengineering the organization will more than justify the pain. Lessons have been learned and are still being learned and applied to readjust the process. New management techniques, coupled with aggressive application of systems engineering, will prove to be key elements of IPD.

REFERENCES

Hunt, V. D., Reengineering, Leveraging the Power of

Integrated Product Development, Oliver Wight

Publications Inc., Essex Junction, Vermont, 1993, pp. 8–14, 41–71.

Roe, C. L., “The Role of the Project Manager in Systems Engineering,” Proceedings Fifth Annual

NCOSE Symposium, 1995, pp. 439–445.

Thomas, L. D., “Systems Engineering in an Inte-grated Product Team Organization,”

Proceed-ings Fifth Annual NCOSE Symposium, 1995. pp.

407–410.

MIL-STD-499B, Engineering Management, U.S. Air Force Systems Command, Draft, 1992.

BIOGRAPHY

Charles L. Roe is a project manager in the Surface Combat Systems Program Office at The Johns Hopkins University Applied Physics Laboratory. He manages projects related to ship self-defense for U.S. and NATO navies. These tasks emphasize combat system analyses, upgrades, and integration of new developments with existing fleet equipment. He also guides laboratory efforts in the development of the Evolved Seasparrow Missile. Mr. Roe has a B.S. in computer science from the University of Maryland and an M.S. in technical management from The Johns Hopkins University. He has been a member of INCOSE since 1994 and is active in the Chesapeake Chapter.