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 Abstract. Integrated Development is a creative new way to produce quality products in a predetermined 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 Development (IPD) is a management 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 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 improve the overall processes by integrating the functional and engineering disciplines from the beginning. The resulting teams then focus on developing quality products within cost and schedule constraints. Fundamentally, IPD is a different way of developing 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 systems 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 setting up the IPD procedures. This paper briefly reviews Integrated 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 carefully structuring the teams, getting the project manager more involved, and ensuring application of good systems engineering practices. A CLOSER LOOK AT IPD design and development has traditionally 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 development process (Hunt 1993). Communication between 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 language, 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 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 Integrated Teams (s), as discussed in MIL- STD-499B (1992). Under this concept a team or several teams of people are responsible for the product throughout all phases of the development into manufacturing and fielding of the system. A typical might be composed of technical engineering, production, testing, systems engineering, procurement, and specialty engineering (reliability, maintainability, safety, human factors, integrated logistics, etc.), as well as including customer and management representatives. The intent of this involvement 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, decisionmaking is concurrent among the teams, and Office Workers (Engineers) Status Reports Policy Fiscal Administration Plans Designs Results Upper Management Progress Use of Resources Professional Link The Big Picture (Job, Money, Contract) Facts Schedules Priorities Tasks People Skills Schedules Reports Figure 1. Traditional Interrelationships. Sponsor (Customer) Functional s Management Disciplines Integrated Development Better, Cheaper, Faster s Figure 2. Integrated Development Overview. 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, s 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, involvement, and support of the 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 responsibility, 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, 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 visibility into the process. In the case of government contracts 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

Management of Integrated Activities Quality Assurance Integrated Development Computer- Aided Tools Multifunction Teams Figure 3. Integration of IPD Elements. time, how can customer representatives on teams ensure that their inputs are evaluated fairly rather than given undue consideration because of the perception 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 s, then it becomes difficult to determine which of multiple s is overspending on its particular piece of the work package. Numerous other issues arise with the process: how to ensure training for members of the s; how to overcome technical language barriers among members who come from different disciplines; how to ensure adequacy of tools to support the s; how to manage the growth and establish proper representation 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 engineering methodology is to be ensured through the structure and workings of the s. BUILDING SUCCESSFUL INTEGRATED PRODUCT TEAMS In basic terms, an Integrated 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 channels to management, and commitment to the project rather than commitment to the functional office. activities in the IPD process are shown in Figure 4. Tasking is determined by decomposing the system into nodes and assigning responsibility for each node to a separate. 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 engineering 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 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 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 technical 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 Define Requirements Resolve Issues Integrate the s Organize s Apply Tools and Techniques Ensure Identify Team Goals Assign Requirements to s Deliver Quality Figure 4. Integrated Development Process.

Specialty Quality Assurance Disciplines Integrated Team Manufacturing Test and Evaluation Figure 5. Integrated Team. of action or solutions that are backed by a consensus. Figure 5 shows possible membership. ENSURING THE SYSTEMS ENGINEERING PROCESS Large system developments sparked the emergence of engineering discipline specialists. These specialists were expert in their engineering disciplines, 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 multifunctional approach to ensure that the system met overall project goals and user s needs. engineering techniques were developed and applied consistently in government procurements as well as large-scale commercial projects. The question becomes, how can the systems engineering functions developed and proved over the past several decades be applied effectively in the IPD environment? As previously noted, s bring in people from various disciplines. Thomas (1995) describes s as being organized in tiers. How the systems engineering function is applied within or across s can vary with the organization involved. Let us look at pros and cons of some of these approaches. engineering in the first tier. Figure 5 showed the makeup of a typical. 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 s; some may have to double up, which disperses their focus and responsibilities. In any case, the systems engineering discipline manager is responsible for applying the systems engineering methodology evenly and effectively across the full range of lower-tier s. engineering in the second tier. The first tier of s contains all the s to which component parts of the system have been assigned. Requirements have been flowed down for each team s part of the WBS. These s may be overlaid by a second tier System Integration, which brings in the systems engineering discipline in addition to quality management, external interfaces management, integration and testing, support engineering, and production transition. At this level, systems engineering will develop and employ system simulations to perform systems engineering studies, trades, and analyses. This will track the products of the lower-tier s to ensure that their subsystem requirements have been met. It will also be responsible for any requirements that have been allocated to it in the system decomposition. engineering in the upper tier. Some organizations apply an upper-tier to the process. This is usually referred to as a Management or a Program Management Team. A typical team charter would be to manage the project using principles in accordance with the contract and to deliver technically 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 leaders, and a customer representative. In this case the systems engineering flows down from a management perspective to the lower tiers of s and is implemented in accordance with the systems engineering manager s direction as affected by the overall management perspective of the project. Such a structure might be chosen when it is perceived that the lowertier s are not well versed in systems engineering and close management attention is regarded as necessary.

The conclusion is that systems engineering must be applied at all levels of the IPD process. Figure 6 illustrates the multitier concept and shows an approach that maximizes systems engineering in the project structuring. The ability of the organization 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, systems engineers do not spring up overnight. As a minimum, the training for s should give attention to systems engineering methodology. THE PROJECT MANAGER MUST BUY IN Integrated Development takes considerable management attention. Canned solutions cannot generate the level of human commitment that is needed if the effort is to succeed. Teamwork is important 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 participate. 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 members working together and productive. The project manager must support the s activities, secure resources, and open communication lines between each team and the rest of the organization. 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 s overcome inefficient processes embedded in the culture of the organization. The project manager should encourage face-toface interaction of the team members in lieu of time-consuming and burdensome paperwork; should constantly be looking for ways to remove inefficiencies; and should help s streamline their processes. Customer Corporate Management Discipline s Business and Contracts Integration Leaders Management Disciplines System Integration Figure 6. Structure Under IPD.

He must see that open communication is maintained between the s and management during the process 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 longlead 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 members past company cultural hang-ups. He must dispel mistrust among and within the s. 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 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 Teams are structured 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 decomposed so that each has clear responsibilities (requirements to meet) and goals. These s 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 unmanageable. engineering can be applied in different ways depending on how the s are structured. 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 uniformly across all s. 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 s. Thus, to retain close ties with the customer, the project manager 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 s with upper management Integrated 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. Success stories abound. But it has not come easy to any organization. Each has found it necessary to make fundamental changes and to convince upper management 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 Development, Oliver Wight Publications Inc., Essex Junction, Vermont, 1993, pp. 8 14, 41 71. Roe, C. L., The Role of the in, Proceedings Fifth Annual NCOSE Symposium, 1995, pp. 439 445. Thomas, L. D., in an Integrated Team Organization, Proceedings Fifth Annual NCOSE Symposium, 1995. pp. 407 410. MIL-STD-499B, Management, U.S. Air Force Command, Draft, 1992. BIOGRAPHY Charles L. Roe is a project manager in the Surface Combat Program Office at The Johns Hopkins University Applied Physics Laboratory. He manages projects related to ship selfdefense 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.