Successfully executing a large program full of subcontractors, associate contractors, teaming arrangements, the work in-house, satisfying both internal and external customers and stakeholders from around the globe, and a $5,000,000 a month running rate, can be daunting when taken as a whole. As with most complex problems, the solutions are typically found by breaking down all of the complex parts into its constituents and solving all of the pieces until the whole is accomplished. When the parts are broken down into well-defined objectives; milestones to meet the objectives; events to meet the milestones; accomplishments to meet the events; criteria for successful accomplishments; tasks to meet the criteria; interfaces between the tasks; processes for execution; and responsible and accountable leadership is assigned for every task set, the whole becomes manageable. These task sets referred to here are products and services that are distinct and well defined. The Work Breakdown Structure (WBS) is comprehended by the summation of all of these products, services and integration between them.
Over the past 10 years in the Aerospace/Defense industry, we have discovered that a key to successful program execution is through solving the complex problems with each product or service through integrated teams of people from applicable product disciplines. We have found that members of groups are typically better than individuals at solving problems because the collective group understand more of the parts to a problem, generate more options, relinquish dead-end ideas sooner, improve on each other’s ideas and, when empowered to execute, share the responsibility of the results. We call these groups Integrated Product Teams (IPTs) because they are formed on the basis of a grouping of a set of common tasks and objectives that are a product or service that directly map to the work requirements in the WBS and team membership is cross-functional (includes engineering, operations, producability, quality assurance, reliability, or whatever discipline is required to develop or deliver a compliant product or service right the first time).
IPTs have become a cornerstone to success in our programs today. One of the benefits that IPTs provide are they pierce barriers such as culture, functional issues, political agendas, personal problems and physical distance between stakeholders. Since they are formed on the basis of a set of common objectives, they represent what is common between all members and stakeholders with an objective to accomplish product results within the performance, cost and schedule requirements allocated and as effectively as possible. They are measured and rewarded by this performance and therefore derive no benefits from politics and not meeting goals because “it was someone else’s fault.” They are final product and service results driven. In my past 21 years in the Defense/Aerospace business, I have seen no other organizational form more enjoy this kind of focus and success.
How to Form IPTs
Getting the right leader with the right people into the niche they were born to be in forms great teams. It creates passion to perform and subsequent greater contribution levels. The process of how IPTs are formed is as important as the make-up of the teams themselves. It all starts with a set of common program objectives, goals, requirements and their allocation. It is imperative that the customer and contractor collaborate to identify, document, internalize and communicate the overall program objectives, goals, strategies and key performance parameters very early in the program and sustain this communication throughout the program life cycle. These program objectives, the contract, the SOW, specifications and a subsequent WBS are the source data by which Product Teams are identified. A product or service “needing a team to make it happen” is a logical grouping of elements from the lowest levels of the WBS. The first critical step in defining teams is to develop a detailed WBS that comprehends all work that must be performed. It comprises of a set of tasks, products and/or services that become a clearly identifiable, unambiguous and manageable item or project. Examples of products within a missile may be its guidance electronics unit, control section, payload, and airframe. Examples of product services that deliver an integrated missile system are all-up-round integration, aircraft integration, test and evaluation, and logistics support. The summation of all of these “products or projects” is the program.
Organizational linkage definition between products is critical so that all tasks are understood. Once these products are well defined, team leaders are carefully chosen. The leaders should be chosen for their ability to successfully manage a project (i.e., cost, schedule, and performance) and not solely because they may have the most technical knowledge of the product. Typical characteristics of the IPT leader are they are confident, trustworthy, and achievement and results oriented, they have organizational awareness and self-control, they can influence, communicate effectively, manage conflict and adapt to changes, and, above all, they don’t just manage, they lead and are force multipliers of their efforts and successes through others. An IPT leader, as the Defense/Aerospace industry has defined and used them over the past 15 years, is what many today define to be a project leader today. These leaders have the ability to remove bureaucratic and other noise barriers to facilitate the IPT members in solving problems. These folks are not just managers, they lead people. They realize that having and successfully implementing all of the best processes in the world do not make a program successful. Although these processes are critical guidelines and tools to success, they are not a panacea. Leaders realize that, in the long run, it is more important to do the right thing than just do things right.
Once the IPT leaders are established, the program manager and these project leaders develop a set of documents that describe each product team’s charter, scope, and interface to all other product teams and stakeholder organizations. This process takes time, but it leaves no room for ambiguity of who is responsible for what and how teams will interact with each other. An example of the contents provided for each team contained within the document includes the following:
Team Name; Business Unit Goals (including a Mission Statement and Vision Statement); Team Charter; Task Definition; Team Products; Boundary Definition; Performance Definition; Stakeholders (including Team Members from Customers, Suppliers, Raytheon); Resources (including Budget and Schedule); Authority; and an Interface Control Document (ICD) (as shown in Exhibit 1).
Concurrence on performance success criteria, schedules, budgets, and allocations of management reserve is then established. Exhibit 2 shows how the WBS elements, integrated master schedule (IMS) tasks, and IPTs are linked together. This forms the beginning of an integrated master plan (IMP). When the IMP is completed and all WBS elements are accounted for, resource loading and staffing plans are developed. IPTs are staffed with people from the functional disciplines required (i.e., Electrical, Mechanical, Software and Systems Engineers, Procurement, Operations, QA, etc.), by each team leader with the assistance of the program manager and functional leadership, consistent with budget, schedule and execution requirements for each team. An important word here is “assistance.” Although it may be a functional organization’s responsibility to hire, train, place, and replace people in an organization, it is the Program Manager’s and each IPT leader’s job to assure the right people are on the right teams to help assure success. People are not as interchangeable as some would like to believe. Unique talents can be exponentially more valuable in one role over another. It is the program and project leaders who are ultimately responsible for program cost, schedule, and technical performance. They should be a voting body on staffing decisions. Each product team is now a fully staffed, authorized, accountable, and integrated (both by product and cross-functionally to achieve concurrent engineering advantages). True IPTs are formed.
Program Organization that Best Supports IPTS
This author’s experience of the organizational structure that best fits IPT deployment is a strong matrix. Exhibit 3 represents the evolution of organizational structures that we have gone through with IPTs over the past 10 to 15 years. We stopped changing when we got it right. In large companies with complex and diverse programs that involve almost every engineering discipline there is, as well as operations, large procurements, finance, contracts, etc., some form of functional structure is usually desired due to standards, process and organizational stability and the hopes of maximizing functional synergies over programs for lower execution costs. However, these synergies and cost savings are not realized unless the programs are executed successfully and customers are satisfied. Purely functional organizations can have a tendency to guide an employee’s reason for working to be to impress the functional bosses and rise to the top of their function. Customer needs become a lower priority. Purely product-based organizations are more customer product focused. However, downsides are there is typically less engineering and manufacturing standards, less training and functional skill retention, no natural placement process after a project is completed, and opportunities for achieving technical excellence in a field is lessened. For large diverse companies, the answer lies between these two. A matrix organization employ people from the functional organizations within the company, some of which report full time to the program, some report part time. A strong matrix organization gives authority and accountability to project and/or product-oriented team leaders whereas a weak matrix provides the authority and “usually” accountability to the functional organization. Another way to say this is that a weak matrix organization team typically is not as “product” focused. It is more focused in the functional aspects of a product such that a “thread” management team often needs to exist to assure that the summation of all the functional parts actually equal the end product(s) requirements and user needs. In a strong matrix, the summation of parts or products and services more directly equal the end product(s) requirements and user needs. Thread management is less work and is significantly easier to manage. Exhibit 4 illustrates an example of a strong matrix program organization. The leadership team (those who report to the program manager) is made up of both functional and IPT leaders. To most efficiently complete a project, fully projectized organizations have proven to work very well and efficiently. However, the skills, talents, tools and steady state communication with your functional organization is also critical for project success and the future (post program completion) of the functional staff. In a large company, you need both project focus and functional links. The best of all worlds is when you have functional leaders who can also serve as IPT leaders.
A key point of Exhibit 4 is that it is the IPT leads (vertical axis, right side) who have the authority to do whatever it takes to successfully complete their product or project within their cost, schedule and performance requirements. It is important to note that success criteria must include the successful integration with the other products and services so that the end product(s) meet all requirements and customer’s needs. The IPT leaders are held accountable for each of their products and/or services and their integration to assure that this happens. Other noteworthy points in the chart are that (a) each team is made-up of the required functional skills/people (the dots), (b) each IPT leader is from some functional group (starbursts), and (c) the IPTs also include both customer and key supplier members. A subtle, but absolutely key, note is that the customer and supplier members are also accountable to team performance. When IPT customer and supplier member counterparts are also responsible and rewarded for team solutions to problems rather than just providing early warning shots of the team’s problems, you have a program success story in the making.
How to Manage IPTs
Once IPTs are formed, how they communicate with each other and other teams become crucial. All IPT members (regardless of location) should meet, at least, once a month (face to face) during a product development cycle. This is necessary in the beginning to keep steering the rudder on their product development progress to the cost, schedule and performance baselines.
All program reviews are lead by the Program Manager and will always involve the IPT leaders. Program cost and schedule reviews are typically held monthly and many times biweekly in the beginning, until there is proven favorable and stable execution performance on the program. Since each IPT is the summation of several costs accounts, these reviews start with IPT performance measurements, indices and trend analysis and then “the onion is peeled back” on “problem” cost accounts, within the respective IPT. The point is that the accountability chain starts with the IPT and then with individual cost accounts within the IPT. Internal and external program reviews, as well as, cost and schedule reviews are focused on each IPT’s performance. Risk Management Board (RMB) reviews are typically held on a monthly basis. An assigned risk owner, who is an IPT leader or IPT member, typically presents each risk’s status to the RMB. All of these are best conducted face to face. Communication between IPTs, IPTs and the RMB, IPTs and Program Management and IPTs and Functional Leadership is shown in Exhibit 5. As this exhibit implies, communication is achieved in a multipath yet structured closed loop fashion. Exhibit 6 illustrates the concept of the program risk escalation path. IPTs are responsible for managing all program risks unless the expected value (Probability of occurrence x its Impact) is so small that it should be handled at the cost account level or it’s so large that it requires almost full time RMB or more senior management attention.
The last part to be discussed on managing the IPT process involves a reward system that endorses team behavior for all team members, customer, suppliers and the contractor alike. People respond to the reward system. From an internal organizational standpoint, it is very important that all program, IPT and functional leadership are involved in an employee’s reward determination and the employee clearly understands the reward assessment process. It is not necessary that the customer, supplier and contractor IPT members be rewarded in the same quantifiable way for meeting a team’s success criteria. Although, in a perfect world, this would be ideal, in government contracts this is typically very difficult to do. What is important is that the customer, supplier and contractor IPT members be rewarded for achieving the same product or project objectives and be publicly recognized between all IPTs and program stakeholders. Contractor and customer leadership must unambiguously and enthusiastically sponsor this to make it work.
A Success Story
The processes described herein are some of the key elements of how the Joint (Navy and Air Force) Stand-Off Weapon (JSOW) program has been managed. JSOW (shown in Exhibit 7 and built by Raytheon Missile Systems) is an air-to-ground joint USN and USAF stand-off weapon that is currently in full rate production. It is a 1,065-pound, winged glide weapon that contains a low cost Guidance and Electronic Unit (GEU) with a tightly coupled inertial and Global Positioning Satellite (GPS) navigation system to either guide the weapon to a directed point in space where it dispenses a payload of 145 BLU-97s or six BLU-108 submunitions or perform a terminal impact maneuver with a unitary warhead. The unitary version adds an autonomous target acquisition (ATA), commercial uncooled IIR seeker and a BLU-111 unitary payload. Since fleet introduction, JSOW has performed like no other weapon in the history of weapon development and deployment. This weapon was delivered to the fleet one year ahead of schedule, under-ran cost targets and met all performance requirements. Since its deployment, it has been used over 60 times in Iraq and Kosovo and has had as many successes. It has clearly surpassed both customer acquisition community and user expectations.
JSOW has been touted as a DoD development program execution benchmark and one the best programs ever executed in Naval Aviation history. Admiral J.V. Chenevey was once quoted in an article in Aviation Week & Space Technology while discussing JSOW IPTs. He commented: “…right now, I can’t imagine how [teaming] could work much better. It was just a maturation process of the contractor trusting its government counterparts, and the government [people] putting themselves into the team—as apposed to just sitting back and critiquing the contractor.”
The JSOW program is a testimony to what can be accomplished through setting up and managing IPTs as described in this paper. When formed correctly and lead with discipline, IPTs will dissolve all time, distance, and culture differences that exist. As these IPTs are managed and lead by a combined and cohesive contractor and customer leadership team with common goals and objectives, the program success stories will continue.
JSOW is integrated on the F/A-18C/D, F-16, B-2, B-52H, and undergoing integration with the F/A-18E/F, F-15E, and B-1B aircraft. Exhibit 8 illustrates the IPTs that were formed and who successfully executed the development contract.