<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<channel rdf:about="http://hdl.handle.net/1721.1/3764">
<title>Center for Innovation in Product Development (CIPD)</title>
<link>http://hdl.handle.net/1721.1/3764</link>
<description/>
<items>
<rdf:Seq>
<rdf:li rdf:resource="http://hdl.handle.net/1721.1/6753"/>
<rdf:li rdf:resource="http://hdl.handle.net/1721.1/5064"/>
<rdf:li rdf:resource="http://hdl.handle.net/1721.1/3962"/>
<rdf:li rdf:resource="http://hdl.handle.net/1721.1/3961"/>
</rdf:Seq>
</items>
<dc:date>2013-05-21T23:14:40Z</dc:date>
</channel>
<item rdf:about="http://hdl.handle.net/1721.1/6753">
<title>Complex System Classification</title>
<link>http://hdl.handle.net/1721.1/6753</link>
<description>Complex System Classification
Magee, Christopher; de Weck, Olivier
The use of terms such as “Engineering Systems”, “System of systems” and others have been coming into greater use over the past decade to denote systems of importance but with implied higher complexity than for the term systems alone. This paper searches for a useful taxonomy or classification scheme for complex Systems. There are two aspects to this problem: 1) distinguishing between Engineering Systems (the term we use) and other Systems, and 2) differentiating among Engineering Systems. Engineering Systems are found to be differentiated from other complex systems by being human-designed and having both significant human complexity as well as significant technical complexity. As far as differentiating among various engineering systems, it is suggested that functional type is the most useful attribute for classification differentiation.  Information, energy, value and mass acted upon by various processes are the foundation concepts underlying the technical types.
</description>
<dc:date>2004-07-24T00:00:00Z</dc:date>
</item>
<item rdf:about="http://hdl.handle.net/1721.1/5064">
<title>Architecting and Innovating</title>
<link>http://hdl.handle.net/1721.1/5064</link>
<description>Architecting and Innovating
Campbell, Ronald B. Jr.
Innovating is essential to sustained industrial growth and profitability. But experience amply demonstrates how difficult innovation is, especially for large companies. The synthesis of valued offerings by aligning customer needs with technology possibilities lies at the heart of innovation. System architects working at the strategic level are ideally positioned, as a consequence of their experience and training, to play a key and even a leadership role in enabling, energizing, and leading this synthesis. The scope of the architecting effort must include the process architecture of the entire value chain as well as the more conventional product architecture to address all potential wellsprings of innovation. This paper outlines an architecture-centric approach to innovation, based on the concept of the system platform architecture.
</description>
<dc:date>2004-04-14T00:00:00Z</dc:date>
</item>
<item rdf:about="http://hdl.handle.net/1721.1/3962">
<title>Drive Out Fear (Unless You Can Drive It In):The role of agency and job security in process improvement</title>
<link>http://hdl.handle.net/1721.1/3962</link>
<description>Drive Out Fear (Unless You Can Drive It In):The role of agency and job security in process improvement
Repenning, Nelson
Understanding the wide range of outcomes achieved by firms trying to implement TQM and similar process improvement initiatives presents a challenge to management science and organization theory: a few firms reap sustained benefits from their programs, but most efforts fail and are abandoned. A defining feature of such techniques is the reliance on the front-line workforce to do the work of improvement, thus creating the possibility of agency problems; different incentives facing managers and workers. Specifically, successfully improving productivity can lead to lay-offs. The literature provides two opposing theories of how agency interacts with the ability of quality-oriented improvement techniques to dramaticlly increase productivity. The 'Drive Out Fear' school argues that firms must commit to job security, while the 'Drive In Fear' school emphasizes the positive role that insecurity plays in motivating change. In this study a contract theoretic model is developed to analyze the role of agency in process improvement. The main insight of the study is that there are two types of job security, internal and external, that have opposite impacts on the firm's abilty to implement improvement initiatives. The distinction is useful in explaining the results of different case studies and can reconcile the two change theories.
</description>
<dc:date>1998-11-01T00:00:00Z</dc:date>
</item>
<item rdf:about="http://hdl.handle.net/1721.1/3961">
<title>Understanding Fire Fighting in New Product Development</title>
<link>http://hdl.handle.net/1721.1/3961</link>
<description>Understanding Fire Fighting in New Product Development
Repenning, Nelson
Despite documented benefits, the processes described in the new product development literature often prove difficult to follow in practice. A principal source of such difficulties is the phenomenon of fire fighting the unplanned allocation of resources to fix problems discovered late in a product's development cycle. While it has been widely criticized, fire fighting is a common occurrence in many product development organizations. To understand both its existence and persistence, in this article I develop a formal model of fire fighting in a multi-project development environment. The major contributions of this analysis are to suggest that: (1) fire fighting can be a self-reinforcing phenomenon; and (2) multi-project development systems are far more susceptible to this dynamic than is currently appreciated. These insights suggest that many of the current methods for aggregate resource and product portfolio planning, while necessary, are not sufficient to prevent fire fighting and the consequent low performance.
</description>
<dc:date>2001-03-01T00:00:00Z</dc:date>
</item>
</rdf:RDF>
