by
Robert B. Northrop
B.S., Computer Science (1987)
Rochester Institute of Technology
Submitted to the System Design and Management Program in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Engineering and Management at the
Massachusetts Institute of Technology
,December 1999
© 1999 Robert B. Northrop. All rights reserved.
The author hereby grants to MIT permission to reproduce and to distribute publicly paper and electronic copies of this thesis document in whole or in part.
Signature of Author .........................
Certified by .............
.-. .
............. . . ..........
System Design and Management Program
December, 1999
.. .... ... .............
Joyce M. Warmkessel
Senior Lecturer, Aeronautics and Astronautics
Thesis Supervisor
A ccepted by ........................................ .........
-. ...-.
Thomas A. Kochan
LFM/SDM Co-Director
("'George M. Bunker Professor of Management
Accepted by .......... ........
Paul A. Lagace
LFM/SDM Co-Director
Professor of Aeronautics & Astronautics and Engineering Systems
MASSACHUSETTS INSTITIUTE
OF TECHNOLOGY
JAN 2 0

<this page intentionally left blank>
2

by
Robert B. Northrop
Submitted to the System Design and Management Program in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Engineering and Management
Abstract
There is an increasing trend in product development to re-use existing architectures, designs and implementations across product lines because of the advantages achieved in time to market, leveraging proven quality and performance, cross-product coherence and efficient use of labor. There is prior work on the benefits of platformbased product development, as well as frameworks and aids that help manage platform-based product development.
This prior work generally considers only a single platform from which multiple products are derived, or assumes a clean-sheet design and development of multiple components that can be coordinated through traditional project management and systems engineering techniques.
However, there are product development environments where multiple platforms are being developed or extended simultaneously but asynchronously from one another, and one or more of these platforms serve as the base for multiple, simultaneous but asynchronous products or systems. New or extended frameworks and aids would improve the development process for systems comprised of multiple platforms by avoiding the following types of problems: deviations from strategic direction regarding the evolution of function and form, improper focus on the short-term, improper focus on individual products or platforms, poor coordination of the asynchronous development of platforms and products, unclear roles and responsibilities, sub-optimal use of resources, and system integration issues.
This thesis proposes a set of root causes that lead to ineffective systems development in an asynchronous multiplatform-based product development organization. The prevalence of those causes is assessed in such an organization (the target organization). A framework and set of aids are developed to counter the causes and piloted within a target organization. An assessment of the degree of improvement this framework and aids will have on a relevant subset of those causes is made and the findings reported. The thesis then makes recommendations for further improvement and research.
In summary, the findings indicate that the proposed aids alone, although believed by participants to be an improvement, are not sufficient in addressing the identified set of root causes that lead to ineffective systems development in a multi-platform environment. Additional actions, aids and other improvements are needed primarily in the management domain (e.g., organization structure, processes, etc.). In addition, the study also re-affirmed the notion that effective and efficient communication is a key goal. The information that must be communicated across product and platform teams is necessarily complex, yet any format must walk a fine line between having too little detail (fluff) versus too much (indigestible).
Thesis Supervisor: Joyce M. Warmkessel
Title: Senior Lecturer, MIT Aeronautics and Astronautics
3

I would like to thank my advisor, Joyce Warmkessel, Senior Lecturer MIT Aeronautics and
Astronautics Department, for her guidance on this thesis. Her inputs helped me more clearly identify the goals and present the research, and allowed me sufficient freedom to pursue a topic of interest to my sponsor company and myself.
I am grateful to my employer for sponsoring my participation in the System Design and
Management (SDM) program. Special thanks to my management and referrals for proposing and selecting me as a candidate, and for my management's ongoing support of my participation in the program while knowing it would mean less time at work. I would like to thank the management and other members of my home organization for allowing me to use them as the subject of this study, especially those who gave their time to participate in the interviews and survey.
This thesis is the culmination of my two-year journey through the SDM program. It has been a taxing, but educational and rewarding experience. The greatest highlights from the last two years are the unforgettable memories of both the hard work and fun I experienced with my SDM
'98 cohort. I consider myself fortunate to have been with them, and look forward to continuing interactions with my new friends.
I would like to thank my parents for providing me the capabilities and instilling in me a drive that has enabled me to achieve so much, the latest accomplishment being selection to and graduation from the SDM program.
More than anyone else, I want to acknowledge and thank my wife and friend Lisa, and my two daughters, Rachel and Emily! They have made the biggest sacrifice over the last two years. The
"balance" between work, school and family hasn't been a balance at all, weighted instead to work and school over family. I regret that I haven't been able to spend more time with my family, but know they are strong and have grown from this experience as well. I consider myself the luckiest man to have a wife and friend so supportive and loving, and know we will all be glad for me to finally "come home".
4

Table Of Contents
A CK N O W LED G EM EN TS ........................................................................................................................................ 4
1. INTRO DU CTIO N ...................................................................................................................................................
1.1 M OTIVATION.......................................................................................................................................................
1.2 PROBLEM STATEM ENT ........................................................................................................................................
1.3 GOALS OF THESIS ..............................................................................................................................................
1.4 ASSUM PTIONS AND SCOPE ................................................................................................................................
1.5 USE AND PROTECTION OF PROPRIETARY AND CONFIDENTIAL INFORMATION ..................................................
1.6 DOCUM ENT CONVENTIONS AND TERMINOLOGY .............................................................................................
1.7 DOCUM ENT OVERVIEW .....................................................................................................................................
2. TARG ET O R G AN IZA TIO N...............................................................................................................................
2.1 OVERVIEW OF THE PRODUCTION PRINTING BUSINESS ......................................................................................
2.2 ORGANIZATIONAL STRUCTURE AND ROLES....................................................................................................
2.3 PLATFORM S ......................................................................................................................................................
2.4 SYSTEM S...........................................................................................................................................................
2.5 PRODUCTS.........................................................................................................................................................
2.6 PILOT SCOPE AND D ATA COLLECTION ..............................................................................................................
3. R O O T CAU SES....................................................................................................................................................
3.1 ANALYSIS .........................................................................................................................................................
3.2 PROPOSED FRAM EW ORK ...................................................................................................................................
3.3 PROPOSED AIDS OBJECTIVES AND SCOPE .......................................................................................................
4. PRO PO SED A IDS ................................................................................................................................................ 36
4.1 DEGREE OF IMPROVEM ENT ...............................................................................................................................
4.2 INFLUENCES ON FUNCTION AND FORM ...........................................................................................................
4.2.1 Proposed Influences D iagram ..................................................................................................................
4.2.2 Advantages Compared To Other M ethods ...........................................................................................
4.2.3 Expectations .............................................................................................................................................
4.2.4 W ithin the Target Organization................................................................................................................
36
4.3 EVOLUTION OF FUNCTION AND FORM ...............................................................................................................
4.3.1 Proposed Evolution D iagram ...................................................................................................................
4.3.2 Advantages Compared To Other M ethods ...........................................................................................
4.3.3 Expectations .............................................................................................................................................
4.3.4 W ithin the Target Organization................................................................................................................
4.4 SCHEDULE OF PRODUCTS AND PLATFORM S ......................................................................................................
4.4.1 Advantages Compared To Other M ethods ...........................................................................................
4.4.2 Proposed Product/Platform Chart .....................................................................................
4.4.3 Expectations .............................................................................................................................................
4.4.4 W ithin the Target O rganization................................................................................................................
4.5 SCHEDULE OF FUNCTION AND FORM .................................................................................................................
4.5.1 Proposed Feature/Platform Chart....................................................................................
4.5.2 Advantages Compared To Other M ethods ...........................................................................................
4.5.3 Expectations .............................................................................................................................................
4.5.4 W ithin the Target Organization................................................................................................................
54
54
...... 56
57
58
61
....... 61
63
63
65
45
46
47
48
50
36
36
39
40
41
5. CO N CLU SIO N ...................................................................................................................................................... 71
5.1 SURVEY RESULTS .............................................................................................................................................
5.1.1 Expectations Not M et ...............................................................................................................................
5.1.2 Expectations Exceeded .............................................................................................................................
5.1.3 How The Aids W ere Used.........................................................................................................................
25
31
33
71
74
75
75
9
9
9
10
11
11
11
13
14
14
15
17
19
20
22
25
5

5.2 THESIS CONCLUSIONS.......................................................................................................................................
5.3 AREAS FOR FURTHER STUDY ............................................................................................................................
5.3.1 Expanding the Scope ................................................................................................................................
5.3.2 Applicability to Other Contexts ................................................................................................................
5.3.3 Better M easurem ent and Longer Pilot ..................................................................................................
BIBLIOG RA PH Y .....................................................................................................................................................
A PPEN D IX A R O O T CA U SE AN A LY SIS..........................................................................................................
APPENDIX B ROOT CAUSE SURVEY DATA ..............................................................................................
APPENDIX C PROPOSED AID SURVEY DATA .........................................................................................
81
83
76
78
78
79
79
80
85
6

Table of Figures
Figure 1 System s, Products, Platforms ...........................................................................................................
Figure 2 - Product Positioning ..........................................................................................................................
Figure 3 Organization / Project Structure ....................................................................................................
Figure 4 - Platform Relationships .....................................................................................................................
Figure 5 - System Configurations .....................................................................................................................
Figure 6 M arket Segmentation Grid ...............................................................................................................
18
19
13
14
16
Figure 7 Survey Population Demographics ................................................................................................
Figure 8 Root Cause Fishbone........................................................................................................................
Figure 9 M edian Prevalence Rating By Cause ...........................................................................................
Figure 10 Holistic Framework........................................................................................................................
20
24
26
30
32
Figure 11 Purpose of Proposed Aids ..............................................................................................................
Figure 12 - Scope of Proposed Aids .................................................................................................................
Figure 13 Simple Influence Diagram ..............................................................................................................
Figure 14 Generic Influence Diagram ............................................................................................................
Figure 15 Influence Diagram for Pilot............................................................................................................
33
35
36
38
43
Figure 16 - Evolution Diagram .........................................................................................................................
Figure 17 Evolution Diagram for Pilot...........................................................................................................
Figure 18 Product Vintage Chart....................................................................................................................55
46
51
Figure 19 - Platform Lineage Chart ..................................................................................................................
Figure 20 M ultiple Platform Lineage Charts ..............................................................................................
56
56
Figure 21 Product/Platform Chart...................................................................................................................57
Figure 22 Product/Platform Chart for Pilot ....................................................................................................
60
Figure 23 Feature/Platform Chart...................................................................................................................62
Figure 24 Feature/Platform Chart for Pilot..................................................................................................... 67-70
Figure 25 Percent Meeting or Exceeding Expectations for Influence Diagram...........................................72
Figure 26 Percent Meeting or Exceeding Expectations for Evolution Diagram........................................ 72
Figure 27 Percent Meeting or Exceeding Expectations for Product/Platform Chart .................
Figure 28 Percent Meeting or Exceeding Expectations for Feature/Platform Chart....................................73
73
7

Table of Tables
Table 1 Root Cause D efinitions......................................................................................................................
Table 2 Influence D iagram Expectations........................................................................................................
Table 3 Evolution D iagram Expectations .......................................................................................................
Table 4 Product/Platform Chart Expectations ................................................................................................
Table 5 Feature/Platform Chart Expectations.................................................................................................
Table 6 Frequently M entioned Root Causes..............................................................................................
Table 7 - Additional Root Causes .....................................................................................................................
27-28
41
49
58
64
77
79
8

There is an increasing trend in product development to re-use existing architectures, designs and implementations across product lines because of the advantages achieved in time to market, leveraging proven quality and performance, cross-product coherence, and efficient use of labor.
Prior work has shown how platform-based development in a variety of industries can be beneficial [1] [2] [3] [4] [5] [6].
Meyer and Lehnerd define a "platform" as "the set of subsystems and interfaces that form a common structure from which a stream of derivative products can be efficiently developed and produced."[1] Robertson and Ulrich define "platform" as "the collection of assets that are shared
by a set of products" and further divide these assets into components (the "chunks" or form), processes (production and manufacturing process and equipment), knowledge (techniques, models, methods, and general design know-how), and people and relationships (the teams involved and relationships between them) [2].
Jandourek presents a "Model for Platform Development", detailing among other things how to manage and plan the product portfolio through the use of product vintage and platform lineage charts [7].
The focus of the prior work, with the exception of Robertson and Ulrich, is on a single platform.
The interesting twist is when there are multiple platforms and their respective development teams operate somewhat independently, concurrently and asynchronously from one another, yet somehow they must come together to form a product. This is particularly troublesome when a feature spans multiple platforms (and interfaces) requiring development effort on multiple platforms' part, but the availability of the pieces of that feature may not all come together at the same time such that it can be made available in a product. This may be due to the asynchronicity of the platforms' schedules, or due to constraints (technology, resource, architectural, 3rd party, etc.) specific to each platform. By asynchronous, I am referring to the case that the development and release cycles of various platforms and/or products do not coincide; e.g., Platform-x delivers a new release every 3-4 months, Platform-y every 12 months, Product-A may launch in 1 Qyy,
Product-B in 4Qyy, etc. Another complication is in dealing with transitions from the prior nonplatform-based systems that were developed and are still in use by customers along with the newer platform-based systems, or from one technology to another which has impact across more than one of the system's platforms. Additional goals or characteristics of effective systems development, not necessarily specific to platform-based development, include meeting customer needs, consistent and predictable ability to deliver, and issue-free system integration.
Organizations need clear strategies, means of communicating those strategies to all involved, and techniques to track the implementation of those strategies effectively.
9

There is prior work on the benefits of platform-based product development, as well as frameworks and aids that help one manage platform-based product development. This prior work generally considers only a single platform from which multiple products are derived, or assumes a clean-sheet design and development of multiple components that can be coordinated through traditional project management and systems engineering techniques.
However, there are product development environments where multiple platforms are being developed simultaneously but asynchronously from one another, and one or more of these platforms serve as the base for multiple, simultaneous but asynchronous products or systems.
New or extended frameworks and aids would improve the development process for systems comprised of multiple platforms by avoiding the following types of problems: deviations from strategic direction regarding the evolution of function and form, improper focus on the shortterm, improper focus on individual products or platforms, poor coordination of the asynchronous development of platforms and products, unclear roles and responsibilities, sub-optimal use of resources, and system integration issues.
More specifically, the system development process would improve by realizing benefits from new or extended frameworks and aids that address the following:
" Unknowing deviation from strategy and tactics, improved by more clearly and efficiently communicating such with formats that reduce cognitive load and allow quick "information pick up" (e.g., graphical, one-page formats)
" Hindrances to flexible problem solving, improved by communicating overall intent versus just specifics
" System integration issues and unnecessary duplication of effort across platform teams, improved by communicating a clear allocation and identification of functionality and form across multiple platform teams and responsibility for such
" Uncoordinated design and implementation effort, improved by a synchronized delivery of system-level functionality that spans multiple asynchronous platforms
" Wasted time and effort spent seeking, debating, and/or re-clarifying decisions, improved by communicating at appropriate levels of detail and in a way suitable for members in various roles within the organization (business team, development managers, planners, architects, designers, developers)
" Short-term, platform- or product-specific focus which could preclude or make difficult the evolution, retirement or introduction of function and form supportive of the desired state, improved by ensuring a long-term, holistic, and system-level view
This thesis does the following:
* proposes a set of causes that lead to ineffective systems development in an asynchronous multi-platform-based product development organization
" proposes a holistic framework within which aids are proposed that can be employed in such organizations to counter a portion of those causes
10

* assesses the prevalence of those problems in a software development organization (the target organization) within a leading printer development firm
* pilots the proposed framework and aids in the target organization
* assesses the degree of improvement these proposed aids have on a relevant subset of those causes
* makes recommendations for further improvement and research
Systems development is a wide field of study. Successful systems development requires the harmony of many factors including, but not limited to: planning, communication, coordination, organization structure, culture, marketing, engineering, management, technology, and capability.
There is much that can go wrong. This thesis presents a holistic framework within which aids are proposed. These aids are designed to address a subset of the many root causes that can lead to ineffective systems development. They will not ensure success alone. In particular, this thesis will not address organization- and process-related issues or aids; e.g., structure, procedures, incentive systems, and funding models. Areas such as communication and efficient use of resources are touched on lightly.
No specifics regarding the target organization are used in this paper in order to protect the target organization's proprietary information. This includes information pertaining to its products and platforms, technologies, release dates, and people. Examples and figures are based on publicly available information from companies or industries or have been otherwise altered to preserve confidentiality and protect proprietary information. These steps do not compromise the objectives or findings of this study.
The following terminology and conventions are used in this document.
Aids Aids refers to graphs, charts, or diagrams intended to be effective means of documenting and communicating particular information; the proposed work products which are the subject of this study.
Form
Function
Participants
Form refers to where the physical and logical chunks or blocks are in a system. Form defines the shape and structure of something. Form is the parts, components or elements which implement the product's function.
Form is solution specific [8].
Function is how the system behaves, the operations and transformations that contribute to performance, and the action for which a thing exists.
Function is solution neutral (independent of form) [8].
Participants refers to the members of the target organization that took part in the interviews and survey.
11

Pilot
Release or Version
Pilot refers to the application of the proposed aids within the target organization.
These terms are used interchangeably. A release or version is a specific instantiation of a Product or Platform implementation in time.
Target organization Target organization refers to the organization within a firm in which the proposed framework and aids were piloted.
Work Product A work product is the item that captures the output of a process step; e.g., a requirements specification or other document. The proposed aids are examples of work products.
Platform
Product
A Platform is a common component that has form and provides some functionality, and is shared in different System configurations. A Platform is not typically viable as a Product itself but there are exceptions.
Platforms are developed and released somewhat independent from other
Platforms. The release cycle of Platforms is typically on the order of months to years, with longer cycles for hardware-oriented Platforms.
A Product is a Platform or System that is named and sold for a specific market. This may involve adding function or form, or tailoring of the
Platform or System for a specific market, thus giving it product-unique characteristics. Products are developed and released somewhat independent from Platforms and other Products. The release cycle of
Products is typically on the order of a year.
System A System is a collection of two or more Platforms that together provide a greater benefit or serve a greater purpose than achievable by the Platforms alone (the whole is greater than the parts). A System is a configuration, and as such does not follow a release cycle like Platforms and Products do.
The relationship between Platform, System and Product is graphically depicted in Figure 1.
12

Figure 1 Platforms, Products, and Systems
Products
Systems
Platforms
Chapter 1 of the document has provided an overview of platform-based product development, including the nuances when there are multiple asynchronous platforms. In particular, the importance of communicating and managing the vision, strategy, tactics and rollout (schedule and plan) across multiple platform and product teams has been mentioned. The goals of the thesis have been stated. Finally, it has established the scope, terminology and any conventions applicable through the remainder of the document.
Chapter 2 discusses a primarily software-oriented platform-based product development organization (the target organization) within a leading printer vendor firm in which new and extended framework and aids were applied. The scope of the pilot and method of data collection are also discussed.
Chapter 3 discusses the root causes to ineffective systems development, and defines which of these are to be addressed in this study. A holistic framework is presented within which various aids are proposed to address these root causes.
Chapter 4 discusses in detail the proposed aids, the root causes they will address and why, and their value over traditional methods for communicating and managing product and platform schedules, and the evolution and schedule of function and form.
Chapter 5 discusses the method by which the effectiveness of the proposed aids is gauged, and the findings for each aid, including significant lessons that may not have been originally pursued.
Areas for further study, including recommendations to improve this study, are identified.
13

The target organization for this study is a division within a leading laser printer vendor. More specifically, the target organization delivers printing systems for the production printing market.
The printer markets can be roughly summarized as follows:
" Home/Desktop Desktop printers and multifunction systems are designed to meet the needs of individual users or a small group of users in a shared environment; the home and smalloffice-home-office (SOHO) market.
* Office/Workgroup Workgroup systems are designed to meet the needs of many users in a shared environment; the Office market.
* Production High performance production printing systems support high-speed document production in centralized and distributed data centers, electronic publishing groups, commercial printing environments, and in some cases office workgroups; the Production
Printing market.
Figure 2 - Product Positioning
A A
Production
Price
Workgroup Xerox, IBM, Oce,
Xeikon
Desktop
HP, Epson, Canon,
EC, Lexmark, Xero
Xerox, HP, NEC,
Lexmark, IBM
Performance (speed, features, reliability, etc)
Figure 2 summarizes the relative positioning of these printer products in terms of price and performance, and lists some of the leading vendors in each category. Note that these lists are not intended to be exhaustive.
14

The Production printing market, for xerographic devices alone, is a multi-billion dollar business.
The customers for production printing systems are typically not the final consumer of the printed documents these systems produce; rather, they are in the business of printing for others.
Example customers include: R.R. Donnelly and other commercial printing firms, Boeing and other firms that produce large documentation for their products, and Kinkos and other "quick printers" that reproduce and print documents for walk-in customers. Example applications in which these systems are used include: "student reader packs" for college courses, equipment service and training manuals, pamphlets and brochures, prospectus, insurance policies, bank and credit card statements.
Production printing systems are typically composed of several networked elements, connected via local-area-network (LAN) or point-to-point cabling. Each element is a collection of hardware and/or software components. Production printers differ from those for other markets on the following characteristics:
" Speed Run-lengths (the number of copies printed) are in the thousands, so speed is of the essence. Speed for these systems, as measured in pages-per-minutes (ppm), ranges from
90ppm to over 180ppm.
" Feature Functionality These systems are capable of supporting a variety of input pagedescription-languages (PDL's) such as PostScript, many network connectivity options and protocols, graphical-user-interfaces (GUI's) for performing administrative and job management functions, various image manipulations (duplex, imposition, signaturization for booklet making), and have on-board in-line finishing capabilities (stitching, tape binding).
" Reliability These systems are critical to the customer's business and operation. The systems are often run 24x7, and downtime or unpredictable behavior must be minimal.
Reliability measures on the order of "one failure per millions of prints".
" Image Quality Image quality and high resolution (as measured in dots-per-inch or dpi) are critical.
" Price/Cost Given the capabilities described above, these systems command a premium price, roughly in the $250,000 to $500,000 range (at time of this writing), and represent a significant capital investment on the part of the customer. The customer typically looks not only at the initial price of the system, but at total cost of ownership (TCO) for ongoing operation and maintenance over the many years of the product's life.
" Life-span Given the high costs and robust design, these products have a useful service life of ten years or more.
A summarized view of the target organization from a project and functional perspective is shown in Figure 3.
In terms of reporting structure, the Platform managers and some Functional managers are grouped under a central development manager, who reports directly to the Division Manager.
Some functions such as Customer Documentation lie outside the division, and their services are contracted.
15

Division Mgr The firm to which this organization belongs consists of several business units or divisions intended to address the needs of a particular market.
The target organization belongs to the division responsible for the
Production Printing market. The Division Manager is the head of this particular division.
Product Planning MgrProduct Planning Managers are responsible for particular segments within the division's target market; e.g., black-and-white publishing, transactional printing, color, etc. They oversee the delivery of a particular line of products intended to meet the needs of that segment.
Figure 3 Organization / Project Structure
Functions e.g., SE, CM, Test, Doc
Platforms
e.g., Client, Server, Printer
---
_
I1
*** D ** Z
~d u c t s
0
P r
Project Mgr
Division Mgr
*
Product Planning Mgr
E
Function Mgr
FEl
Platform Mgr
Project Mgr
Project Managers are responsible for the overall delivery of a specific product, from concept, through development, and ongoing support and upgrade. While the project manager's coordination responsibilities are extensive and his influence in the marketing realm great, his influence in the engineering and other functional organizations is limited. The project manager can best be described as a lightweight project manager. The project manager lacks the authority to assign particular resources, and
16

Function Mgr instead works through representatives from the various functions and platforms.
Functional Managers are responsible for cross-platform or cross-product
(i.e., shared) functions such as Configuration Management, Testing,
Customer Documentation, and System Engineering. These functions, like platform teams, typically divide their time across the many projects.
Platform Mgr Platform Managers are responsible for the engineering development of a given platform. There are six Platform teams, and these teams support at least six different product lines.
Cusumano defines several models of platform-based product development: new design, concurrent tech transfer, sequential tech transfer, and new design modification [3]. The target organization doesn't fit any of these models exactly, but is similar to the concurrent and sequential technology transfer models. In those models, platforms are incorporated into different products concurrently or subsequent to the platform's development.
Prior to the introduction of the platform concept, each product team effectively had its own development team. With the exception of one platform, there was little sharing or reuse of common components. At best, one development team might take a snapshot of another development team's component, but then those components would evolve on their own paths.
Eventually this was perceived as an inefficient use of resources due to the duplication of effort in designing and developing components that were largely similar across products, and due to the duplication of skill sets it necessitated. In addition, the development efforts of independent teams inevitably led to incoherent product lines. Similar products that found themselves side by side at a customer site would not interoperate, or had different behaviors that customers would have to work-around. As an example, Client application software was developed independently and specifically for a particular printer product from a snapshot of code borrowed from another product team. Thus, the customer would have to install and use each variant of the Client software depending on the number and types of printers they had on-site, and in many cases the
Client software could not co-exist with its counterparts due to disk file collisions. Platforms were seen as the solution to these problems, and would help meet the increasing demands for faster product delivery.
The target organization moved more formally to platform development teams within the engineering side of the organization about three years prior to this study's publication. The candidates for what was to be considered a platform were largely self-evident in the systems, and thus easily identified.
Figure 4 depicts the various platforms and their inter-relationships. Platforms typically interact over a local area network (LAN) using industry standard and proprietary network protocols. An exception is the interface between the DFE and IOT, which tends to be a proprietary protocol over a serial interface.
17

Client
Scan Station
Client
Scan
Station
This platform consists of a collection of software applications for job submission and monitoring (status). These applications would be available for a variety of client operating systems (e.g., Windows NT®,
UnixTM, etc.).
This platform consists of a collection of software applications and hardware (underlying computer, scanner, extended disk storage) for the creation, management, submission and monitoring of jobs and their images. Customers would use this portion of the system to merge electronic and hardcopy inputs.
Figure 4 Platform Relationships
Printing System (superset)
Printer
4----*Server
_I
DFE IOT
DiagWS
Server
DiagWS
DFE
IOT
This platform consists of software and hardware for job transformation, management and routing across multiple printers. Job routing allows load-balancing of jobs across a fleet of printers or directing jobs with special requirements to specific printers that can meet those requirements
(e.g., jobs requiring signaturization and booklet-making are routed to the printer with that optional capability installed). This platform in particular is not present in every system.
This platform is a collection of software applications and hardware (the underlying computer) used by Service Technicians for diagnostics and service of printers.
This platform, commonly referred to as a Digital Front End, is a collection of software and hardware (underlying computer, image processing hardware) for the reception, rasterization and management of jobs.
This platform, referred to as an Image Output Terminal, is a collection of hardware and control software for the imaging of jobs, including paper handling and finishing (e.g., stapling, binding). There are actually several
18

different IOT platforms, legacy and new. Since the IOT is outside the scope of this study, IOT generically refers to both legacy and new.
A DFE and IOT are typically bundled together to form what many consider to be a "printer".
Platforms may be combined in a variety of ways to create systems. A system may not necessarily include all platforms; some are not relevant to their particular segment, or the product team may elect to use a third party component in place of an internally developed platform. Figure 5 shows some example configurations. Although not shown here, it is understood that these printing systems reside within a larger super-system defined by a particular customer's operation and workflow.
Figure 5 System Configurations
System 2
System I
DiagWS
Client
DiagWS
A
Scan
Station
DFE IOT
DFE IOT
(3rd party
System 3
Client
Server
F
JDFE
IO
IOT
System 1
System 2
System 3
A system aimed at low-end customers, utilizing a lower speed third party
IOT.
A full-up publishing system including the Scan Station capability for customers that have need to merge electronic and hardcopy inputs, or wish to maintain a repository of such images for on-demand printing.
A transaction printing system, which includes the intermediate server platform to manage job flow across one or more printers.
19

There are roughly nine distinct products that make use of these Platforms (including variants and products that consist of a single platform). In some cases, a product team may elect to use a 3rd party component in place of an internally developed platform. These products differ in terms of functionality and speed depending on the particular segment they are intended to address. Also of interest are legacy product lines. These legacy systems were developed prior to the platform concept. There are roughly another six such legacy products. Given the level of investment that customers made in these systems, and the long life-span of the products in general (as much as ten years), customers are not likely to dispose of them quickly. Thus, the target organization must contend with interoperability concerns and transition strategies.
Using notation from Meyer and Lehnard and their "Power Tower" framework [1], Figure 6 is a
"market segmentation grid" for the target organization that shows how platforms feed derivative products destined for different tiers within different market segments.
Figure 6 Market Segmentation Grid
Market Segments
High End
Mid-range
Product B
Product E
Product B' -C)
Product C
0
0
-o
0
Product A
T
I
E
R
S
Low End
Publishing Transaction t
Derivative Products
Office / Workgroup
Platforms
0
Columns represent market segments (e.g., networked document publishing, mainframe based transaction-oriented printing, shared/workgroup office printing). Rows represent tiers within a
20

given segment. These tiers are typically differentiated by cost and performance attributes; e.g., speed in pages-per-minute, color versus black-and-white, in-line finishing capabilities, multifunctional capabilities such as scan, fax, and print. The product "bubbles" indicate the presence of a product offering for that tier within that segment.
Meyer and Lehnard speak of the "leverage" (the degree to which platforms are reused in derivative products) and whether leverage is horizontal (across segments) or vertical (across tiers within a segment). As can be seen from the diagram, the target organization leverages platforms in both dimensions.
The following defines the scope of the products in the target organization included in this study.
Product A A black-and-white printing product targeted for the high-range of the office/workgroup market. This product consists of the following platforms: Client, DiagWS, DFE, and an IOT developed by another division within the firm.
Product B
Product C
For the purposes of this study, Product B refers to several printing products that have somewhat different speeds but similar features and configuration, targeting the high-, mid- and low-range of the publishing market segment. This product consists of the following platforms: Client,
Scan Station, DiagWS, DFE, and IOT.
Product C is printing product targeted for the high-range of the transaction printing market segment. This product consists of the following platforms: Client, DiagWS, DFE, and IOT.
Product D
Product E
Product F
Product G
Product H
Product D is a color printing product targeted for the low-range of the publishing market segment. This product consists of the following platforms: Client, DiagWS, DFE, and a
3 rd party IOT.
Product E is a color printing product targeted for the high-range of the production publishing market segment. It differs substantially from
Product D in terms of features, performance and expected use. This product consists of the following platforms: Client, Scan Station,
DiagWS, a 3rd party DEE, and IOT.
Product F is simply the Scan Station platform in product form, targeted towards all ranges of the publishing market segment.
Product G is simply the Server platform in product form, targeted towards all ranges of the transaction printing market segment.
For the purposes of this study, Product H refers to the collection of legacy products that serve various purposes. These products span market
21

segments and tiers. They are composed of a variety of legacy components, and only a few use any of the Platforms.
The following proposed aids were piloted within the target organization: Influence Diagram,
Evolution Diagram, Product/Platform Chart, and Feature/Platform Chart. These aids are designed to address several root causes leading to ineffective systems development. The
Influences diagram helps the organization keep in mind the various influences on function and form of the product and platforms. The Evolution Diagram helps convey the intended evolution of function and form over a long-term period. The Product/Platform Chart helps the organization coordinate and convey the interdependencies between products and platforms over a long-term period. The Feature/Platform Chart helps the organization coordinate and convey the intended evolution of function and form over a long-term period. The proposed aids were developed and introduced as part of a larger strategy document over a nine-month period to a limited audience in the target organization.
With the exception of the proposed Product/Platform Chart, the function or form of interest in this study is a major system capability versus the entire system. A system capability is a functionally important aspect of a System, which in some cases maps to a predominant customer workflow. Specifically, the study addresses the Job Submission, Status, and Programming
(JSSP) capability. This capability was chosen because it was sufficiently complex yet manageable, and spans the platforms listed in Figure 22 in that each platform either possesses or contributes to this system capability. For the purposes of this study the IOT platform was excluded.
Job Programming functionality is the ability to specify the desired printing instructions for a job.
This includes job re-programming, the reconciliation of multiple sources of job programming, conflict checking, encoding and decoding job programming, and communication and transfer of
job programming. Forms of job programming include "job ticket formats" (both transported with the job and those stored in a persistent form, usually in a disk file), and embedded print instructions. Job Submission functionality is the ability to introduce the job and its job programming into the system for processing. This includes re-submission of previously submitted jobs, submission of compound documents, multi-document jobs, and multiple jobs.
Forms of job submission are print drivers, job submission applications, and print protocols. Job
Status functionality is the ability to ascertain the status of one or more of jobs. Forms of job status include job status applications and status protocols.
Information regarding the prevalent root causes in the target organization and perceived effectiveness of proposed aids against those causes was gathered via interview and surveys of twelve members of the target organization, conducted over a month. Interviews were approximately one hour in length plus additional time for follow-up, if necessary. A survey was completed offline by participants, requiring about one additional hour of their time. The survey population, although small, was selected in an effort to achieve adequate and representative coverage across Platform teams and the various roles (Figure 7). It is possible that the views expressed in this study are not representative of the organization as a whole. The roles which participants were bucketed under are as follows:
22

Business Team
Planner
Development Manager
This category includes Project Managers, their assistants,
Marketing, Sales, and other members of the non-engineering community responsible for the overall delivery and coordination of one or more products.
This category includes persons primarily responsible for planning, scheduling and coordination activities.
This category includes managers in the Platform engineering community.
Development Non-Manager This category includes Platform-level architects, designers and other non-managing members of the Platform engineering community.
Other This category includes (system-level) System Engineers,
Functional Managers, and other persons that didn't fit any of the previous categories.
23

Dev Non-Mgr
18%
Figure 7 Survey Population Demographics
Other
9%
Business Team
28%
Dev Mgr
27%
Planner
18%
Scan Station
14%
Platform Participants
Other
0%
Client
29%
DFE
43%
Sener
14%
24

Based on the experience of the author, ineffective systems development is characterized as follows:
" Slow Platforms and/or products are not being developed and delivered, commensurate with the staffing levels, in sufficient speed to meet time to market requirements
" Inefficient Resources are used inefficiently
" Late Platforms and/or products are not being developed and delivered to expected deadlines
" Doesn't meet needs Platforms and/or products do not meet the requirements and user expectations
" Prone to system integration issues Inter-platform issues arise when systems are assembled from platforms
" Incoherent Functionality that spans multiple Platforms and/or Products differs unnecessarily or unexpectedly
" Unpredictable Platform and/or product delivery is indeterminate
Wheelright and Clark refer to some of these as "consequences" [9].
The Ishikawa "fishbone" diagram (Figure 8) was used to identify root causes to ineffective systems development. Refer to Appendix A for further discussion on the root cause analysis.
25

Scope / Focus
Figure 8 Root Cause Fishbone
Work Products
*
*
"
*
0
0
0
0
Non-holistic view
Too short-term focused
Too platform-focused
Too (project) product-focused
No cross-platform/-product coordination
" High overhead
Poor communication
Revisiting decisions / direction
Unclear roles & responsibilities
" Lack of agreed to definitions
* Doesn't accommodate asynchronicity
* Poor estimation / planning
* Poor change management
* Insufficient detail
" Partial / Absent
" Not accessible
* Not usable
" Doesn't communicate intent
" Unclear allocations
* Not cross-platform/-product
" Doesn't accommodate asynchronicity
" Poor inputs
* Inadequate org structure
* Incentives misalignment
* Cultural resistance to "system" engineering
* Funding model misalignment
S
0
0
0
Inadequate skill sets
High overhead
Duplication of effort
Insufficient staffing
Ineffective System
Development
* Slow
* Inefficient
0 Late
* Doesn't meet needs
* System integration issues
" Incoherence
" Unpredictable
Process Organization Resources

Table 1 clarifies the causes.
Table 1 Root Cause Definitions
Category
Scope / Focus
Work products
Cause Definitions / Clarifications
Non-holistic view As a root cause, a non-holistic view refers to the failure to consider the influences of and effects on upstream and downstream entities as they relate to the development of a system's function and form. Examples of entities are customers, competitors, and manufacturing.
Too short-term focused Fails to take a longer-term view. A short-term only view may result in decisions that preclude or otherwise make difficult the ability to respond to subsequent or inevitable demands because the architecture/design was developed with only the single short-term goal in mind.
Too platform-focused Fails to take a system-level or cross-platform view. A platformonly view may result in local optimization versus optimal system performance.
Too (project) product-focused Fails to take a cross-product view. A product-only view may result in incoherence between products or inefficiencies with respect to other products that share the same platforms.
Insufficient detail
Partial / Absent
Not accessible
Work products either lack necessary detail, or are too detailed.
The former leaves open critical questions, while the latter can unnecessarily constrain the solution space.
Critical work products are incomplete or do not exist. Examples: incomplete requirements, no system architecture, etc.
Work products are not readily accessible by those who need them.
Example: they are not easily located in a network repository.
Not usable Work products are not easy to use by those who need them.
Examples: large text-based work products that can not be feasibly consumed or referenced, work products poorly communicate their essentials, etc.
Doesn't communicate intent Work products communicate only final conclusions or specification, without mentioning the driving intent or desire.
This can make flexible problem solving and trade-off analysis
Unclear allocations
'problematic.
Work products don't clearly communicate who should deliver what.
Not cross-platform/-product Work products don't comprehend all products, systems and the platforms that comprise them.
Doesn't accommodate asynchronicity
Poor inputs
Work products don't comprehend the asynchronous development and delivery of products, systems and platforms that comprise them.
Inputs to the work products are of low quality or non-existent.
Example: incorrect customer requirements conveyed by external organizations, faulty corporate directives.
27

Table 1 (cont.) Root Cause Definitions
Category
Process
Organization
Resources
Cause
High overhead
Duplication of effort
Insufficient staffing
Definitions / Clarifications
No cross-platform/-product The process doesn't comprehend or coordinate the multiple coordination products, systems and platforms that comprise them.
High overhead The process requires substantial or unduly high effort of its participants.
Poor communication
Revisiting decisions / directions
The process does not effectively communicate the essentials
(inputs, decisions, etc) to the necessary participants.
The process allows or requires continual re-processing of decisions. Examples: decisions are re-opened, decisions must be re-communicated, there is an infinite right of appeal.
The process does not clearly define roles and responsibilities.
Example: unclear decision authority.
Unclear roles & responsibilities
Lack of agreed to definitions The process is not built around well-defined terms. Example: what is a "system" and what are its boundaries.
Doesn't accommodate asynchronicity
The process doesn't comprehend the asynchronous development and delivery of products, systems and the platforms that comprise them.
Poor estimation / planning Plans are non-existent, or of poor quality. Examples: fail to consider all tasks, don't allow appropriate buffer, built on poor estimates
Poor change management The process does not effectively manage changes. Examples: changes are too frequent, changes are not communicated, etc.
Inadequate org structure The organization structure is not conducive to effective systems development.
Incentives misalignment Incentives are not conducive to effective systems development.
Example: management rewards local optimization (within a particular platform) versus effort toward system optimization.
Cultural resistance to system A system-engineering function (overseeing systems analysis, engineering strategy, architecture, design, requirements, allocation, etc) is not actively supported or encouraged at all levels of the organization.
Examples: System engineering is not seen as a desirable career path, system engineering directives can be disregarded.
Funding model misalignment The funding of development efforts is not conducive to effective systems development.
Inadequate skill sets The organization lacks the necessary skills for systems development. Example: the organization lacks skilled resources in system engineering, planning, shared component management, software development, general management, etc.
Inefficient use of resources due to overhead effort that diverts from essential systems development tasks. Examples: frequent meetings and effort not related to systems development directly, numerous other initiatives underway that are not directly related to systems development
An inefficient use of resources due to the duplication of effort.
Example: multiple implementations of the same functionality across different teams.
Critical functions are not staffed appropriately. Example: insufficient architecture or system engineering staff.
To determine whether this list was sufficient and accurate, participants from the target organization were asked to rate the prevalence of these causes prior to the introduction of any of
28

the proposed aids, where prevalence is a combination of presence and significance. Prevalence was measured on a scale of 1 to 5, where 1 means the cause was not present and thus not a problem and 5 means it was present and was a significant cause of ineffective systems development in the target organization.
Figure 9 is a radar chart summarizing those findings, plotting the median rating for each problem
(for details refer to Appendix B). Of interest are those causes whose median rating was 4 or higher (i.e., half the participants rated the prevalence to be 4 or 5). Participants indicated that there were other causes than those presented in this graphic but their discussion is deferred until
Chapter 5.
29

Figure 9 - Median Prevalence Rating By Cause
(1 =absent, 5=very prevalent)
Insufficient staffin
Duplication of effort
Non-holistic view
Too short-term focused
Too platform-focused
High overhead
Too (project) product-focused
Inadequate skill sets
Insufficient detail
Funding model misaligned
Partial / Absent
Cultural resistance to system engineering
Not accessible
Incentives misaligned
Not usable
Inadequate org structure
Doesn't communicate intent
Poor change management
Unclear allocations
Poor estimation / planning
Not cross-platform/- product
P-Doesn't accommodate asynchronicity
Doesn't accommodate asynchronicity
Lack of agreed to definitions
Poor inputs
Unclear roles & responsibilities
Revisiting decisions / directions
P-No cross- platform/-product coordination
High overhead
Poor communication

By understanding the causes of ineffective systems development, one can then propose structures, processes and/or work products that counter or are less susceptible to these causes. A holistic view should be fundamental to such a framework. Crawley presents a holistic framework that captures the whole and identifies all things that must be considered by the architect for both the product and process domains [8]. As he points out, holistic thinking means "considering the whole". Crawley notes that holistic thinking ensures the following of a good architecture:
" Satisfies customer needs and requirements specifications
" Incorporates appropriate technology
" Meets strategic business needs
" Meets or exceeds present and future regulations
" Is operable, maintainable, sustainable, reliable
* Can be evolved and modified as appropriate
" Can be designed and manufactured by envisioned team
" Can be manufactured with existing and planned capabilities
This is consistent with the goals for effective systems development:
" Speed When considering concepts or the introduction of technologies, a holistic view factors in the desired timeframes for delivery, current staffing levels and skill sets, manufacturing considerations, and other considerations.
" Efficiency A holistic view identifies similar activities within the organization for potential consolidation or to head off potential duplication or incoherence.
" Predictability and Consistency A holistic view considers the likelihood and consequences of unpredictable and inconsistent delivery and supports a more proactive role in project scheduling and management. Difficulties in delivering are seen across platforms and suppliers in advance, and not as a surprise.
" Meets needs A holistic view identifies the (potentially conflicting) needs and requirements from various sources including different types of customers, multiple product teams, engineering, the industry in general, as well as what is needed to stay with or ahead of competition. Conflicts between requirements are identified for resolution.
" Issue-free integration A holistic view considers the cross-product and cross-platform implications in advance.
" Coherency A holistic view considers cross-product and cross-platform functionality and behavior in advance. Incoherence occurs only as a conscious and desirable decision, not as a surprise.
31

Management structure r
Figure 10 Holistic Framework
Technical
- e -platform
Plan
~~ productI process people evolution schedule
-X
The framework proposed by this thesis is shown in Figure 10. The holistic view spans the framework's domains of Management, Technical, and Plan. The Management domain refers to the reporting and incentive structures, people, culture, and procedures by which platform-based product development occurs. In terms of a holistic view, the Management elements need to be designed with properly aligned funding and incentive systems, reporting structures, roles and responsibilities, and procedures conducive to multi-platform and multi-product systems development.
The Technical domain refers to the work products that detail what technologies are to be employed in products and platforms, and how those work products communicate transitions and evolutions of function and form. In terms of a holistic view, technical work products must consider all the influences on function and form (internal or external, upstream or downstream) and must consider transition strategies that allow all impacted parties (e.g., development, service, manufacturing, customers) to accommodate the introduction or retirement of function and form.
A unified vision, strategy, and tactics for achieving the vision need to be communicated across the various product and platform teams. The vision is some desired longer-term state in terms of functionality or use of particular technologies. The strategy is analysis, summary and position statements and direction against a wide range of relevant factors, influences, and technologies.
Tactics are specific shorter-term positions and actions in support of the strategy and movement to the desired state; e.g., specific technologies to be employed in the next release, interface changes, etc.
The Plan domain refers to the work products used to communicate and track product and platform releases, lineage, and the introduction or retirement of specific function and form against timelines and releases. In terms of a holistic view, the planning work products must take a cross-product and cross-platform perspective, consider the ability of the organization to deliver, and must clearly communicate the expectations of product and platform deliverables. Platform teams, serving many products, need to see a consolidated view of what is expected of them and
32

when. Product teams, utilizing many platforms, need to see a consolidated view of similar platform-level information. Some work product is needed to communicate and manage the multiple, parallel, and asynchronous product and platform team activities within the organization. More specifically, the details regarding what track-able feature (function) and technologies, protocols, or applications (form) are to be introduced, by whom, and by when.
Within each domain, specific aids are proposed. These aids were developed as extensions to existing ideas or tools, and are based primarily on the experience of the author. A fundamental goal is to ensure a holistic view; i.e., to consider the influences on function and form, to convey intent versus only outcomes or directives, to have a long-term view including transition from the current to a desired state, and to have a cross-product and cross-platform view.
Another common theme for the aids being proposed is for graphical versus textual display of information, preferably in one-page formats, with supporting text accompanying it for first time users of the material or as a reference. As is often the case, organizations are increasingly pressured to do more, faster, and with fewer resources. This tension is further exacerbated in organizations where teams (platforms) are also serving many masters (products). Time is precious so lengthy specifications are unlikely to be read, e-mail is ignored or skimmed, it is hard to schedule anyone's time for meetings, and it is a challenge to get the many individuals "on the same page" regarding direction and decisions. Information must be communicated and presented in an effective and efficient manner. A picture is hopefully worth a thousand (easily read) words, provided it doesn't confuse or frustrate the user.
As shown in Figure 11, these aids are intended to address some subset of the root causes leading to ineffective systems development.
Figure 11 Purpose of Proposed Aids
Root Causes aids_ aids
Framework
33 aids

Two aids are proposed for the Technical domain:
* Influences Diagram The Influences diagram helps the organization keep in mind the various groups, specific entities within those groups, and the specific influences those groups exert on the function and form of the product and platforms.
" Evolution Diagram The Evolution Diagram helps convey the intended evolution of function and form over a long-term period.
Two aids are proposed for the Plan domain:
" Product/Platform Chart The Product/Platform Chart helps the organization coordinate and convey the interdependencies between products and platforms over a long-term period to a quarterly and release number level of detail.
" Feature/Platform Chart The Feature/Platform Chart helps the organization coordinate and convey the intended evolution of function and form over a long-term period to a quarterly and release number level of detail.
Note that the Management domain is not within the scope of this thesis, thus no specific aids are proposed or assessed regarding the Management domain. As a result, the aids which are proposed are not intended to address the Process and Organization root cause categories from the
Ishikawa diagram from Figure 8, and only minor impact is expected within the Resources category. Figure 12 indicates more specifically which root causes within the Scope/Focus, Work
Products and Resources categories these aids are intended to address.
34

Figure 12 Scope of Proposed Aids
I
_Proposed
UO aD
0
C
E
Cu
6
CM
CO
Non-holistic view
Too short-term focused
O
LL
CL
-0
2L
Too platform-focused
Too (project) product-focused
Insufficient detail
Partial / Absent
Not accessible
Not usable
Doesn't communicate intent
Unclear allocations
Not cross-platform/-product
Doesn't accommodate asynchronicity
Poor inputs
Inadequate skill sets
2 High overhead
Duplication of effort
Insufficient staffing
E
CO
0,
C:
0
0 aids
0
C.)
-t as
.0
0
0
0C
CL (
Indicates expectation of positive improvement for that root cause
35

The degree of improvement expected from a proposed aid against a particular root cause is measured on a simple High/Low rating as explained below.
H
L
The proposed aid will significantly improve on the problem
The proposed aid will have some improvement on the problem
The proposed aid will make the problem worse
<blank> The proposed aid will have no effect
These expectations are speculative, and are based primarily on the author's experience. A more detailed discussion of these relationships and expectations appears as each aid is introduced.
4.2.1 Proposed Influences Diagram
The proposed aid, the Influences diagram (Figure 13), helps the organization keep in mind the various groups, specific entities within those groups, and the specific influences those groups exert on the function and form of the product and platforms. This can be thought of as a "radar screen", on which all relevant "bogies" can be listed. The diagram consists of the item of interest in the middle, with specific groups and their influences listed around it.
Figure 13 Simple Influence Diagram
Group
Entities
Group
Entities
Influences
Influences
Function / Form
Influences
Influences
Group
Entities
Group
Entities
36

The explanation for each component of this diagram follows:
Function/Form This is the system of interest, or perhaps a component or aspect of the system of particular interest. This may be function, form, the name of the system being developed, or a detailed form for a particular piece of system functionality. In the case of the target organization, a major system capability (function) was listed.
Group
Entities
This is a collection of entities within the domain of interest.
These are specific parties within a group which exert influence on the function or form of interest.
Influences These are specific influences on the function or form of interest.
Depending on the domain and the specific group, these influences may include standards (de-facto or otherwise), corporate objectives, emerging technologies, or customer requirements to name a few.
The groups, entities and influences are undoubtedly domain specific. A relatively comprehensive set of groups is depicted in the generic diagram (Figure 14), minus specific entities and influences. One may wish to include the complete set of groups in their domain specific diagram even if that group is not currently applicable or doesn't exert a specific influence within the given domain, since it is possible that over time the degree of applicability changes. This is a tradeoff, however, between completeness and clutter.
37

Business
Teams
Figure 14 Generic Influences Diagram
Corporate
Government
Manufacturing
EngineringCompetitors
Function / Form
Customers
Service /
Support
Suppliers
Tech. /
Industry
A more detailed explanation of each of these groups follows.
Corporate Corporate or division-level entities may exert influences in the form of corporate ROA or market share objectives, requirements for interoperability between products and systems from other divisions and your system, requirements from corporate-wide system engineering or architecture, etc. One would list those corporate entities of interest, the names of other divisions, etc.
Business Teams These are the product business teams responsible for the overall delivery of particular Products. These entities exert influence on the system of interest, primarily in the form of requirements for their products. One would list the relevant Products as entities within the Business Teams group. It is infeasible to list all the requirements in the diagram as influences. Rather, one may elect to list types of influences such as backward compatibility or interoperability.
38

Engineering
Manufacturing
Service / Support
Suppliers
This is the group responsible for the actual design and development of the function or form of interest. Entities within this group include the various platform teams, system engineering, and other support groups such as configuration management, testing, etc. Influences here might include internal infrastructure projects to make the system more robust or extensible, but which have an effect across the platforms that comprise the system.
This is the group responsible for the mechanical assembly of the system.
Influences might include design-for-manufacturing objectives, automation restrictions, etc.
This group represents those entities responsible for service and support of the delivered system, include field maintenance, hotline support, etc.
This group represents those external entities on which the organization is dependent for components. This might include parts suppliers, off the shelf software component providers, or operating system vendors.
Tech. / Industry
Customers
This group represents technology and industry entities. This might include trade organization and standards bodies. Influences might include specific emerging technologies or standards.
This group represents the target customers for the products in question. It is infeasible to list all potential customers as entities. Rather, one may list types or classes of customers; e.g., end users, system integrators, etc.
Competitors This group represents those organizations offering competing solutions.
One would list the relevant competitors as entities. Influences might include benchmark performance attributes that the system must now meet to remain competitive.
Government Alas, the government is almost always an influence in some form or another. Example influences include environmental or safety standards.
Entities would be those government entities exerting those influences such as the Federal Aviation Administration (FAA).
4.2.2 Advantages Compared To Other Methods
Crawley presents a "Model of Upstream Influence on Architecture" [8]. The purpose, goals, function, concept and form must reflect these upstream influences and the business context.
Market data determines the needs the system must meet. Corporate strategy (what the company does, how it does it, what the return to investors is, how its competitiveness will be sustained) and Market strategy (in what markets the company will compete, with whom, and how) influence the goals for the system. Goals differ from functions in that goals identify performance characteristics and drive metrics to be used in success criteria. Regulation influences function in
39

that products must meet existing or envisioned regulation or standards. Technology influences the concept in terms of how products incorporate new technology or reuse old technology.
Crawley's model is a good start towards considering the various influences on the development of particular function or form. Its bias, however, is on upstream influences, and it doesn't identify the many potentially significant sub-entities that exert influence. For example, there may be several regulatory bodies of interest, each with a potentially different and/or conflicting set of influences. Likewise, in the case of platform development trying to meet the needs of several different products and their respective markets, there may be several sets of market strategy influences with one product or market favoring speed and another reliability, for example. It is also the case that some entities may influence more items than what is depicted.
Technology and business trends in the commercial printing industry, for example, may dictate that remote administration functionality be made available, and prevalent industry standard protocols such as SNMP may dictate that the component providing that functionality be in the form of an SNMP "agent".
4.2.3 Expectations
Table 2 lists those root causes this aid is intended to address, to what degree, and why.
40

Table 2 Influence Diagram Expectations
Category
Scope / Focus
Cause
Non-holistic view
Too short-term focused
Too platform-focused
Expected
Improvement
(H, L)
H
L
L
L
Rationale
1. The diagram is particularly targeted towards this cause. It raises consciousness of other entities and factors that should be considered during planning and development. For example, implications to
Service and Support costs should be considered during design.
2. The diagram is like a radar screen highlighting items just beyond the immediate planning horizon.
Incentive and other organizational issues will continue to drive a short-term focus in other areas, however.
3. The diagram explicitly identifies the many products and platforms in the organization; there is no bias toward one over the other. Groups, entities and influences are intended to be the superset of those items influencing function or form spanning any of the products or platforms. Incentive and other organizational issues will continue to drive product- or platform-specific focus in other areas, however.
See 3.
Work
Products
Too (project) product- focused
Partial / Absent L
Not usable
Not cross-platform / product
Poor inputs
-
H
H
L
4. In many cases there is no single source documenting the various influences, or responsibility for doing such. Knowledge and consideration of these influences is casual and spread across many work products or individuals.
This diagram fills a particular void.
5. The diagram is intended to be one-page, graphical and intuitive. The actual diagram for the target organization comes with a "backup" one page textual description of how to interpret the diagram (for first time users). This is advantageous compared to countless pages of text buried in a one or more specification or strategy documents, which are unlikely to be read or later referenced.
See 3. The work product itself is cross-platform and cross-product in scope.
See 2. While the diagram does not guarantee that better inputs (e.g., accurate requirements) will be received, it does raise consciousness and cause consideration of other future inputs.
4.2.4 Within the Target Organization
Prior to the use of the Influences Diagram, there was no single source documenting the various influences, or responsibility for doing such. Knowledge and consideration of these influences was casual and spread across many work products or individuals. To improve this situation, an
41

Influences Diagram was introduced in the target organization for Job Submission, Status, and
Programming (JSSP) functionality (Figure 15).
42

Figure 15 Influence Diagram for Pilot
Product-A Product-C
Product-B3
Product-D
Product-E Products
Product-F
Product-G
Legacy Products
Scan Stati on Test
Other Divisions
Server
SysEng Engineering
Client
DiagWS
DFE
IOT
Pet projects
Int erfaces (official nd unofficial)
Funding
Plans
-
CD
;;- g
Functionality
00
Protocols / API' / w Behaviors
Interfaces
(D
Plans
Divis ional Strategy
Cros s-Division
Corporate / Divisional
Corp. Office A r t
Architecture
Req
F roduct uirem ts
Shared mponents
Corp. jectives (ROA, cu mer sat targets)
Resources and
Capacity
Infrastructure work
Strategy / Tactics Job Submission/Status/
Xeikon
Oce'
Indigo
IBM
Competitors HP
Xerox
Solution Enabler
Requests (API's
Feature/Performance
Capabilities
Kodak / NexPress
Legacy and
Emerging Workflows
Quick Printers
Commercial Printers
In-house
System Integrators
4
,
Feature
Requests
Java
SNMP
IPP
HTTP
NDPS
Linux
Jini
L gacy protocols
XML
CUPS
Ad be Portable JT
PDF
PPD, GPD, GPC
Legacy PDL's
Vendors
(e.g., Adbobe, Microsoft)
OT capabilities
Softwar
C ponents
MicroSoft Sun
Adobe
IOT Vendors
SW2000
Trade Orgs
.g., Assoc of Printers)
IETF
PWG

This diagram was developed and distributed in the target organization as part of a strategy document for all JSSP function and form. The diagram includes only those groups relevant to
JSSP. There are many groups from the generic Influences Diagram that are not relevant. For example, in a software environment such as the target organization, there is little influence from
Manufacturing. An explanation of the different groups, entities and their specific forms of influence are as follows:
Products The Product group includes the various product teams that the platforms support. Products possess particular functionality, exhibit particular behavior, and support particular interfaces and API's. The product teams for these products have an obvious influence in terms of funding and target product plans. This group also includes legacy products that were developed prior to platform-based product development and are still in use in the customers. The legacy products exhibit particular behaviors, often inconsistent between themselves and new products. A holistic view contends with these different aspects of the product to hopefully ease customer transitions from the use of legacy products to the newer platform-based ones.
Engineering The Engineering group includes all those entities within the engineering arm of the target organization. These are the platform development teams and the system engineering group. The influences these groups exert include their current resources and capacity. A holistic view considers the organization's ability to deliver when identifying and pursuing particular concepts and solutions. Other influences are the strategies and interface definitions from systems engineering, and infrastructure or pet projects pursued by the platform development teams. A holistic view considers these technical items and activities.
Corporate/Divisional The Corporate/Divisional group includes corporate level entities and entities in other divisions. The corporate architecture group exerts influence through firm-wide requirements, technical strategies, and reusable components that divisions are asked to use so as to achieve product coherency across the firm's complete set of products. The corporate office exerts influence through corporate objectives such as customer satisfaction targets and return on assets (ROA). The platformbased approach helps to achieve the ROA objective, for example.
Customers The Customer group includes the different types of customers relevant to the target organization's product line. For this organization, the types of customers include commercial printers (e.g., RR Donnelly), quick printers
(e.g., Kinko's), in-house printers (e.g., Boeing or others who produce their own documentation), and system integrators that build solutions utilizing the products from the target organization and other firms. The influences that these entities exhibit are primarily in the form of feature requests and other voice-of-the-customer (VOC). As mentioned elsewhere, they also
44

Suppliers exert an influence via the workflows, solutions, and processes they have built around the target organization's product line. A holistic view contends with these influences when considering the evolution and retirement of function and form in the organization's product line.
Competitors The Competitor group includes the firms that compete against the target organization. One could list as influences the specific products against which the target organization competes. In this case, however, we merely noted that the competitors' products exert influence indirectly via their own performance and capabilities. A holistic view considers existing and projected capabilities of the competitors so the target organization's products can stay ahead of them.
Technology/Industry The Technology/Industry group includes those entities in the industry in which the target organization competes; in this case, the production printing industry. Entities include trade organizations which influence the target organization via trends or positions. For example, the printing industry itself may begin to adopt the Adobe@ Portable Document
FormatTM (PDF) as a primary means of file interchange during the production printing workflow. The other entities are those in the technology domain for those technologies relevant. For the target organization this includes standards bodies such as the Internet
Engineering Task Force (IETF) and the Printer Working Group (PWG) which define printing related industry standards such as Internet Printing
Protocol (IPP). Specific influences are those technologies currently employed in the target organization's products and platforms or to be employed in the future. A holistic view considers the industry and technology trends when determining which technologies to employ and when.
The Suppliers group includes those entities that provide components and platforms in the development of the target organization's platforms and products. For this organization these influences are primarily software components such as the Adobe@ PostScriptTM interpreter or print driver components for Microsoft@ Windows@ operating systems. An exception is the use of third party IOT platforms, which indirectly exert influence in that other platforms must reflect the capabilities of the third party IOT
(e.g., job programming). A holistic view contends with the make versus buy decision based on the organization's own internal capabilities as well as the capabilities and other factors of suppliers
Evolution refers to the introduction, migration, and retirement of function and form. A holistic view considers the entire lifecycle of alternative functions and forms. It is infeasible to require changes on the customer's behalf to accommodate the overnight introduction or retirement of function and form. In most cases there must be a period of co-existence between old and new,
45

with sufficient discipline in place to prevent further extensions to the old. Otherwise the newer form is trying to replace a moving target.
4.3.1 Proposed Evolution Diagram
The proposed aid, the Evolution Diagram (Figure 16), is a method to convey the evolution of function and form over time.
Figure 16 Evolution Diagram
Function / Form rA specifics
BC specifics specifics
Evolution of
Function /
Form
Time /
Phase
K s pecifics specifics specifics
The components of the diagram are as follows.
Time
Function / Form
Time is shown on a vertical axis, progressing from top to bottom. In this example time is left somewhat vague as a series of phases. One can use actual dates (years, quarters, etc) if they desire. The advantage of phases is that the organization can discuss intents, timeframes and major transition points that are all relative to some TBD starting point.
Important functions or form are listed horizontally on the top. In this diagram, these are denoted by A, B and C.
Evolution The shapes beneath each function or form depict the evolution of specific function or form. Each shape can be labeled to quickly identify and summarize the specific forms or implementations that are emerging or being retired. The shape of the block for each function or form is intended to convey that item's importance, relevance, prevalence, and/or possibility over time. Some are constant and thus are rectangular in shape. Others
46

decrease and thus are triangular in shape, tapering to a tip as time increases. Others emerge or otherwise are made possible and appear triangular in shape, starting at a tip and growing wider as time increases.
This diagram is purposely vague in that it doesn't dictate specific platform releases or schedules.
The diagram conveys intent of the organization with respect to systems development and evolution of function and form. Planning and scheduling details are addressed by other more schedule-oriented aids (i.e., the Feature/Platform Chart to be discussed later).
4.3.2 Advantages Compared To Other Methods
Foster's S-curves are a method for tracking the evolution of technology [10]. Foster has shown that many technologies follow an S-curve pattern when charted against performance and effort.
Effort refers to the cumulative level of effort and resources applied to incrementally improve the technology. Performance refers to some set of desirable characteristics; e.g., speed, functionality, etc. Initially the improvement of a technology is slow; a lot of effort with little gain. This is followed by a period of rapid improvement; less effort for a lot of gain. Eventually a point of diminishing returns is reached. In most cases a new radical discontinuous innovation or technology appears and eventually replaces the previous technology.
S-curves can be used to display and track the evolution of function or form. For example, printing protocols such as RFC 1179 (lpr) and the emerging discontinuous alternative Internet
Printing Protocol (IPP) can be charted. RFC 1179 offers limited functionality and efforts to extend it (e.g., through the use of proprietary extensions for conveying job programming parameters) have reached a point of diminishing returns. IPP, on the other hand, is an extensible and more feature-rich protocol that enables a higher level of performance.
But S-curves lack some crucial elements for systems development. First, there is only an implied time dimension. Product and Platform teams need to know when transitions to new function or form are to occur both at a rough (strategic, desired) and fine (tactical, committed schedule) level of detail. Second, performance alone may not be the reason for driving certain evolutions. For example, product development may simply want to consolidate multiple implementations of particular functionality into a single form for the purpose of reducing maintenance overhead, and the level of performance of the function really doesn't change.
Finally, S-curves are still too strategic or vague for development teams that need to clearly understand how the evolution relates to and impacts their tasks. For these reasons, S-curves are not the best method to display evolution of function and form to the development teams. This isn't to say that S-curves have no place in systems development. S-curves are still a valuable tool to track technologies and the effort applied, and to forecast when discontinuous innovation is necessary or likely.
One can always document intentions regarding evolution of function and form in traditional ways such as strategy, architecture, design, or systems specification documents. As previously discussed, however, members of the systems development organization are pressed for time and are unlikely to dig through a thousand page multi-volume specification for information such as this. In other cases, traditional documentation may state only the final outcome of analysis based on some rationale. What isn't captured is the rationale. When trade-offs or further problem solving is necessary, lacking the overall intent can make the task error-prone or difficult.
47

Leveson discusses the importance of intentional information in the design and evolution of software [11].
4.3.3 Expectations
The proposed aid has the advantages of being graphical and a one-page like summary, shows the evolution against a time dimension, and allows for specifics to be displayed and communicated.
Table 3 lists those root causes this diagram is intended to address, to what degree, and why.
48

Table 3 Evolution Diagram Expectations
Category Cause
Scope / Focus Too short-term focused
Too platform-focused
Expected
Improvement
(H, L)
H
H
H
Rationale
1. The diagram is intended to show evolution of function and form over multiple phases or time periods. Prior to this, organizations may have documented only the specific tasks for the next release, with no description of desired state or how function and form would be evolved over time on the path to that desired state.
2. The diagram is intended to represent the evolution of function and form across all relevant platforms and the products they support.
See 2.
Work
Products
Too (project) product- focused
Partial / Absent
Not usable
L
H
Resources
Doesn't communicate intent
Unclear allocations
Not cross-platform /
product
Doesn't accommodate asynchronicity
Duplication of effort
H
L
H
L
L
See 1. This diagram fills a particular void.
3. The diagram is intended to be one-page, graphical and intuitive. The actual diagram for the target organization comes with a "backup" one page textual description of how to interpret the diagram (for first time users and to explain acronyms). This is advantageous compared to countless pages of text buried in a one or more specification or strategy documents, which are unlikely to be read or later referenced.
See 1. With a clear picture of where the organization would like function and form to evolve, engineers can make near-term trade-offs without compromising the ability to introduce or retire function and form in the long-term, per the desired state.
See 2. The column headings and/or "specifics" in the diagram are intended to convey information regarding allocation of function or form or responsibility. For example, in the target organization the diagram indicates through the column headers how the form of job submission will evolve for each platform that supports that functionality. But allocation is not always explicit.
See 2. The work product itself is cross-platform and cross-product in scope.
See 1 and 2. The overlap in function or form conveys both a general transition period as well as a phased introduction or retirement across asynchronous platforms. But the diagram is intentionally vague, leaving the details to more schedule-oriented aids.
See 2. The diagram can be used to show convergence of alternative forms into a single one; e.g., the convergence from multiple to a single protocol. The chart doesn't make explicit the responsibility for particular form through its lifecycle, however.
49

4.3.4 Within the Target Organization
Prior to the introduction of the proposed aid, evolution of function and form within the target organization was covered at only a very high level of detail or not at all. What was documented was not widely communicated or used within the engineering organization, and was not at a sufficient level of detail for platform teams to know exactly what function or form was to be implemented. These documents typically did not have timeframes associated with the evolution of function and form, particularly in regards to a transition and the retirement of function or form.
To improve this situation, an Evolution Diagram was introduced into the target organization for
Job Submission, Status, and Programming (JSSP) function and form (Figure 17). This diagram was developed and distributed in the target organization as part of a strategy document for all
JSSP function and form. The diagram includes only those items relevant to JSSP, and focuses more on form (e.g., applications, protocols, format).
50

im /0Ph
Current
1 9XX
0 0
.0)
0i
0
C
W o.
I
Proprietary-JT-2
Proprietary-JT-1 a)
~~
Subm via ProreayPoo1~~
;- c
0
-
Subm: via Proprietary-Proto-1 cc................................
20M
C
Status: via Proprietary-Proto-2
U) Subm: via Proprietary-Proto-1Sumtau:vapePro-
0) cwo
I
Proprietaryj API 2
..
Proprietary API-2 um: via legacy std proto
Subm/Status: Open Proto 1
'.
Open-JT-1
SumStus: via Open-Proto-1
Open-API-1
Subm/Status: via Open-Proto-1

An explanation of the different items of this diagram follows:
Time / Phases The time scale on the right hand side of the diagram communicates the intent to phase in new technologies (protocols, API's and formats) and phase out old ones over some period. The diagram does not list specific dates, but rather talks to phases. In this particular case, a major transition is intended to occur at phase 1, where new protocols, API's and job ticket formats will begin to appear. Legacy forms are expected to continue one for some time due to their use in existing installed products and customer investment in them. The diagram also indicates the possibility of some intermediate phases (the "T' marks). Thus, the diagram communicates an overall intent without getting hung up on specific release dates that are subject to negotiation and change. Specific release dates are best captured in a planning tool presented elsewhere.
3rd Party Apps 3rd party applications are those software components generated by customers or system integrators that enable the target organizations products to work within a larger super-system. These applications are generated to enable a custom solution or shield the rest of the system from the particulars of a vendor's product. The diagram indicates that
3 rd pay submission applications currently use legacy industry standard protocols
(Subm: via legacy std proto). These protocols are older and limit the level of functionality that can be achieved. For example, job status functionality is not currently possible. The diagram indicates that the intent is to introduce a new industry standard protocol (Open-Proto-1).
This protocol is more comprehensive and will allow both submission and status functionality (Subm/Status). The widths of the two triangles also indicates significance; i.e., that the newer more comprehensive protocol will enable more feature rich 3d party applications.
API's There are currently two different proprietary application programmer interfaces (API's) published for use by customers and/or used by products and platforms (Proprietary API-I and API-2). Not all products or platforms support both API's. The diagram indicates intent to move away from several incompatible proprietary API's to a single one based on an industry standard (Open-API-1). The advantages are that the organization need not maintain several similar but competing mechanisms, and that the use of an industry standard-based mechanism could enable interoperability with other components that support the same industry standard. The widths of the triangles communicate significance in terms of the level of functionality that is available through the different API's. In this case,
Proprietary API-2 is very limited. The newer Open-API-I the organization is transitioning to is much more comprehensive and will enable more feature rich communication.
52

Scan Station The Scan Station platform offers both submission and status functionality
(Subm, Status). Submission is accomplished through the use of one proprietary protocol (Proprietary-Proto-1) and status through another
(Proprietary-Proto-2). This is a situation that had evolved haphazardly over time as product and platform teams implemented functionality with whatever means they could. The diagram indicates an intent to preserve the functionality currently offered by Scan Station, but to do so over a single industry standard protocol (Subm/Status: via Open-Proto-1). The width of the lower triangle relative to the others indicates that the level of functionality is expected to surpass that which was possible in the past.
Proprietary Subm/Status App
Proprietary submission and status applications are standalone applications offered with the Client platform. Proprietary applications are provided when standard or commercial-off-the-shelf (COTS) applications, typically bundled with a particular operating system (e.g., Microsoft@ Windows@), do not offer the full functionality possible and desired for the target organization's products. The diagram indicates that only submission functionality implemented over a proprietary protocol has been possible
(Subm: via Proprietary-Proto-1). The intent is to move to the use of an industry standard-based protocol that will allow the organization to offer both submission and status functionality (Subm/Status: via Open-Proto-1).
Proprietary Print Drivers
Proprietary print drivers, part of the Client platform, are custom print drivers typically not bundled with a particular operating system.
Proprietary print drivers are necessary when the standard or COTS print drivers do not support access to the full job programming capabilities of the target organization's printers. When installed on an operating system, the proprietary print driver supports the normal printing experience from within a document creation application (e.g., Microsoft@ Word®), but with full job programming functionality. The underlying operating system may impose further constraints on print driver vendors regarding access and use of particular protocols or limited operational models on how the application can interact with the user. This in turn may limit the level of functionality the driver can offer, and in this case, it currently only offers submission functionality. The diagram indicates that proprietary print drivers currently achieve their submission functionality through the use of a proprietary protocol (Subm: Proprietary-Proto-1). The intent is to move to the use of an industry standard-based protocol (Open-Proto-1).
Legacy Products / Components
Legacy products and components refer to those products and components developed prior to the use of platform-based product development. The legacy products are still maintained and in use by customers, but there is no intent to enhance them further. A holistic view requires that we
53

Job Ticket Formats consider interoperability requirements and transitions for these legacy products. The diagram indicates the intent that these legacy products will not be updated, and will continue to implement job submission functionality through the use of a proprietary protocol (Subm: Proprietary-
Proto-1). Relevant platforms such as the DFE will maintain support for this form for the foreseeable future, although the diagram indicates intent of phasing out this form sometime around phase 2.
Job ticket is the term describing the form used to represent the comprehensive set of job programming instructions; i.e., how the user would like their job processed, finished, accounted for and delivered. Job tickets follow a defined format, whether they be saved to disk file or communicated over a network. Client platform applications, for example, allow a user to define a complicated set of job programming and then save that programming to a disk file for subsequent use. The diagram indicates that there are two job ticket formats in use by platforms and products
(Proprietary JT-1 and JT-2). One format is used for disk files by the
Client and Scan Station platforms, and the other for saving job information at the DFE platform. The intent is to move towards the use of a single job ticket format based on an industry standard-based encoding (Open-JT-1) that can be used for both disk files and network protocols by all platforms.
Proprietary Extensions to Std Protocols
In some cases, proprietary extensions have been made to legacy industry standard protocols to overcome their limitations and offer more functionality. For example, the "lpr" and "lp" standard submission applications first popularized on UnixTM systems but now available on other operating systems, offered limited job programming; i.e., job title, copy count, banner page message. The "lp" application supported printer specific job programming via the "-o" option. These extensions are not standardized across vendors, and as it turns out, were not even standard within the target organization as they had evolved haphazardly from the efforts of multiple independent product development activities prior to the introduction of platforms. The diagram indicates an intent to suspend further extensions to these legacy protocols, whose time is limited anyway, and to instead concentrate on a newer industry standard protocol that more formally supports printer specific extensions for both job programming, submission and status (Subm/Status: Open-Proto-1).
Since the proposed aid builds off an existing method, we begin this section with a discussion of the other methods.
There is prior work regarding strategic planning of product portfolios [3] [4] [5] [9]. Most of what they present is at a strategic level, and doesn't get into the details of actually mapping and tracking multiple platforms to multiple products.
54

Jandourek presents a Platform Development Model [7]. For the purposes of this thesis, only the
Product Portfolio Planning portion of his model is relevant. Among other things, portfolio planning defines the product and platform versions to be developed and released over time, and the relationship between them. Two particular items of interest are the Product Vintage Chart and the Platform Lineage Chart.
In this section, simplistic examples will be used for illustration. The following conventions apply here only, and are not intended to represent the situation in the target organization.
A..Z Products are denoted with capital letters; e.g., 'A' is a different, perhaps similar, product than 'B'.
a..z Platforms are denoted with lowercase letters; e.g., 'x' is a different platform than
'y', but may be used in conjunction with each other to form a product 'C'.
.v# Versions of either a product or platform are denoted by a '.v#' suffix, where '#' indicates the version number; e.g., 'A.vl' represents version 1 of product 'A',
'x.v2' represents version 2 of platform 'x', etc. Note that version and release are used interchangeably.
F# Features are denoted with an 'F', and '#' is a unique number used for reference and tracking purposes.
Products are comprised of platforms as defined below:
A = {x, y, z}
B = {x, y}
C = {x, z}
The Product Vintage Chart is part of an overall business plan, and shows the target releases of various products over time. An example Product Vintage Chart from Jandourek's model is shown in Figure 18.
Figure 18 Product Vintage Chart
Product Line
(perhaps aligned to target markets)
A
B
C
Q1
Product Releases
A.v1
B.v1
Q2
199X
Q3
A.v2
B.v2
C.v1
Q4 Q1
Release Timeframes
B.v3
Q2
199X
Q3
A.v3
C.v2
Q4
55

A Platform Lineage Chart (Figure 19) supplements the vintage chart, and shows the hereditary relationships between products and platforms.
Platform
Origi*
Figure 19 Platform Lineage Chart x.v0
Platform.
PVersions x.vl x.v2 x.v3
Products
A.vl
B.vl
A.v2 A.v3
B.v2 B.v3
C.vl I C.v2
4.4.2 Proposed Product/Platform Chart
In a multi-platform environment, however, there are many platform lineage charts as depicted in
Figure 20. While individual lineage charts may be useful from a platform perspective (i.e., allows an individual platform development team to keep themselves grounded and aware of relevant products), they are not conducive for a system or cross-platform/cross-product perspective (i.e., it's cumbersome and difficult to see how relevant platforms apply).
Figure 20 Multiple Platform Lineage Charts z.v0
y.VO
Platform
Origir
Platforms y.V1 z.Vl
~ y.v2 yP. 3 z.v2
~ --
Platform
S Versions x-V x.v2 x.03 Av2
A.v2
C.v2
Products
A vl
B.vl B.v2
A.03
+
B.v3
C.vl L C.v2
The proposed aid, the Product/Platform Chart (Figure 21), is a hybrid between the vintage and lineage charts. This chart doesn't describe platform-level lineage. In some cases, platform lineage is relatively simple (i.e., single origin, one release simply building on the previous) making them unnecessary. Otherwise, platform lineage can be maintained separately via the traditional platform lineage charts.
56

Products
Figure 21 - Product/Platform Chart
Relea:ss piMforms)
.
| 01
A
02
A.v
X x.v1
Other zI te
-- z.v1
199X
03
B
X
B.v1 x.V1 v2 Y ~ z
COtherCAA x
.2 _.v3
-.
04 x.v2
Az
OtherM
.V1
199X
Q1 02 03 04
A.v2 x.v2
-
1
-
A.v3
x.v3
z.V2
B.v2 x.v2 y.v3
B.v3
x.v3
v.v4
-z.v2
y.v4
x v3
X
E Z x.V1
Y.v1
Z.V1 y.v2 x.v2 y.v3 zAv2 x.v3
y.v4
The lower portion of the chart indicates target platform releases. The upper portion of the chart indicates target product releases. Beneath each product release, the relevant platforms that will make up that product release are listed; i.e., the platform releases that are or have been released
by that timeframe. Shaded rows indicate that the platform is not applicable to that product configuration. For example, product A-release-2 is comprised of platforms x-release-2, y- release-3, and z-release-2; platform x-release-2 was developed and released prior to this particular product.
Optionally, one may wish to show the dependence of the product on a non-platform or thirdparty component. For example, if a product is going to use a 3rd party developed "client software" component in place of the internally developed platform counterpart, the row could be relabeled "Other -
3 rd party Client".
4.4.3 Expectations
The advantage of this chart is that it provides an integrated view of all Product and Platform deliverables across the organization. It avoids the product-specific or platform-specific myopic view that sometimes takes hold in an organization. It also serves as a great quick-glance aid for keeping track of product and platform relationships and release targets, and acts as a historical record. Table 4 lists those root causes this chart is intended to address, to what degree, and why.
57

Table 4 Product/Platform Chart Expectations
Category Cause
Scope / Focus Too short-term focused
Work
Products
Too platform-focused
Too (project) product- focused
Partial / Absent
Not usable
Expected
Improvement
(H, L)
L
H
H
L
H
H
Rationale
1. The diagram is intended to show a multi-year plan. The chart used in the target organization, for example, displays four years.
2. The chart is intended to display all products and all platforms that comprise them. It provides an integrated view.
See 2. The integrated view makes potential crossproduct issues more visible. For example, the organization can see what demands are being placed on their platform teams, or to assess the implications of schedule slip of a particular platform on relevant products.
See 2. This chart fills a particular void.
3. The chart is intended to be graphical, intuitive, and easily referenced; the grid structure is useful for increasing clarity in human information processing [12]. The integrated view is more usable than continually and manually integrating information from individual sources.
See 1 and 2.
Doesn't communicate intent
Unclear allocations L
Not cross-platform / product
Doesn't accommodate asynchronicity
H
H
See 2. Allocation, to the level of which platforms will comprise which products, is clearly visible.
The chart is not intended to show more detailed allocations of function and form, however.
See 2. The chart is cross-platform and crossproduct in scope.
See 1 and 2. The chart makes clearly visible the asynchronous releases of platforms and products, and shows which platform releases a product will pick up based on the desired product launch date.
4.4.4 Within the Target Organization
Prior to the pilot, the organization maintained product plans at only a high level of detail. The plans depicted launch targets for products in the various product lines. The plans were developed and communicated primarily within the product business teams, and didn't necessarily show an integrated view across product lines and market segments. Informal integration of the various product line plans occurred within the engineering organization as platform teams reconciled the many project requests and deliverables.
To improve the situation, a Product/Platform Chart was introduced in the target organization
(Figure 22). This chart was developed and distributed by the system engineering group in the target organization using inputs from product business and platform engineering teams. Note the actual chart used in the target organization maintains a four year view (here a three year view is used) and lists each legacy product separately (here they are all lumped under product G). As
58

explained previously, this chart shows the relationship between product releases and the releases of the platforms comprising those products. The shading is used to show non-applicability of platforms to products.
For example, Product A release 1.1 is planned for QI of the second year. As is typical, this is a follow-up release (1.1) intended to offer incremental improvement over the first, major feature release (1.0). It will launch with the latest versions of the requisite platforms at that time; i.e.,
Client release 2.3, DWS release 3.0 and DFE release 2.0. Due to the nature of platform-based products, as can be inferred from the chart, product A can see a potential benefit in the form of additional feature content being introduced in DFE release 2.0 for product C; this might encourage product A's business team to pay closer and prior attention to product C.
59

Figure 22 Product/Platform Chart for Pilot
S199X
Q1
A
Client
A-1.0 c-2.2
ScanStation
DiagWS dws-2.0
Sere
DFE dfe-1.0
B
Client
ScanStation
DiagWS
Sene
DFE
C
Client
I
ScanStation
DiagWSI
Snr
DFEj
D
Client
I-1.
ScanStation
DiagWS
Sene
DFE
E
Client
ScanStation
I
DiagWSo
DFE
IF
Clienti
ScanStationj
DiagWS
Se~er
DFE
G
Clientl
ScanStationj
DiagWSI
Senverl
DFE
Clioent (c)
ScanStation (as)
Dia WS (dws)
Server ()s-2.0
DIFE (dfe) dws-2.0
02 c-2.2
Q3
I
B-2.0 c-2.2 ss-1.0 dws-2.0 dfe-1.0
I
Q4
F-2. ss-2.01
G-2.0 s-2.01
01
A-1.1 c-2.3 dws-3.0 dfe-2.0
I C-1.0 c-2.3 dws-3.01 dfe-2.0
I-I.0
Q2
199X
F-21I ss-2.1184.
c-2.3 ss-2.0 dws-3.0 dfe-2.0'- c-2.4 ss-2.1
03
B-2.1 c-2.4 ss-2.1 dws-3.0 dfe-F-3.0
G-3.0 s-3.01 s-3.0
Q4
Key
Applicable, included in that product
Not applicable, not included in the product
01
A-2.0
c-3.0
dws-4.
dfe-3.0
C-1.1
c-3.0
dws-4,0 de-.
dws-.
dfe-3.0
c-3.0
dws-4.0
dfe-3.0
G.
Q2 s-.
s-4.0
199X
.''
Q3
B-3.0
c-3.0
ss-3.0
dws-4.0
E-1.0
c-3.0
ss-3.0
dws-4.0
F-3.0
ss-3.0
60

There is the matter of tracking individual function or form applicable to multiple platforms and desired by one or more products for particular product releases; in particular when portions of that function or form may become available at different times due to the asynchronicity of the platforms' schedules or due to constraints (technology, resource, architectural, 3rd party, etc.) specific to each platform. Of course we also want to display the retirement of older function and form.
The proposed aid, a Feature/Platform chart (Figure 23), can be used to map and track function or form to platforms against desired timeframes.
61

Figure 23 Proposed Feature/Platform Chart
Function or
Form (and applicable platfoms)
F1
X
Q1
199X
02
AMv x.v1
Y.v1
03
Releases
04 01 02
199X
03 04
F2
Othr
B.v1
z
0ther
F3 z z x1 z x.v3j
zI
Other
Platforms x
Y z
Key x.v1
.v1 z.v1 y.v2 x.v2 y.v3 z.v2
x.v3
y.v4
Applicable, available, supported and/or utilized
Not applicable, available, or supported (discontinued)
. .|. Supported but no updates intended; in a maintenance mode and being phased out z.v2j
Product Releases correspond to the Product's target Launch date. Under each Function/Form, the
Platforms to which it is applicable are indicated. "Other" indicates impact to some other entity of interest; e.g., "Other Architecture" could indicate that there is some architecture or design work that must be done, such as updates to an interface spec.
The function/form "release" is determined by the release dates of the products the item applies to. In the example presented, only the first product to which it is applicable is listed. One could list the additional product releases to which the item is applicable, but if one assumes that items are generally common across all products, this data would be unnecessary. Beneath the first product release for that item are the applicable platform releases; i.e., those platforms to which the item is allocated, and for which the platform must develop some portion of the item. Shaded rows indicate that the item is not allocated to that particular platform, that the function/form has entered a maintenance mode and no further updates are expected, or that the function/form has been retired and is no longer available.
62

For example, item F3 is being introduced and is targeted for product C-release-2 (and presumably any other products at or after that point in time). The feature spans platforms 'x' and
'z', and the implementation of their portions of the feature is targeted for releases 3 and 2 respectively. Feature F2 is being retired. It is in maintenance mode up until product B-release-1 at which time the function or form will no longer be available.
4.5.2 Advantages Compared To Other Methods
Traditional methods for showing these mappings and schedule include Quality Function
Deployment (QFD) [13] or Gantt charts. QFD matrices typically begin by showing a mapping between function and form (design or implementation). Subsequent matrices can be used to show other mappings such as design to implementation. One could use a QFD matrix to show a mapping between function or form and applicable platforms. But QFD matrices do not include time or release information.
Gantt charts and similar scheduling techniques are commonly used to show activities against time and can include the names of relevant resources for those activities. One could use a Gantt chart to show the introduction of function or form including the names of the applicable platforms. But it would be an awkward use of Gantt charts to show the retirement of older function or form.
4.5.3 Expectations
The advantage of the Feature/Platform Chart is that it takes more abstract directions and intents and clearly indicates product and platform releases; i.e., who is to deliver what and when. It offers more of a realistic project planning perspective to complement the technical and ideal views presented by the Evolution Diagram. Table 5 lists those root causes this diagram is intended to address, to what degree, and why.
63

Table 5 Feature/Platform Chart Expectations
Category
Work
Products
Resources
Cause
Scope / Focus Too short-term focused
Too platform-focused
Too (project) product- focused
Insufficient detail
Partial / Absent
Not usable
Doesn't communicate intent
Unclear allocations
Not cross-platform / product
Doesn't accommodate asynchronicity
Duplication of effort
Expected
Improvement
(H, L)
H
H
H
L
L
H
H
H
H
H
L
Rationale
1. The chart is intended to show a multi-year plan.
The chart used in the target organization, for example, displays four years.
2. The chart is intended to display all platforms impacted by the evolution of function or form, and the lead product first affected. It provides crossplatform view.
See 2. The chart is intended to speak to function and form across all products and platforms. Lead products are listed only to show which is first affected.
3. The chart is intended to enumerate detailed function or form items that would be useful for product business team members down to platformlevel architects and designers. It is not intended to replace more detailed and verbose specifications, however.
See 2. This chart fills a particular void.
4. The chart is intended to be graphical, intuitive, and easily referenced; the grid structure is useful for increasing clarity in human information processing [12]. The integrated view is more usable than continually and manually integrated information from individual sources. Items in this chart can correlate to columns or specifics in the
Evolution diagram.
See 1 and 2. The chart shows transition periods, as new function or form is introduced and older function and form is gradually replaced.
See 2. Allocation, to the level of which platforms will be impacted by evolution of function and form, is clearly visible.
See 2. The chart is cross-platform and crossproduct in scope.
See 1 and 2. The chart makes clearly visible the asynchronous releases of platforms, and shows when function or form becomes fully supported across platforms and which product will be the first affected.
See 2. Allocation, to the level of which platforms will be impacted by evolution of function and form, is clearly visible. Items can represent the consolidation of duplicated efforts into a single form. The chart doesn't make explicit the responsibility for particular form through its lifecycle, however.
64

4.5.4 Within the Target Organization
Prior to the introduction of the proposed aid, evolution of function and form within the target organization was covered in design and planning documents that were separate and distributed throughout the organization. No single piece of documentation presented an integrated view of the evolution of function and form across all platforms and products to the level of actual releases of each. This documentation did not always consider the transitions that needed to occur from legacy forms to newer ones. Specifications may have indicated the decision to move to a newer form, but didn't address when older forms would be retired (if at all).
To improve this situation, a Feature/Platform Chart was introduced in the target organization.
Figure 24 is an excerpt from the Feature/Platform Chart for Job Submission, Status, and
Programming (JSSP) function and form. This chart was developed and distributed in the target organization as part of a larger Feature/Platform Chart in a strategy document for all JSSP function and form. The diagram includes only those items relevant to JSSP, and focuses more on form (e.g., applications, protocols, formats) versus function. More specifically, it only addresses those items in the Evolution Diagram presented earlier. Note that "Before" and "Later" columns are used to communicate inherited situations or longer-term intentions; timeframes just beyond the horizons of this three year view.
The items are grouped in the following categories: API's, legacy and proprietary protocols, the newer protocol, and job ticket formats. As discussed earlier, shading is used to indicate the applicability or significance of function or form to platforms over time. Annotations within the chart are used to more clearly communicate specifics. Products indicate the primary product in which function or form is first introduced or begins a path of retirement. Hopefully the diagrams are intuitive, but the following are some highlights of specific examples:
API's Although internal software development may rely on API's, the emphasis here is on the publication of API's for use by external parties such as endcustomers or system integrators. In that sense, these forms are not applicable to the platforms. There is impact, however, to the design group chartered with the definition and management of API's, as indicated by
"Other Design group". The diagram indicates that for the older proprietary API's (Proprietary-API-I and -2), the design group is the party responsible for preventing further extensions to these legacy API's. They will also lead and coordinate the definition of a newer API (Open-API- 1) for use by customers and/or platforms.
Legacy Standard protocols
The use of legacy industry standard protocols will not disappear overnight.
Their advantages come from their familiarity, ubiquity and (in some cases) simplicity. It is expected, however, that a transition period begins in Q3 of the second year, when the Server will speak legacy protocols only to legacy products. Later, customers will begin the transition to a newer and more feature-rich alternative. As Q1 of the third year, the DFE will
65

continue support of these legacy protocols for the foreseeable future as customers make that transition or until legacy products (which will not be upgraded to the use of newer protocols) are retired.
Legacy Proprietary protocols
There are several legacy proprietary protocols in use between platforms today, one for submission and one for status functionality (Proprietary-
Proto-1 and -2, respectively). Beginning in Q1 of the third year for the
Client platform and Q3 of the third year for the Scan Station platform, these protocols will be used only as necessary to speak with legacy products (e.g., older printers in the field that will not be upgraded to speak a newer protocol). The DFE will continue to support the legacy proprietary protocols, but without extending it beyond what functionality it supports today and with the expectation that only legacy client-side products will be using it. In Q3 of the third year, the Scan Station is expected to use the proprietary status protocol (Proprietary-Proto-2) only when communicating with legacy printer-side products.
New Open protocol A newer industry-standard based protocol (Open-Proto-1) will be introduced in QI of the third year, and the platforms will make use of it for both submission and status functionality. Product D release 1.0 is the first product to launch with this enhanced functionality and underlying implementation. Other products (G and E) can offer that functionality when the other platforms which comprise them (Server and Scan Station, respectively) have implemented it. The newer protocol more formally supports vendor-specific extensions, and the design group will take the lead and coordinate those extensions across the product and platform teams.
Job Ticket Formats There are two incompatible file formats used for job tickets by the Client,
Scan Station and DFE platforms. Beginning in QI of the third year for the
Client and DFE, and Q3 of the third year for the Scan Station, those platforms will move to the use of a newer more robust format (Open-JT-1) based on an industry standard encoding mechanism. Given that large repositories of job tickets may exist in the older formats, the platforms will continue to support the older formats but only for "read" operations. All new job tickets that are created (via "write" operation) will be in only the new format.
66

Function or Form
(and applicable platforms_
Before n/a
B-1.0 Proprietary-API-1
Client
ScanStation
Dia WS
Server
DFE
Other Desi n roup
Proprietary-API-2
Client
ScanStation
Dia WS
Server
DFFE
Other - Design group
H-1.0
Open-API-1
Client
ScanStation
Dia WS
Server
DIFEM
Other - Design group 111
01 02
199X
03
Figure 24 - Feature/Platform Chart for Pilot
04 01
C-1.0
Releases
02
1 99X
03
Platforms (Code)
Client LC C-1.0
ScanStation (ss) ss-1.0
DiagWS (dws) dws-1 .0 dws-2.0
Server (sl s-1.0
DIFE (dfe)l dfe-1 .0 c-2.2
Key c-2.3 ss-2.0 s-2.0 dws-3.0
Platform Releases c-2.4 ss-2.1 s-3.0 dfe-2.0 i
Applicable, available, supported and/or utilized
Not applicable, available, or supported (discontinued)
Supported but no updates intended; in a maintenance mode and being phased out
I
04
D-1.0
lIead
01 02
1 99X definition/deliver of
03
API c-3.0
dws-4.0
I.
I dfe-3.0 I s-4.0ss-3.0
04
Later n/a

Figure 24 (cont.)
-
Feature/Platform Chart for Pilot
Function or
Form
(and applicable platforma) Before n/a
Subm/Status: via legacy std proto'a
Client
ScanStation
Dia WS
Server
DFE
Other Custome
Subm/Status:
Proprietary
Extensions to legacy std proto's
Client
ScanStation
Dia WS
DFE
Other
SubmP : via
Proprietary-Proto-1
B-1.0
B-1.0
ScanStation
Dia WS
Server
01 02
199X
03 Q4 01
I
C-1.0
Releases
199X
02 1 03 1 04
G-3.0
01
D-1.0
D-1.0
02
199X
Later
[
03 04 1 n/a
F-3.0
I
I
I
Proprietary-Proto-2
F-3.0
DFE
Other
Platforms (Code)
Client (c) c-1.0
ScanStation (ss) ss-1.0
DiagWS (dws) dws-1.0 dws-2.0
Server (s) s-1.0
DFE (dfe) dfe-1.0
Key c-2.2 c-2.3 ss-2.0 s-2.0 dws-3.0 dfe-2.0
Platform Releases c-2.4 ss-2.1 s-3.0
Applicable, available, supported and/or utilized
Not applicable, available, or supported (discontinued)
Supported but no updates intended; in a maintenance mode and being phased out c-3.0
dws-4.0
dfe-3.0
s-4.0
ss-3.0

Figure 24 (cont.) - Feature/Platform Chart for Pilot
Function or Form
(and applicable platforms)
Subm/Status:
Extensions to Open-
Proto-1
Client
ScanStation
Dia WS
Server
DFE
Other - Design Orc
Subm: via Open-
Proto-1
Client
ScanStation
Dia WS
Server
DFE
Other
Status: via Open-
Proto-1
Client
ScanStation
DiagWSq
Serveris-4.n
DFE
OtherM
Before n/a 01 aib nd
02
199X
03 04 01
Releases
02
199X
03
Platforms (Code)
Client cq c-1.0
ScanStation (ss) ss-1.0
DiagWS (dws) dws-1.0 dws-2.0
Server si s-1.0
DFE (dfe) _ dfe-1.0
Key c-2.2 c-2.3 ss-2.0 s-2.0 dws-3.0
Platform Releases c-2.4 ss-2.1 s-3.0 dfe-2.0
Applicable, available, supported and/or utilized
Not applicable, available, or supported (discontinued)
Supported but no updates intended; in a maintenance mode and being phased out
04 01 02
199X
03
D-1.0 G-4.0 E-1.0
F-3.0
c-3.0
s-3.0
s-4.0
dfe-3.0
coordinate extensions definition
D10
-. c-3.0
G40
G40
E-1.0
F-3.0
ss-3.0
s-4.0
dfe-3.0
04
D10
-.
G40
0
G4 c-3.0
E-1.0
F-3.0
ss-3.0
fie -3. 0 c-3.0
dws-4.0
dfe-3.0
s-4.0
ss-3.0
Later n/a

Function
(and or Form applicable platforms)
Before n/a
JT: Proprietary-JT-1 B-1.0
Clienti
ScanStation
Dia WS
Server
DFE
Other
JT: Proprietary-JT-2 B-1.0
Client
ScanStation
DiagWS
Server
DFE
Other
JT: Open-JT-1
Client
ScanStation
Dia WS
Server
DF
Othe
01 02
199X
03
Figure 24 (cont.) - Feature/Platform Chart for Pilot
04 01
Releases
Q2
199X
03
Platforms (Code)
Client (c) c-1.0
ScanStation (ss) ss-1.0
DiagWS (dws) dws-1.0 dws-2.0
Server (sl s-1.0
DFE (dfe)l dfe-1.0
Key c-2.2 c-2.3 ss-2.0 s-2.0 dws-3.0
Platform Releases c-2.4 ss-2.1 dfe-2.0 s-3.0
Applicable, available, supported and/or utilizec
Not applicable, available, or supported (discontinued:
Supported but no updates intended; in a maintenance mode and being phased ou
Q4
Q1
D-1.0
-.
D-1.0 c-3.0
dfe-3.01
c-3.0
dws-4.0
dfe-3.0
02
199X
03
F-3.0
s-4.0
E-1.0
F-3.0
ss-3.0
ss-3.0
04
Later n/a

Perceived effectivness was measured through a survey of the participants. Participants were asked to fill in a matrix mapping proposed aids to the set of root causes. Participants filled in each cell with one of the following values:
H The proposed aid will significantly improve on the problem
-
L The proposed aid will have some improvement on the problem
The proposed aid will make the problem worse
<blank> The proposed aid will have no effect
Participants did not rate those combinations that were deemed not applicable in the study; e.g., impact of proposed aids on process problems. The anticipated results were not shared with the participants so as to preserve their objectivity.
Only one participant felt that the proposed aids made a few things worse. Despite being more critical, that participants'responses were not so far out of line or extreme to justify removing his data from the sample. Nor did these extreme ratings significantly sway the overall rating.
The radar charts in Figures 25 through 28 indicate the percentage of participants rating the aid at a degree meeting or exceeding expectations and the expected rating is shown in parenthesis next to each root cause. For detailed data, refer to Appendix C.
71

Figure 25 - Percent Meeting or Exceeding Expections for Influence Diagram
(H/L)
Poor inputs
(L)
(H)
Non-holistic view
75*/ Too sh ort-term focused
(L)
Not cross-platform/-pro duct
(H)
0
Too platform -focused
(L)
Not usable
(H)
Too (p roject) product-focused
(L)
Partial / Absent
(L)
Figure 26 - Percent Meeting or Exceeding Expections for Evolution Diagram
(H/L)
(H)
Too short-term focused
100%
Duplication of effort
(L)
75%
Too platform-focused
(H)
Doesn't accommodate asynchronicity
(L)
Too (project) product-focused
(H)
Not cross-platform/-product
(H)
Unclear allocations
(L)
Doesn't communicate intent
(H)
Not usable
(H)
Partial / Absent
(L)
72

Figure 27 - Percent Meeting or Exceeding Expections for Product/Platform Chart
(H/L)
Doesn't accommodate asynchronicity
(H)
(L)
Too short-term focused
100*/
750/
5
Not cross-platform/-product
(H)
Too platform-focused
(H)
Too (project) product-focused
(H)
Unclear allocations
(L)
Doesn't communicate intent
(H)
Not usable
(H)
Partial / Absent
(L)
Figure 28 Percent Meeting or Exceeding Expections for Feature/Platform Chart
(HIL)
Duplication of effort,
(L)
(H)
Too short-term focused
100%
75%-
Too platform-focused
(H)
Doesn't accommodate asynchronicity
(H)
Too (project) product-focused
(H)
Not cross-platform/-product
(H)
Unclear allocations
(H)
Doesnt communicate intent
(H)
Insufficient detail
(L)
Not usable
(H)
Partial / Absent
(L)
73

5.1.1 Expectations Not Met
Of interest are those cases where less than 50% of the participants rated the aid at or exceeding expectations. Expectations aside, across all aids the favorable ratings for those root causes where some improvement was expected (the combination of both "H" and "L") ranged from 55% to
90%, with only one item scoring 55%. This indicates that participants did see the aids as some degree of improvement, just not to the degree expected. The following is an attempt to explain some of those results.
Not usable Between 18% and 27% of the participants rated this "H", and between
36% and 55% rated it "L". Some of the criticisms were that the
Influences Diagram didn't indicate how the influences affect the function or form. The Evolution Diagram was oriented awkwardly. One participant from a platform team commented that Product/Platform Chart is too difficult to understand quickly. He ends up keeping his own version, which interestingly, lists only products and their releases and no platform information. The generic Product Vintage Chart on which this proposed aid is based would provide just that information. Another participant indicated that the Feature/Platform Chart was "too busy". Nobody thought the information in either chart was unnecessary, however. In fact, most indicated that they required seeing the content and release information for other platforms with which their platform interacts. Thus the challenge is to effectively communicate both product and platform release information.
Another criticism is that although the diagrams can be powerful, more education is needed with them. Participants were unfamiliar with the diagrams and their purpose. While it is not clear whether participants read the one-page textual description that accompanied some of the diagrams, I think the point is that newer aids in particular may initially require a "road show" or one-on-one sessions to help familiarize individuals with the aid's scope and purpose. A new aid can not be dumped into the organization with the expectation that everyone will understand it just by reading it alone.
Not cross-platform/-product
Between 9% and 45% of the participants rated this "H", and between 27% and 64% rated it "L". It is not obvious from viewing some diagrams that the aids are taking a cross-product perspective, although that is the intent for their use. My interpretation is that participants felt the aids did not actively coordinate or reconcile cross-platform and cross-product tensions so as to deserve a higher rating.
Too platform-focused
The Evolution Diagram, where expectations were least met, happened to deal mainly with form of interest to the Client and Scan Station platforms, so one might hypothesize that participants from other platforms felt the diagram was too platform-specific. But the data indicates that members
74

from the other platforms rated it equal or better than their counterparts from the Client and Scan Station platforms.
Unclear allocations A criticism and explanation for this lower than expected rating on the
Feature/Platform Chart is that allocations of functionality to platforms is really not known until further along in the software development lifecycle, and the proposed aids appear much earlier in the lifecycle. For example, detailed allocations are not known until requirements analysis and systemlevel design. Thus the proposed aids were seen at best having only an "L" impact.
5.1.2 Expectations Exceeded
Expectations were exceeded in some cases; i.e., participants felt the proposed aids would be an improvement against seemingly unrelated causes. The Influences Diagram received a 63% favorable rating (all "L") for the issues of "insufficient staffing" and "inadequate skill sets".
When asked why, one participant stated that the diagram helped make visible (to those in control of the funding) all the impending work that surrounded them. Platform teams need to work the immediate tasks, but also need to stay abreast of industry and technology trends, supplier relationships, etc. The list of upcoming technologies also pointed out the need to build or acquire the skills to respond to them. The Product/Platform Chart received a 73% favorable rating (all "L") for the same two issues, again, because it helped identify for product business teams the "many masters" that the platform teams were struggling to support. Product business teams often had a myopic view of their own product program, and didn't necessarily appreciate the trade-offs that sometimes had to occur at the platform level and resulting impact to multiple product programs.
The Evolution Diagram received a 73% favorable rating (evenly split between "H" and "L") for the issue of "insufficient detail". Prior to the pilot, there was little documentation that directly discussed specific forms (e.g., protocols, file formats) across platforms and products, and a rough timeline for the introduction and retirement of such form.
5.1.3 How The Aids Were Used
Participants were asked how they use the proposed aids, and what general improvements they felt the aids provided. The overwhelming response was that the aids were used and seen as great communication vehicles of planning and (somewhat high level) technical information.
Influence Diagram This was seen as an aid in communicating technical context. Business team participants indicated that while it didn't directly influence their business decisions it did serve as a technical "back drop". It could also help business teams understand why certain technical directions are taken or why certain trade-offs are made. Several platform participants indicated it would be useful way to communicate context to new hires or to bring other people up to speed.
Evolution Diagram This was seen as a good communication vehicle. Several participants had distributed it to other members of their team to help them understand the new forms of protocols and file formats that the platforms were moving
75

towards. They also commented that the diagram was a good start towards documenting and communicating the transitions from one form to another.
Product/Platform Chart
The overwhelming response was that Product/Platform Chart was seen as a great communication vehicle of planning information. The
Product/Platform Chart helped the participants see the "big picture" of what was expected and when, and also served as a historical record against which future projections could be made. The chart was distributed amongst their teams, and some even pinned it to their office wall. Another participant indicated that this and other aids ought to be made into posters for prominent display.
Feature/Platform Chart
This was seen as good communication vehicle of planning and technical information. In particular, it communicated the evolution of function and form against specific scheduled releases. This aid was the least used, least familiar and perhaps the most overwhelming to participants, however.
In general and on the bright side, participants felt the aids offered some degree of improvement, and against a larger set of the root causes than anticipated. In cases where a "H" degree of improvement was expected, however, few of the aids surpassed a 50% threshold, where the threshold is the percentage of participants rating the degree of improvement at or exceeding the
"H" expectation. This suggests several possibilities.
First, the proposed aids may have simply been poor. They should have scored higher, but simply weren't designed well. There is some evidence that the aids could be improved. For example, the Feature/Platform Chart was seen as difficult to follow and the Evolution Diagram could be re-oriented allowing quicker "information pick up" [14]. The Influences Diagram was seen as
"fluff with little value" by some, while others felt it was a good "lay of the land" and even commented that it was something they would use with new hires to help them understand context. In addition, it was clear that the proposed aids were very different ways of presenting information from what participants had seen before, and there was a fair degree of unfamiliarity and hesitancy with them. This is not a trivial point or defensiveness on the part of the author.
Lloyd and Jankowski point out that diagram clarity decreases when information is presented in an unfamiliar format [12]. As participants suggested, any new aid requires some "hand holding" initially so people can become comfortable with its purpose and style. For example, a series of workshops could be conducted to educate and collect input on the proposed aids. Only one participant felt that the proposed aids made a few things worse, but this didn't significantly sway the overall rating.
Second, the proposed aids by themselves would not have great enough impact. Although the proposed aids offered improvement, they were not sufficient by themselves for participants to feel the situation would "greatly" improve. Other supporting work products would need to be improved in similar fashion, and issues and barriers would need to be addressed. For example,
76

although the proposed Product/Platform Chart is cross-product and cross-platform in scope, other work products such as requirements specifications would need to be improved as well. Also, issues regarding the funding model, incentives and decision process still support a myopic view
by the product business teams and make cross-product trade-off discussions difficult. This suggests that further work is needed to analyze the other root causes and propose processes and aids that fall more within the Management domain of the framework from Figure 10.
This study points out that the proposed aids alone, although believed by participants to be an improvement, are not sufficient in addressing the identified set of root causes that lead to ineffective systems development in a multi-platform environment. Additional actions, aids and other improvements are needed primarily in the Management domain. It was valuable to learn what participants considered the most significant root causes. The causes shown in Table 6 turned out to be the most frequently discussed concerns for participants.
Table 6 - Frequently Mentioned Root Causes
Category
Process
Cause
No cross-platform/-product coordination
Scope / Focus Too (project) product-focused
Organization Incentive misalignment
Funding model misalignment
These issues are very much related. At the corporate level in the firm there is a desire to move from a "box" (product) mentality to providing "systems" and "solutions". But it isn't clear how
"systems" are valued or measured, and the pressure, culture and measurement still focuses on launching "products". In addition, the incentives and funding model still drive a myopic view within the business teams. Each product business team has its own targets and money to fund development. There is no incentive or supporting process for the product business teams to coordinate amongst themselves, and funding of common activities within the platform (e.g., development of common features, testing, etc.) is a source of tension. Platform teams are left to reconcile the many prioritized sets of inputs, with no supporting process for making trade-offs.
As one participant put it, "the product business team with the most money usually wins" and sometimes small, easily developed features advocated by a minority program don't make it into the product. Note that these concerns were expressed by both platform and business team participants.
A process is needed to coordinate the prioritization and trade-off of features, schedules, synchronization, and issue resolution across products and platforms. This process must include participation from the relevant product business teams, platform teams, and system engineering.
At the time of this study, the target organization was just introducing a "system planning forum",
77

a biweekly meeting involving system engineering and representatives from the platform teams.
Product business teams were included on communications but did not attend. In general, participants felt this was a positive step. In addition, management issues such as incentive systems, funding models and culture must be addressed.
Was the absence of the other required changes in the target organization due to an oversight?
Were they not addressed because they are "hard", and effort was directed instead at only the simpler and more obvious changes? One wonders whether an established organization can make these types of changes all at once. More than likely, it was a conscious decision to evolve the organization, in much the same way that function and form must be evolved over a period of time.
This study also re-affirmed the notion that effective and efficient communication is a key goal.
Many of the participants commented that the aids would need to be simple and intuitive and require little time to process. No one is about to spend a lot of time trying to understand a chart or diagram, nor would they dig through a lot of textual documentation. This presents one of the primary challenges of the proposed aids. To do their jobs effectively, members of the target organization indicated a need for information such as schedule and content for all platforms and products, the intended transition from one form to another and over what time period, etc. This information is necessarily complex. Displaying all the details leads to an indigestible diagram.
Not displaying enough detail leads to a diagram considered "all fluff and no content". In general the proposed aids were deemed an improvement, and are doing a reasonable job at walking the tightrope between fluff and detail. But further improvement is possible.
Note that one should use caution in extending these findings and conclusions to other organizations or contexts, since the study is based on a single organization. In addition, the participants in this study were a relatively small percentage of the target organization's population, so there is a possibility that the views expressed are not representative of the organization as a whole.
Additional study and proposals could be made to address those root causes that were outside the scope of this study. Such work would want to consider additional root causes that participants identified beyond those presented to them in Table 1. Since these additional causes were not known in advance, they were not included in the study, and participants were not asked to rate them regarding their prevalence or whether the proposed aids addressed them in any way. Table
7 presents those additional causes that were identified by more than one participant, including a proposed bucketing of the cause per the Ishikawa "fishbone" diagram from Figure 8.
78

Category
Process
Organization
Technical
Cause
Partial / Absent
Instability
Table 7 Additional Root Causes
Insufficient architecture/design
Definitions / Clarifications
Processes to support effective systems development are not defined or are incomplete. For example, the target organization moved to platform-based product development from an organizational structure and technical perspective, but without putting the necessary processes in place.
Frequent changes in organization structure, management and other personnel means revisiting and re-establishing communication channels, relationships and agreements.
There are two parts to this issue. First, system and platform architectures are not capable of supporting the asynchronous release of portions of a system feature that spans multiple platforms. For example, suppose a product is now able to support in-line shrink-wrapping of a finished job. The bulk of support for the functionality lies in the DFE and IOT platforms. The Client and Scan Station platforms need to make that job programming option available in their user interfaces. Preferably, the Client and
Scan Station platforms, which may release earlier than the DFE and IOT, should not expose that functionality unless it is supported across all platforms in the system. Second, the architecture/design is not separable and most functionality ends up in the platform. Products have to incorporate the entire platform versus only those portions of the platform suited to that product's particular market. This in turn leads to a problem of increased testing load; every product must perform regression testing if a change occurs in a platform, even if that change is to a feature not applicable or desired by a particular product business team. And since products must wait for the development and testing for full and large platform feature set, products may end up taking longer to delivery. This is directly counter to one of the biggest advantages seen in platform-based product development.
5.3.2 Applicability to Other Contexts
It is felt that the root causes, the holistic framework and the proposed aids are applicable to platform-based systems development environments in other industries. Example applications of the proposed aids could be shown for the automotive industry, for example, which must also deal with many influences and the evolution of technologies (form) across multiple component
(platform) teams that serve multiple product teams. Additional study in other industries and contexts would begin to validate whether the findings of this study are applicable outside the target organization.
5.3.3 Better Measurement and Longer Pilot
Ideally, the pilot would have run longer resulting in better familiarity with the proposed aids and more demonstrated use. In addition, the measurements for gauging improvement were very subjective. Establishing less subjective measurements is a challenge. Ideally, one would want to show quantitative improvement in the proposed goals for effective systems development; i.e., fast and predictable delivery, resource efficiency, meeting needs, no system integration issues, and increased coherency.
79

[1] M. H. Meyer and A.P. Lehnerd, The Power of Product Platforms, New York: Free Press,
1997.
[2] D. Robertson and K. Ulrich, Planning for Product Platforms, Sloan Management Review,
Summer 1998 v39 n4.
[3] M. Cusumano and K. Nobeoka, Thinking Beyond Lean, The Free Press, New York,
1998.
[4] S. Eppinger, Product Design and Development, new version to be published Fall 1999.
[5] M. McGrath, Product Strategy for High-Technology Companies, Irwin Professional
Publishing, New York, 1995.
[6] M. H. Meyer and R. Seliger, Product Platforms in Software Development, Sloan
Management Review, Fall 1998 v40 nI.
[7] E. Jandourek, A Model for Platform Development, HP Journal, August 1996, article 6.
[8] E. Crawley, MIT 16.982 System Architecture class, Fall 1999
[8] S. C. Wheelright and K. B. Clark, Revolutionizing Product Development, The Free Press,
New York, 1992.
[10] R. Foster, Innovation, the Attacker's Advantage, Summit Books, Simon and Schuster,
1986.
[11] N. Leveson, Intent Specifications: An Approach to Building Human-Centered
Specifications, Proceedings Third International Conference on Requirement Engineering,
IEEE Comput. Soc. 1998, pp.
2 0 4 13 .
[12] K. B. Lloyd and D. J. Jankowski, A Cognitive Information Processing and Information
Theory Approach to Diagram Clarity: A Synthesis and Experimental Investigation, The
Journal of Systems and Software, v. 45 n. 3, March 15, 1999, p 203-214.
[13] J. Hauser and D. Clausing, The House of Quality, Harvard Business Review, v. 66 n. 3,
1988, pp. 63-73.
[14] D. D. Woods, Toward a theoretical base for representation design in the computer medium: Ecological perception and aiding human cognition. In J. M. Flach, P.A.
Hancock, K. Caird and K. J. Vicente, editors for An Ecological Approach to Human
Machine Systems I: A Global Perspective, Erlbaum, Hillsdale, New Jersey, 1995.
80

-
An analysis of the set of root causes was performed to determine which if any were the key drivers. The following matrix was used to score the relationship between the causes. Causes listed vertically on the left side of the matrix were analyzed to determine if they drove any of the other causes listed horizontally on the top of the matrix. A "1" in a cell indicates that the vertical
(left-most) cause drives the one on the top. The rows were totaled to determine how many times a particular cause acted as a driver to others. The columns were totaled to determine how many times a cause is driven by others. Causes with significant scores are highlighted.
This approach is limited as compared to a directed graph approach in that it doesn't necessarily or easily identify a potential single cause that drives all others, nor does it easily detect hierarchical and cyclical relationships. For example, at the extreme case, there could be one cause that has a "times a driver" score of 1 and a "times driven" score of 0, which in effect sets in motion a set of hierarchical and cyclical relationships between all other causes. The causes were studied to detect relationships that were not immediately visible. The causes appeared sufficiently distinct that the decision was made to proceed with the entire set.
81

Root
Cause
Relationships column-tem
S=? ocus T
I
I
1.
I
I
I
E
2
L
--k roucs
I Ii
E
E 21
-
Pr cess
-E
.......
I
I i
I
1
.. 6
I p a
I
Mm.nn
1
I
R.. urces driver ro-tm
DRIVES
Non-holisfic view
&)
IToo platform-focused
Too
(project) product-Iocused
IlUlll~i11d*21
Insufficientd
PartialA
Not
Not able a
Doesn't communicate intent
Unclear allocations
Not cress-platlormv-product
Doesn't1
No cross-plfforml-product coordination
High
Poor communication
Revisiting
Unclear roles
& responsibilities
U z accessible
1 1
1
1 1 1 1 11
1
±
T
1
1
1 f
I1
1
1 1
1
1 1
1
1 1
1
1
1 1A1se1t
1
1
1
1
1 1
1
1
1 1 1 1
11
1 1 overhead1
1 decisions
1
1
1
1
1 1
1
1
1
1
1
1 1
1 1
1
1
1 1 1 1
1
1
1
1
1
1
1d1t1il
8
1
2
112
1 1
1
1
1
6
1
1
1
1 1 1
1
1 111
1 1 1
1 1
Doesn't accommodate asynchronicity
Poor estimation / planning
Poor change management
Inadequate org structure
Vi.1
High overhiead
Dupcation of effort
Insufficient staffing
Timesdriven by
1
1*.1*
11
1
1
1
1
1 1
6
6
7
9
1
6 1 17
1 1
31 9
1
1
1
1
1
1
1
1
1
1
1
1 1 1
6 I
11 16
I
12
3
16
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
15
1 1
1
I
20
1 1
24 a
1 9
1
1
1
1
1
1
1
1
1
1 1
1
1
1
1
1
1
11
1
1
1 1
1
1
1 1
10
1
2 4 1 4 24
1
1
1
1
1
1
1
1
1
1
1
1
4
1
1
1
1
1
1
1
14
1
1
1 1
1
1
1
1
1
1
1
21
1
1
1
1
1
1
1
1
0
1
1 1
1
18
1 I
20 1
1
1
1
Key,
WSignificarft scorm for that dimension
Causes with significant score in both dimensions
Not applicable
11i
I
1
9
2
15
6
10
1 1

-
The table used to create Figure 9 follows.
83

Root Cause Survey Data
Rate the prevalence of the following causes in your organization PRIOR to the introduction of SS&P processes and/or work products.
Totals
0
Non-holistic view
Too short-term focused
Too platform-focused
Too (project) product-focused
Insufficient detail
Partial / Absent
Not accessible
Not usable
Prevalence by respondent
(1=abeent
Person 1 Person 2 Person3 Person 4 Person
S=sary arasalent
5 Person 6
Person 7 Person 8
Person g
3 4 3 2 5 4 5 2 3
Person 10 Person 11
3 4
3 2 5
5 5
3 3 4 3 5 3
4 5 5 4 2 3 4 4 4 4 5
4 4 5 5 4 3 5 5 4 5 5
4 4 4 2 5 5 4 3 3 2 4
4 3 4 3 5 3 4 5 4 4 4
3 2 4 5 4 2 4 4 2 1 2
3 2 4 4 4 3 2 3 2 2 2
Doesn't communicate intent
Revisiting decisions/directions
3
Unclear allocations
Poor communication
4
Not cross-plaforn/-product 4 3 5 3 4
Doesnt accommodate 3 4 4 4 asynchronicity______________________________________________________
4
Poor inputs
P-N cross-platform/-product coordination
High overhead
2
5
2
4 5
________________
3
5
6
5
5
5
5
4
5
________
5
4
2
4
4
4
2
4
4
4
4
2
4
4
4
4
5
4
5
Unclear roles & responsibilities 4 4 4 3 5
4
4
2
5
4
4
2
5
2
4
2
3
4
5
4
5
4
3
4
5
4
5
3
2
5
3
3
3
2
4
3
3
3
4
4
4
4
3
3
2
3
4
4
4
3
4
3
3
4
5
3
4
2
2
3
3
4
4
3
3
Lack of agreed to definitions
P-Doesn't accommodate asynchronicity_
Poor estimation / planning
3
4
4
3
4
3
4
5
2
2
3
4
5
4
3
4
4
4
5
5
4
3
3
4
3
4
4
5
4
2
2
2
4
MAX
5
5
5
5
5
5
5
4
4
5
5
5
5
5
5
___
5
5
5
5
5
4
Poor change management 5 3 2 3 3 4 2 1 2 5 2 5
Inadequate org structure
Incentives misaligned
Cultural resistance to system engineering
Funding model misaligned
3
3
4
4
4
3
2
5
I
4
5
4
5
2
5
3
3
I
3
5
3
4
3
3
4
4
4
3
2
4
4
4
3
5
3
4
3
4
4
4
5
5
4
4
5
4
4
5
5
5
Inadequate skill sets 2 3 4 4 3 1 1 3 3 2 2 4
High overhead
Duplication of effort
Insufficient staffing
4
4
3
2
2
4
4
3
5
5
2
3
4
5
4
3
4
4
3
2
2
3
4
2
4
3
3
3
4
5
3
4
4
5
5
5
2
1
2
3
2
3
2
2
1
2
2
2
2
2
2
___
2
2
3
3
3
2
2
1
2
2
3
2
3
MIN
2
2
3.3
42
3.9
3.7
3.6
3.9
3.5
3.8
3.5
2.9
3.5
3.9
3.5
4.3
2.5
3.5
3.4
3.5
3.3
3.5
3.8
3.8
3.6
3.9
3.0
2.8
AVG
3.5
3.7
4r0
4,5
4.0
3.0
3.0
4.0
4.0
40
4.
3.0
3.0
3.0
4.0
50
4.0
4.0
Median
3.0
5's
/ 4'
Std-dev Very Prevalent
1.0 5
3.0 1.1
0.9
0.7
9
5
10
0.7
0.9
0.7
0.6
1.0
0.7
1.2
0.8
7
8
3
5
7
7 a
5
3.0
50
1.1
1.1
5
9
4.0 1.0 7
40 0.6
3's / 2's
Prevalent a
6
4
3
2
1
5
4
3
6
2
8
6
4
4
4
4.0
4.0
3.0
4.0
4.0
30
1.0
0.9
1.1
0.8
0.8
1.2
7
7
7
8
5
4
3
6
3
4
7
4.0
40
3.0
0.7
0.8
1.0
3
6
7
5
5
4.0
0.6
1.0
0.8
1.0
1.0
10
2
5
6
6
1
7
6
5
4
6
5
0
0
0
0
0
0
0
0
0
0
1's
Absent
0
0
0
0
0
0
1
0
1
0
0
0
0
0
0
0
2
0
0
0
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
Total
11
11

-
The data tables used to create Figures 25 through 28 follow.
85

nfluence Diagram Survey
Data
Rate the degree to which the INFLUENCES DIAGRAM improves on a particular problem (H=high, L=low, -=worsens,
<blank>=no effect)
Non-holistic view
Too short-term focused
Too platform-focused
Too (project) product-focused
Insufficient detail
Partial / Absent
Not accessible
Not usable
Doesn't communicate intent
Unclear allocations
Not cross-platform/-product
Doesn't accommodate asynchronicity
Poor inputs
Inadequate org structure
Incentives misaligned
011
Cultural resistance to system engineering
Funding model misaligned
Inadequate skill sets
High overhead
Duplication of effort
Insufficient staffing
L
L
L
L
L
L
H
L
L
L
L
L
L
L
H
L
L
Rasp 1 itResp2
H H
L
L
L
L
L
L
L
H
L
L
L
L
L
L
L
L
H
L
L
L
L
L
L -
-
L
3 Rees4Rsp
H
L
L
L
Degree of Improvement
(H, L, -, <blank>)
5
Rsp
6
Rsp 7 Reasp
8
Resp Ras 10 Rasp
11
L H H L H
L H L H L H
L L H L H
L H H H H
L L L L L H
L L L L L H
L L L L H
L
L
L
H
H
H L
L
L
H
H
L L L L L
L
L
L
L
L
L
L
L
H
L
L
L
L
L
L
H
H
H
L L H L
L L H L L
L L L L L
L L H L
L L L L L
L L H L
L
L
L
L
H
L
L
L L
1
0
0
1
0
1
1
3
0
1
1
1
3
3
1
2
4
1
4
2
H
6
5
5
7
7
5
7
5
7
7
5
6
6
4
7
6
5
5
6
4
Number of Responses
L Worsens n/a
3 0
0
0
2
2
3
3
2
0
0
0
1
0
1
1
4
2
3
4
0
0
0
0
0
0
3
3
3
3
5
4
4
7
0
0
5
4
0
0
0
5
5
4
Total
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
H
Percent of Responses
L Worsens n/a
54.5%
36.4%
18.2%
36.4%
9.1%
18.2%
9.1%
27.3%
45.5%
54.5%
36.4%
63.5%
54.5%
54.5%
0.0%
0.0%
0.0%
0.0%
9.1%
0.0%
0.0%
18.2%
18.2%
27.3%
27.3%
18.2%
27.3%
36.4%
27.3%
27.3%
36.4%
45.5%
63.6%
0.0% 36.4%
9.1%
18.2%
0.0% 9.1% 27.3%
9.1%
9.1%
63.6% 0.0% 27.3%
63.6% 0.0% 27.3%
27.3% 45.5% 0.0% 27.3%
9.1%
45.5% 0.0% 45.5%
9.1% 54.5% 0.0% 36.4%
0.0% 63.6% 0.0% 36.4%
9.1%
45.5% 0.0% 45.5%
0.0% 636% 0.0% 36.4%
9.1%
9.1%
0.0%
45.5%
45.5%
63 6%
0.0% 45.5%
0.0% 45.5%
0.0%
36.4%
Expected
Percent Meeting
Exceeding a
Expedtions
L
L
H
L
L
H
H
L
9%
100%
73%
100%
100%
100%
100%
100%
100%
100%
100%
55%
82%
73%
73%
91%
73%
100%
27%
91%
91%

Evolution Diagram Survey Data
Rate the degree to which the EVOLUTION DIAGRAM improves on a particular problem (H=high, L=low, -=worsens. <blank>=no effect) p
Non-holistic view
Too short-term focused
Too platform-focused
Too (project) product-focused
Insufficient detail
Partial / Absent
Not accessible
Not usable
Doesn't communicate intent
Unclear allocations
Not cross-platform/-product
Doesn't accommodate asynchronicity
Poor inputs
Inadequate org structure
Incentives misaligned
Cultural resistance to system engineering
Funding model misaligned
Inadequate skill sets
High overhead
Duplication of effort
Insufficient staffing
L
L
L
L
L
L
L
L
L
L
L
Rasp 1
L
H
L
L
L
L
L
L
L
L
Degree af Improvement
(H, L, -, <blank>)
Resp2 Reap 3 Resp 4 Reap
5
Reasp
6
Reap 7 Resp 8 Resp
9
ResplO Respl
L L H L L L
L
L
L
L
L
H
L
L
L
L
L
L
L
L
H
L
L
L
L
L
-
L
L
-
L
L
L
L
L
L
L
L
L
L
H
H
H
H
H
H
H
L
L
L
H
L
L
L
L
L
H
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
H
H
L
L
L
L
H
L
H
L
L
H
L
L
L
L
L
L
H
L
H
L
L
H
H
H
H
H
H
H
H
L
L
H
H
H
H
L
H
L
H
L
H
L
L
L
L
L
L
L
L
L
1
0
0
0
0
0
1
2
4
5
3
1
4
2
1
H
4
2
0
2
2
1
Number of Responses
1
1
0
0
0
0
0
0
0
0
0
Worsens
0
0
0
0
0
0
0
0
0
0
3
4
3
3
3
3
3
5
4
3
4
3
3
3 n/a
4
5
5
4
5
3
5
4
6
4
L
6
7
6
4
3
4
5
6
6
6
6
5
5
6
7
6 a
6
11
11
11
11
11
11
11
11
11
11
11
11
11
Total
11
11
11
11
11
11
11
11
Percent of Responses
0.0%
0.0%
9.1%
0.0%
0.0%
0.0%
H
9.1%
36.4%
18.2%
36.4%
L
54.5%
Worsens
0.0% n/a
36.4%
36.4%
54.5%
36.4%
0.0%
0.0%
0.0%
27.3%
27.3%
27.3%
36.4% 3e4% 0.0% 27.3%
45.5% 27.3% 0.0% 27.3%
9.1%
63.6% 0.0% 27.3%
18.2%
27.3%
9.1%
19.2%
18.2%
54.5%
36.4%
0.0%
27.3%
9.1%
27.3%
45.5%
9.1%
36.4%
54.5%
0.0% 27.3%
54.5%
0.0% 27.3%
18.2%
0.0%
9.1%
45.5%
54.5%
54.5%
0.0%
0.0%
0.0%
36.4%
45.5%
36.4%
63.6%
54.5%
0.0%
0.0%
36.4%
45.5%
45.5% 0.0% 45.5%
54.5%
0.0% 45.5%
72.7% 0.0% 27.3%
54.5%
0.0% 45.5%
Expected
Percent Meeting a
Exceeding
L
H
H
H
L
H
H
H
L
L
100%
36%
16%
36%
100%
73%
100%
18%
27%
55%
I%
73%
100%
100%
100%
100%
100%
100%
100%
73%
100%

Product/Platform Chart Survey Data
Rate the degree to which the PRODUCT PLATFORM CHART improves on a particular problem (H=high, L=Iow, -=worsens,
<blank>=no effect)
0
I
5
Non-holistic view
Too short-term focused
Too platform-focused
Too (project) product-focused
Insufficient detail
Partial / Absent
Not accessible
Not usable
Doesn't communicate intent
Unclear allocations
Not cross-platform/-product
Doesn't accommodate asynchronicity
Poor inputs
Inadequate org structure
Incentives misaligned
Cultural resistance to system engineering
Funding model misaligned
Inadequate skill sets
High overhead
Duplication of effort
Insufficient staffing
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
H
H
H
H
Degree of Improvement
(H, L, -, <blank>)
Reasp
I
Resp2 Resp 3 Reasp 4 Rasp
5
Reap
6
Reap 7 Rasp a Rasp 9 Resp 10 Resp 11
H L L H L H H L L
H L H H H L H H H H
L
L
L
L
L
L
L
L
L
H
L
L
L
L
L
L
H
L
L
-
-
-
L
L
H
L
L
L
L
L
L
L
L
L
L
L
L
L
L
H
L
L
L
L
L
L
L
L
L
H
H
H
H
H
H
H
H
H
H
H
H
L
L
L
L
L
L
L
L
H
L
L
H
H
L
L
H
L
H
L
L
L
L
L
H
L
L
L
H
H
L
H
H
L
L
L
L
L
L
L
L
H
L
H
H
H
H
H
H
L
L
L
L
L
L
L
L
L
L
H
L
H
L
H
L
L
L
L
L
1
0
1
0
0
1
0
0
2
4
4
2
3
4
2
4
1
H
4 a
6
5
Number of
Responses
4
4
4
4
4
4
3
3
2
2
3
3
3
3
3
3
3
2 n/a
2
1
3
Worsens
0
0
0
0
0
0
0
0
0
0
1
1
1
0
0
0
0
0
0
0
1
7
7
6
5
4
6
4
4
6
4
6
2
3
6
L
5
2
6
7
6
8 a
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
Total
11
11
11
Percent of Responses
18.2%
36.4%
9.1%
27.3%
36.4%
18.2%
0.0%
0.0%
9.1%
9.1%
0.0%
9.1%
0.0%
0.0%
H
36.4%
72.7%
54.5%
45.5%
18.2%
36.4%
36.4%
63.6%
63.6%
54.5%
54.5%
63.6%
54.5%
36.4%
36.4%
54.5%
36.4%
54.5%
45.5%
36.4%
54.5%
72,7%
72
7%
L
45.5%
Worsens
0.0% n/a
18.2%
18.2% 0.0% 9.1%
18.2%
0.0% 27.3%
27.3% 0.0% 27.3%
54.5% 9.1% 18.2%
0.0%
0.0%
9.1%
9.1%
9.1%
0.0%
0.0%
0.0%
0.0%
0.0%
0.0%
0.0%
0.0%
36.4%
36.4%
0.0% 36.4%
0.0%
27.3%
0.0% 27.3%
27.3%
27.3%
18.2%
18.2%
27.3%
27.3%
27.3%
27.3%
36.4%
36.4%
36.4%
Expected
Percent Meeting 0
Exceeding
Expections
H
H
L
H
H
L
H
H
L
100%
91%
100%
18%
36#%
64%
07%
30%
100%
100%
100%
100%
100%
100%
100%
55%
45%
91%
73%
100%
100%

Feature/Platform Chart Survey Data
Rate the degree to which the FEATURE PLATFORM CHART improves on a particular problem (H=high, L=low, -=worsens, <blank>=no effect)
0
Non-holistic view
Too short-term focused
Too platform-focused
Too (project) product-focused
Insufficient detail
Partial / Absent
Not accessible
Not usable
Doesn't communicate intent
Unclear allocations
Not cross-platform/-product
Doesn't accommodate asynchronicity
Poor inputs
Inadequate org structure
Incentives misaligned
Cultural resistance to system engineering
Funding model misaligned
Inadequate skill sets
High overhead
Duplication of effort
Insufficient staffing
Resp2
L
L
L
L
L
H
L
L
L
L
H
L
L
L
L
L
L
L
L
L
L
Reasp 1
H
H
L
L
H
H
L
H
L
L
L
L
H
L
H
L
L
L
L
H
L
L
L
H
H
L
L
H
H
H
H
H
L
L
H
L
H
L
L
-
-
L
L
L
L
L
L
L
Degree of Improvement
(H, L.-, <blank>)
Reasp 3 Reasp 4 Reasp
5
Reasp 6 Reasp 7 Reasp Reasp 9 Resp 13 Resp it
L H L L L
H L H H L
L
L
H H L H H
L
L
H
H
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
H
H
H
H
H
H
H
H
H
L
H
H
L
H
H
H
H L
L
H
H
H
H
H
H
H
H
H
L
H
H
L
L
H
L
L
H
L
L
L
L
L
L
L
L
L
L
3
1
5
4
1
3
4
3
5
2
4
4
4
4
H
2
1
1
1
2
2
1
Number of Responses
5
6
4
4
6
3
3
5
3
3
6
4
4
4
4
L
5
4
5
5
5
6
Worsens
1
0
0
0
0
1
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
3
3
3 n/a
3
3
3
4
3
3
3
3
5
5
5
4
4
5
4
3
4
4
Total
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
Percent o Responses
H
18.2%
36,4%
36.4%
36.4%
36.4%
45.5%
18.2%
27.3%
36.4%
27.3%
45.5%
36.4%
36.4%
36.4%
36.4%
27.3%
54.5%
45.5%
27.3%
27.3%
27.3%
36.4%
L
45.5%
Worsens
9.1%
36.4% 0.0% n/a
27.3%
27.3%
0.0%
0.0%
0.0%
0.0%
27.3%
27.3%
27.3%
27.3%
0.0% 27.3%
0.0% 27.3%
9.1%
27.3%
9.1%
36.4%
0.0% 27.3%
0.0% 27.3%
27.3% 36.4% 0.0% 36.4%
9.1% 45.5% 0.0% 45.5%
9.1%
54.5% 0.0% 36.4%
9.1%
54.5%
0.0% 36.4%
18.2% 36.4% 0.0% 45.5%
9.1%
45.5% 0.0% 45.5%
9.1%
45.5% 0.0% 45.5%
45.5% 0.0% 18.2%
9.1% 54.5% 0.0%
36.4%
36.4%
Expected
Percent Meeting s
Exceeding
Expections
H
H
H
L
L
H
H
H
H
H
L
91%
36%
36%
36%
73%
73%
100%
27%
36%
27%
4$%
36%
100%
100%
100%
64%
100%
100%
100%
100%
100%