Sunday, October 11, 2009

SDM has Rx for MD seeking health systems perspective - SDM Pulse Fall 2009

By Dr. Sahar Hashmi, SDM ’09

Dr. Sahar Hashmi, right, meets with Pat Hale, director of the
SDM Fellows Program, during a break from SDM activities.
Watching President Obama and Congress grapple with health-care reform this summer highlighted for me the challenges faced by healthcare systems around the world. The complexities of increasing costs, a scarcity of qualified personnel, and demanding governmental regulations are universal. Yet, everyone focuses on issues within their own country, hospital, or practice rather than approaching the whole problem from an international systems-based perspective.

Some might argue that this broader perspective adds an unnecessary, even insurmountable, layer of complexity, but I would disagree. As a physician, I have seen limited thinking affect every level of medical care. Hospital CEOs argue that their hospital is unique and what will work in one hospital would not work in another. Doctors argue that disease prevalence varies from one country to another and from one patient to another. Standards of treatment vary. And yet, I can’t help but think of a quote from one of my colleagues: "After a while, all knee replacements look the same."

When I decided to join MIT’s System Design and Management (SDM) Program, my goal was to better understand the health-care system and to find ways to improve it as a whole. Six months into the program, I am confident I made a wise decision.

SDM has drawn me away from the tunnel vision of the medical profession and taught me to look at the world from many different angles. Each class I’ve taken has contributed to broadening my perspective.

For example, SDM’s course in product design and development revealed to me the enormous challenges involved in bringing new products to market. Pat Hale, director of the SDM Fellows Program, and Assistant Professor Maria Wang not only taught the class but arranged for successful business leaders to share their product development stories with us. From this class, I have come to appreciate the technical and business factors that need to be considered in evaluating a product’s overall effectiveness—not just its direct medical features.

But what impressed me was the practical experience of going through the process of developing and marketing a product. In our PDD class, students were required to work in teams to develop a viable product. My team designed and developed an efficient pill box for the elderly but we were all delighted to find it was appreciated by younger potential customers who have diabetes as well. The elder patients liked the timer and the flickering light that served as a silent reminder for their pills. All patients appreciated the privacy we provided via bar codes on the pill box, which could be read from cell phones to gain access to prescription details.

Generally, doctors who prescribe medications for chronic diseases like diabetes or hypertension are rightfully concerned with how well patients follow their treatment regimens. But, few doctors delve deeper into ways of solving this problem. Attempting to tackle this problem myself, even in a small way, helped me see the critical importance of the broader, systems perspective in the health care.

SDM also taught me to appreciate technological innovation. By studying technology strategy with Senior Lecturer Michael Davies, I realized that it’s necessary to work with whole systems to adopt change—not just the administration but the physicians, nurses, technicians, and the patients themselves.

For example, our project in this class focused on developing system-wide strategies for the faster adoption of robotic surgery. We spoke with the product manager of the robotics company, Intuitive Surgical, as well as a few surgeons and patients to understand the system and develop a better adoption strategy. This helped us comprehend the whole system—not just one customer and one operation—and our project was deemed to have the best strategy policy in the class. (The details are proprietary.)

Finally, physicians can sometimes understate the significance of communications and relationships in their work—yet this social aspect is perhaps one of the most important elements of excellent medical service and care. Professor Tom Allen’s class, Organizing for Innovative Product Development, pointed out the importance of decreasing distance as a method to building relationships and increasing problem-solving.

Few hospitals consider using architectural designs to increase communication among physicians, nurses, and technicians from different departments. Yet many existing designs are counterproductive. Increasing the communication interdepartmentally could potentially help treat patients with complex or multiple problems more effectively. This class helped me to appreciate networks and designs that help increase face-to-face communications in health care systems.

Many of the technical skills taught in SDM can also be used in the medical and pharmaceutical world. The class in system dynamics, for one, taught me how to draw and simulate infectious disease models. Such models could help us predict and prepare for a pandemic. In fact, I’m planning to focus my thesis on the recent spread of the H1N1 flu virus, examining how the use of non-pharmaceutical interventions and vaccines might be applied to compact it from a healthcare systems view.

Understanding the health-care system better and improving it in whatever way we can is a great way to start to make the world a better place. I’m pleased to report that SDM has already helped me begin to formally and systematically analyze the broader health-care system. I look forward to taking other classes, such as Innovations in the Health Care System with Dr. Stan N. Finkelstein and Senior Lecturer Joseph F. Coughlin, and building up my understanding and perception of how to bring about innovation in health care using a systems approach.

Saturday, October 10, 2009

Certificate student offers systems analysis of power grid - SDM Pulse Fall 2009

By Brian London, SDM ’09 Certificate Program

Solar, wind, and other alternative sources of power generation may all be part of the solution to today’s energy crisis—but integrating these renewable and new resources along with traditional sources of energy poses major challenges for the nation’s electrical grid.

The current national electrical grid is essentially the same as the electrical distribution system laid out by Thomas Edison; this aging infrastructure and the increasing demand for energy is pushing the grid to its limits. In addition, a growing awareness of environmental issues (including global warming), as well as economic and national security issues, have created a push to limit the use of carbon-based energy sources.

The passing of the economic stimulus bill in February 2009 made billions of dollars available to upgrade the country’s power grid and pursue clean energy technologies. However, many of these technologies are being investigated without a systems-based approach, or an understanding of their true costs and benefits. One example is the addition of corn-based ethanol into gasoline. While its benefits were highly touted, ethanol actually has a negative environmental impact, and it raises the cost of food.

I decided to analyze the problem with the electrical grid for my MIT System Design and Management (SDM) Program capstone project, a required element of the certificate program in systems engineering. Not only is solving the problem a very interesting challenge, but it is one that’s particularly in need of a systems-based solution. This paper describes my analysis of the stakeholder needs, with the end goal of succinctly and clearly defining the root problem, allowing for the evaluation of possible solutions.

Every day I read about new projects and plans to tackle some element of the energy crisis, but people seem to be leaping ahead without first taking time to define the fundamental underlying problem. It’s a pattern I’ve seen time and time again in my career. For example, in the years before I started my current job as a system engineer at Draper Laboratory (an independent, not-for-profit, applied research laboratory located in Cambridge, MA), I spent several years working as a civilian for the US Army in research and development. During that time I observed that while efforts across the industry developed advanced systems in the support of military operations, the soldier in the field was often laboring in need of something completely different.

This lesson has stayed with me, and it is one of the reasons that I decided to work to frame a problem properly for my SDM capstone project. The goal was to develop the metrics to provide a method for evaluating proposed solutions for the US electrical system—including defining the important criteria for success working within known political, economic, and business constraints.

The US electrical system consists not only of the generation, transmission, distribution, and end user of electricity. The system also includes the financial exchange for the purchase and sale of electricity, which is divided into several regions, each with different laws and regulations. System regulations at the state and federal levels have as much impact on the system as the type of fuel used in generation.

In some states, the generation, transmission, distribution, and sale of electricity are all accomplished by the same company or utility. In other states, this vertical monopoly is illegal, so a utility company may only provide the customer point of sale, or more often own a portion of the supply chain. In order to examine the problem at a national level, I separated the generators, transmission companies, and distributors, but assumed that the utilities provided the distribution and sale of electricity.

I started with some tools I learned in Professor Ed Crawley’s class in system architecture and a basic systems engineering approach—a top-down analysis of the US electrical system to frame the problem statement and compile stakeholder-specific needs.

At first, I undertook to identify all the stakeholders with priority needs of the electrical system, using object process methodology (OPM) to model their relationships. Unfortunately, the OPM model was very complex and too intertwined to analyze in the framework of the capstone project.

So, I decided to try to see whether a design structure matrix (DSM) might work. Although DSM is typically used to analyze the dependencies among the system elements or processes, it seemed a useful construct for illustrating how various stakeholders affect each other.

Even with this approach, my initial DSM was enormous because there were so many interdependencies. I therefore determined for a first-level analysis to reduce the number of stakeholders and focus on those most important to the overarching problem. To eliminate superfluous stakeholders, I used the DSM to identify which acted as second-order stakeholders. I defined these as stakeholders that influence others, but do not provide any direct benefit to the system.

Original DSM

















Figure 1:
The design structure matrix (DSM) shows how the stakeholder in the row affects the stakeholder in the column. After the formation of this original DSM, stakeholders were grouped together and pared down to produce the final DSM.

Final DSM














Figure 2:

In this simplified form of the DSM, it’s easy to see, for example, how consumers (given
the designator 1) influence the state government and provide money to utilities. They
are also regulated by state government, receive a product from the utilities (equipment
to tie to grid), and get energy from the transmission company.

I then removed the second-order stakeholders to simplify the DSM. This was important as some of the stakeholders have conflicting needs, and identifying the key stakeholder allows me to focus on those that can provide the most benefit to "society," a conglomerate of all stakeholders.

Grouping stakeholders was a second technique used to eliminate stakeholders from the analysis. I began by arranging stakeholders with similar relationships together. Some clusters clearly displayed that some stakeholders only influence others. Lobbyists, for example, were removed because they only advocate for the needs of others. Those whose interests were more tangential to power generation and distribution also had to be removed. Investors, for example, were removed because their needs are not specific to this field. In addition, a variety of government organizations were removed as they provided input to the Federal Energy Regulatory Commission (FERC), which could then act in their behalf.

The resulting list of stakeholders includes three major groups; regulators, consumers, and energy providers, which include the utilities, generation companies, and transmission companies. There are also three levels of regulators—federal, regional, and state. With an understanding of the primary stakeholders, I then had to perform a deeper dive to examine their needs. Their relationships were also identified and grouped.

I used a "to, by, using" analysis to communicate the needs of the individual stakeholder. For example I found that consumers need "to" consume electricity, have minimal direct change, reduce greenhouse gas emissions, and reduce dependence on foreign oil. I then assigned attributes to the needs. Attributes of the customer’s need to minimize direct change are: convenience, equipment location, and effort. The need to minimize direct change could be met by minimizing apparent complexity, minimizing new infrastructure, and minimizing change. But these "by" statements are design, and I had to force myself from completing this part of the analysis.

Examining these needs in detail not only reveals how they align or diverge, it makes it possible to ensure that each need is considered, which drives system requirements. We would not want to design a product that could require significant input from the end user, as it would be impossible to implement across the country. And yet, such solutions have been proposed.

The needs of each key stakeholder can be summarized as follows:

Consumers want a low-cost, "clean" solution, where the change (and complexity) is concealed. They want something at least comparable to today’s availability, reliability, convenience, and safety. And, some are willing to make trades for lower rates.

Utilities want to maximize profits by increasing efficiency, minimizing blackouts (increasing reliability), and reducing costs (including for electricity).

Generators want to maximize profits by increasing efficiency, having lower fuel costs, maximizing revenue opportunities, minimizing ramp-ups and downs, and minimizing fees and taxes.

Transmission companies want to maximize profits by charging for use and minimizing upkeep costs. Regional transmission offices want to ensure reliable operation within the region, meeting the current and future needs of the wholesale electricity marketplace members.

The FERC wants to ensure that the nation’s current and future energy needs will be reliably met (protected against natural and malicious outages) and to maintain an environmentally safe and secure infrastructure.

States want to protect the varied desires of their constituents, meeting their energy needs, environmental concerns, job stability, etc.

Thoroughly examining these different perspectives enabled me to formulate the following problem statement:
To transform the current electrical system into a more flexible and expandable system that reduces emissions of greenhouse gasses and other pollutants, by safely and reliably meeting electrical demands without impacting customer lifestyle, while using cost-effective, distributed, and centralized energy generation sources. This statement may seem obvious—indeed I was surprised it was not more complicated—but it is grounded in a systematic design approach to analyzing the problems facing the national grid and therefore not haphazardly conceived. Proposed solutions should strive to satisfy the problem, but a set of metrics is needed to compare competing solutions for the current system. Each attribute will become a metric once formally defined. This uniform definition is the next step of analysis, and I hope to follow up by working with the selected stakeholders to establish their relative importance. The metrics will not include values, as the goal of this effort was not to develop a specification for the design of a system upgrade, but to develop the tool for the evaluation of proposals.

I am currently applying to the SDM master’s program and intend to delve deeper into these issues for my master’s thesis.

Friday, October 9, 2009

Mobile phone industry calls for systems thinking - SDM Pulse Fall 2009

Ofri Markus, SDM 08, Senior Technical Account Manager, extensionEngine

Editor’s note: In his SDM master’s thesis, The Mobile Common: A Guide to Mobile Open Source and Its Effects on Mobile Device Manufacturers, Ofri Markus examined the mobile phone industry from a systems perspective in order to provide product managers with a guide to influences and developments likely to affect the industry’s future. In this article, Markus (who currently works as a senior technical account manager at Extension Engine) summarizes his findings.

I entered MIT’s System Design and Management (SDM) Program after working for 10 years in software development and telecommunications, first for the Israeli Air Force and later for Tadiran Telecom, a private telecommunications company. Although I already had a depth of understanding in my field, SDM appealed to me as a way to broaden my outlook. In fulfilling SDM’s requirement for a master’s thesis, I chose to examine the mobile phone industry from this broad, systems perspective, hoping to gain an understanding of ways in which product designers within the industry could prepare for the uncertain future.

To date, the mobile phone industry has experienced both slow, steady growth and giant leaps. Although the first public telephone call placed from a mobile device was made in 1973 (by Martin Cooper, who is considered today to be "the father of the mobile phone"), it took more than two decades for cellular phones to become widespread. What enabled the change was the transition to digital network technology (aka 2G networks), which allowed not only improved features and computing power, but also enormous cost reductions at all levels of the industry. In 1995 there were less than 90 million mobile subscribers in the world; by 2000 that figure had risen to 700 million.

For years, the mobile industry value chain was dominated by the mobile phone carriers. Stringent regulatory environments and high initial capital costs of infrastructure erected high barriers to entry for new players, leaving a handful of carriers in each market to compete for the business of several million customers. Carriers were therefore able to control the type of devices that would work on the network (in many cases, these were sold only by the carriers), applications for mobile devices, and the content that users could access via their mobile phone.

However, as customer demands grew, the mobile phone began to be perceived as not just a device for communicating using voice and text, but as a multimedia device, useful for entertainment, research, and information storage. At this point, the industry’s main players discovered what their colleagues in the PC industry realized years before—that versatility is the key to winning the hearts of customers. Platforms that provide the most features garner the most users.

In an MIT class called User-Centered Innovation in the Internet Age, Professor Eric Von Hippel discussed switching from "manufacturers’ innovation" to "user innovation," a recent trend in which companies abandon efforts to understand user needs fully themselves and choose instead to outsource innovative tasks to users equipped with appropriate toolkits.

That’s exactly what telecom carriers and manufacturers did. In order to cope with the massive need for innovation and understanding of user needs, industry players turned to their users, promoting an open operating system that allowed third-party software development.

In June 2001, Symbian released the first "open" operating system, which ran on the Nokia 9210 Communicator. In 2002, the first smartphone running Windows Mobile debuted. Both platforms provided open application programming interfaces (APIs) for software developers.

iPhone—Open or Closed?
Initially, open operating systems had little impact on the industry at large, affecting neither the business ecosystem nor customers’ expectations. But that changed in 2007, with the release of the iPhone.

Figure 1. Mobile phone subscribers per 100 inhabitants 1997-2007.

Although the iPhone is a closed source system, it had a profound impact not only on the dominant design of smartphones and on consumers’ expectations, but also on the balance of power in the mobile industry, changing the dynamic that existed among network operators, mobile device manufacturers, and software developers. For the first time, the device manufacturer had the upper hand: Apple (maker of the iPhone) was able to dictate terms to the carrier, AT&T.

AT&T gave up the power of dealing directly with applications developers, determining which applications go into the devices, and charging fees for that. Instead, Apple maintains these relationships and captures the resulting revenues.

The iPhone capitalized on the biggest advantage of open-source systems—third-party software development—by introducing the Application Store, a completely new ecosystem that allowed software developers to quickly and easily develop beautiful applications for iPhone, and sell them instantly to millions of iPhone users all over the world.

It seems that Apple has found a winning formula, gaining a high level of control of the design, features, and content in its devices, while maintaining enough openness to foster innovation and build a community of developers. Apple’s ability to gain control can be partly explained by what is perhaps its greatest resource—a brand name known for innovation, quality, and hype. While other reasons are less clear, Apple has been able to balance control and innovation to some degree with other products as well.

While some companies, including Palm and RIM, have tried the same tactics, other players have opted for an open source strategy.

Open source initiatives

Companies that make closed source products usually make money by selling the products. Since open source products are free to the public, companies that make and promote these products have to generate revenues in other ways. The most notable example is Android, an open source operating system for mobile devices based on the Linux kernel. Announced by Google in late 2007, Android has been adopted by many of the world’s leading device manufacturers as the future operating system for their devices. The main incentive for Google to release Android is expanding its advertising into the mobile arena and ensuring the availability of Google services on multiple devices.

Nokia, as a response to the Android threat, decided to open source its operating system, Symbian, and release it to the public. Although Nokia is a hardware manufacturer that is very good at making and selling devices, management realized that in order to stay in business the company needs to transform into an Internet company, providing additional services and complete solutions around mobile devices.

A changing industry

Now that consumers have gotten a taste of open devices and access to a variety of services, there’s no going back. It’s clear that the industry will need to accommodate more and more openness, from applications to operating systems, to meet consumer demand for total flexibility. The result is a profound shift in the current business ecosystem at all levels.

Mobile carriers risk losing control over the devices, applications, and content on their networks, ultimately becoming dumb pipelines. In spite of their awareness of this risk, the world’s leading mobile carriers are openly and broadly supporting open source platforms, hoping to gather consumers and manufacturers around them, and to create opportunities to provide unique content and services.

Application developers are currently enjoying an explosive demand for their services, as creators of potentially killer applications for device manufacturers and carriers. There is a risk, however, that this is a bubble that may burst.

New entrants are expected to join the mobile industry as device manufacturers using open source platforms. Many, however, are skeptical about their ability to create and capture value, due to the high barriers to entry beyond the cost of developing an operating system.

Although not all device manufacturers consider openness as a “strategy changing” trend, nearly all I spoke with during my research agreed it brings two major changes to the design and development process.

First, openness affects design, because working with open source components requires careful modularization of the products. Both development and maintenance processes need to be simplified because, if open source is used, these tasks will be decentralized among thousands of people and distributed over multiple locations.

More importantly, openness has changed the context in which mobile devices are operating. This context is evolving rapidly, and that is why systems thinking is so important in this arena. Companies—and in particular, incumbent product managers—must not think of their products a standalone devices or services, but as parts of larger, highly integrated systems that deliver value to users and fit into business ecosystems that support value creation and capture of value by players at all levels.

Could openness cause such vast changes in other industries as well? In light of the recent movement toward open source and open innovation in the academic and business communities, it is interesting to consider what advantages might accrue—particularly to such service oriented industries as health care and energy. These industries are facing great challenges and are in desperate need of innovation. Openness might help to foster solutions.

Thursday, October 8, 2009

Applying polymorphism in systems Engineering - SDM Pulse Fall 2009

By Christine Miyachi, SDM ’00

Editor’s note: Christine Miyachi is principle software systems engineer and architect at Xerox Corporation.


Christine Miyachi
As a software architect and systems engineer, I work with large systems that include software, hardware, and mechanical subsystems. In designing software and systems for a multifunction device that scans, prints, and faxes documents, I often find myself trying to translate software design principles to larger systems.

This kind of thinking is fundamental to MIT’s System Design and Management (SDM) Program, and as an alumna I frequently try to draw lessons from one domain and apply them to another. I like to ask myself, what is the essence of the principle and how can it be applied more broadly?

One particularly useful software principle is polymorphism, and I have recently been intrigued by the possibilities this software principle could hold for systems engineering as a whole.

In software engineering, it is understood that software objects should have only one function; yet the principle of polymorphism allows for abstract software objects to have more than one function.

The word itself derives from a Greek root meaning "having multiple forms." In object-oriented programming, polymorphism is the ability to execute a function specific to a context. The classic textbook example is shape objects. A shape is a general object and a circle and rectangle are more specific objects that inherit from a shape. A circle is a shape and a rectangle is a shape.

In a program, the shape object can be used to draw any shape without knowing what exact shape it is at compile time. So this is useful with software—less code makes it easier to understand the abstraction.

In the non-software world, physical objects can also have more than one function; systems engineers often want to fit many functions into a single piece of hardware. For example, in my SDM class in systems engineering, we talked about a seat cushion in a boat. The cushion serves two functions—as padding for a seat in one context and as a flotation safety device in another. The design of this seat cushion has been influenced by the fact that it has two functions. However it’s basic core function is to lift a human—whether it be on a seat or in the water.

The SDM program, which exposes students to experts from a wide range of disciplines, really emphasizes the value of identifying broader concepts that can be applied across domains. Having learned how such cross-disciplinary thinking can speed up the problem-solving process, I decided to examine how polymorphism could be useful in the design of larger systems.

Take vehicle manufacturing, for example. Imagine that you could drive a vehicle in the same way on the street, in the air, and in the water. You just knew how to drive and it worked the same way no matter where you were. That’s the essence of polymorphism, and that’s useful to the customers of my product—which is a machine that has multiple functions.

Using the vehicle example again, you can see how polymorphism could save unit manufacturing cost. If you want a vehicle that drives over land and floats in water you could buy two vehicles, one that runs over land and another that moves in water. Or, engineers could design you one vehicle that does both.

The multipurpose vehicle is more expensive than a single purpose vehicle, but should be less expensive than two vehicles (one for land, one for water). That is the challenge with polymorphism. If customers really want a multifunction device, and if we can find a way to reuse systems to perform multiple functions in a cost-effective manner, then polymorphism works for our business.

Polymorphism also has a role in product platform design. For example, a platform has a set of common functions. How that functionality is implemented will vary depending upon what system the platform is on. Consider an example from my product design and development class: a power tool served by a power supply that could fit onto a variety of tools and be switched between them. Like the shape and the draw function, the basic functionality of obtaining power remains while the function of doing the work varies from tool to tool.

Of course, polymorphism isn’t always the best idea. In product design, there are tradeoffs when hardware has multiple functions. For example, a seat cushion that did not have to be a flotation device could be made of a wider variety of materials and could be made more comfortable to sit on.

Here’s where software and manufacturing design differ. In software, polymorphism doesn’t require tradeoffs as far as the function of the object goes. Notice in the shape example, that during run time of the code, the shape object will always be either a circle or a square—a distinct object with only one purpose. The shape object is never actually created in software, but used as an abstract reference. With physical objects, in contrast, an artifact needs to be two things at once. The tradeoffs are evident in the physical object, where in software, there is no tradeoff in the objects themselves.

Polymorphism does have an expense associated with it and should be used only when you need different functions in different contexts. The base functionality should be the same in both contexts—to draw a shape, to drive a vehicle, to lift up a person, to power a tool.

But overall, polymorphism is a powerful design pattern, popular in software, that can be used in larger systems to build in flexibility in product design. I believe this principle will be increasingly useful in the design push to build smaller, cheaper, better products for our customers. It may also become more useful as one moves to more abstract levels of system design such as axiomatic design.

Wednesday, October 7, 2009

SDM provides common language, practice space, feedback - SDM Pulse Fall 2009

By Ellen G. Czaika, SDM ’08

Editor’s note: Ellen G. Czaika recently served as a teaching assistant for the System Design and Management Program’s core course in systems engineering.


Ellen G. Czaika
MIT’s System Design and Management (SDM) Program teaches and develops systems thinking as a formidable approach to large, complex, globally relevant problems. SDM matures systems thinking and systems engineering skills by establishing a common vocabulary among students, giving them space to practice, and providing feedback and guidance within an international context.

Each SDM cohort represents nationalities and cultures from all over the world, with backgrounds in multiple areas of science and engineering, and in various types and sizes of firms and organizations. SDMers have an average of 8-10 years of work experience, replete with interesting observations, experiences, and lessons learned. This international constitution and disciplinary diversity necessitate the use of a common vocabulary, as students often start off using similar words to describe different concepts or a variety of words for the same concept. The common language establishes a community wherein students can practice and receive feedback; it is used throughout the SDM core curriculum (including the course in systems engineering).

Project work in SDM’s carefully designed core classes provides opportunity for practice. Each of the projects tackled in the systems engineering class addresses a complex, real-world problem that requires students to dive into the inner workings of a system—and to explore the system’s interactions with its surrounding context or ecosystem. The concreteness of the problems complements the fundamentals taught through course lectures and supplemental readings.

Students choose teams, then identify a globally relevant complex problem for another team in the class to address. This structure is unique to the systems engineering class and creates an added layer of learning because the team proposing the problem serves as the stakeholder representative to the team working on the problem.

In proposing a project, each student team assesses a problem for its level of complexity and impact—and also to ensure the problem involves human components such as cultural factors and government regulation. Three of the 16 projects undertaken this last semester involved an energy-efficient household, a nationwide health information network, and traffic congestion in Los Angeles.

Throughout the semester, each student team meets with its faculty advisor and its student consultant team. Midterm progress reports and final presentations to the class and a team of judges emulate realworld presentations to customers. Delivered over the course of two extended class periods, the final presentations provide juxtaposed examples of the systems engineering tools utilized in 12-16 diverse problems and contexts. Questions and discussions about the project work and the teams’ application of the fundamentals provide feedback to student practice. The opportunity to learn was increased significantly because all of us used the common SDM language.

As a student in this class, I found that working on my team project—clearing the ground of land mines left behind after wars—helped me better understand complex interrelationships in systems problems and the nuances of stakeholder needs. The military has several solutions for detecting and clearing mines during conflicts, but these solutions are expensive and/or difficult to learn to use. Our project specifically focused on the communities in former war zones and how they can clear their own land effectively, safely, and inexpensively.

I loved that this project addressed a real human need and did so from the point of view of the true beneficiary: people who want to walk safely through their fields and streets. In addition to considering technology, reliability, and usability issues, we also had to consider affordability, the cultural preference for employing humans rather than machines, and the insidious creativity that mine makers employ to disguise and build land mines.

More pieces fell into place in my understanding of systems engineering this summer when I served as the teaching assistant for this class. The SDM ’09 cohort came up with a new set of projects for each other, which included the projects noted above, plus reducing waste in the medical industry, addressing open-seas piracy, educating engineers using a systems approach, and modernizing the income tax system, among others.

Interestingly, this year we had four teams that each addressed different elements of the challenge presented by alternative fuel vehicles. Observing the subtleties of how different teams approached not completely distinct problems in distinctly different ways enhanced the learning experience, adding a layer of nuance. Faculty and student questions provided feedback to the class teams’ practice, further refining understanding.

SDM has been an incredible experience for me; it has both broadened and deepened my thinking while providing a language and structure to guide me in communicating these thoughts, space in which to practice, and valuable feedback. And, very importantly, SDM has introduced me to a community of people from around the world who share a systems thinking mindset and global awareness. SDM truly creates cohorts of students equipped to apply systems thinking to the world’s most pressing problems.

Tuesday, October 6, 2009

Integration project puts SDM lessons to work - SDM Pulse Fall 2009

By Luke Cropsey, SDM ’08

Editor’s note: This is the fourth in a series of articles by SDM alumnus Luke Cropsey, who synthesized resources from four communities—the Lean Advancement Initiative, the Systems Engineering Advancement Research Initiative, SDM, and the US Air Force—to develop an overarching systems-based methodology for addressing the complexities of integrating unmanned aircraft systems into the National Airspace System. In this article, he offers his final observations on this process. (For previous Cropsey articles, view the SDM Pulse online at sdm.mit.edu/news_archive.html.)

"A mind once stretched by a new idea never regains its original dimension," said Oliver Wendell Holmes—and that’s certainly been my experience at MIT.

MIT’s System Design and Management (SDM) Program has irrevocably changed my perspective, my approach to solving problems, and my way of framing issues when managing complexity of any sort. Just 18 months ago, my approach to designing and managing integrated systems and enterprises lacked structure. Now I am equipped with a variety of tools to break down and analyze complex problems, as well as to formulate solutions.

To review, Figure 1 illustrates the sequence of analytical steps I used in my effort to integrate unmanned aircraft systems into the National Airspace System—a complex challenge made more difficult because critical stakeholders had different ideas about what they wanted. I relied on several tools to align definitions of value and deliver the desired enterprise attributes: the enterprise purpose statement, the X matrix, an adaption of object process methodology, and finally, the enterprise transformation roadmap.


Figure 1.

Going through each analytical step illuminated some key lessons.

1) There are three rules to success in the lean, value focused thinking approach: value, value, value.

It is impossible to overemphasize this point. Companies need to make the effort to correctly elicit and identify the value needs of key stakeholders within an enterprise. Everything hinges on this task, and any and all pressures to move forward before the value identification phase is successfully concluded should be steadfastly resisted. Until a clear purpose statement exists that describes the desired end-state, any effort to move the enterprise forward is a high-risk endeavor at a minimum and recipe for disaster at worst.

Value—the architect’s first task is to acquire a clear and accurate understanding of each stakeholder’s value definition. These definitions provide the foundation for a successful solution.

Value—the second task is to define the enterprise so that it will deliver value for those both above and below the enterprise. A clear, unambiguous purpose statement that aligns with the needs of external stakeholders creates the prerequisites needed to flow value through the entire value chain, not just the enterprise.

Value—the third task is to align stakeholder value definitions within the enterprise. If the first two value conditions have been accomplished successfully, this final alignment will ensure value delivery to all stakeholders.

2) Qualitative analysis does not mean "by-the-seat of-your-pants." Analytical rigor counts.

Just because an issue cannot be neatly and quantitatively assessed doesn’t mean that all ideas will work equally well. Doing a good qualitative analysis is hard, consumes creative energy, and requires innovative thinking—but it is the only way to provide high-confidence, defensible, and well-structured solutions to otherwise intractable problems.

The challenge is: you have to be willing to invest in understanding what is important to other people and how that drives behavior. A rigorous methodology forces people to articulate values that might otherwise remain in the background, ensuring that you get the best going-in solution possible—as well as the evidence you need to persuade other people to buy into the value proposition that is created at the enterprise level.

3) Insight and innovation occurs at the intersection of dissimilar bodies of knowledge.

This is by no means an original flash of brilliance on my part. Both Professors Eric von Hippel and Thomas Allen discuss the dynamics of this effect in their respective courses at MIT. Indeed, MIT’s Engineering Systems Division (including SDM) pools talent from across the engineering and management disciplines precisely because that fosters innovative approaches to old and new problems alike.

Nevertheless, the truth of the observation struck me as never before as I worked through my analysis for the US Air Force. The combination of different approaches, tools, and perspectives laid the foundation for true insight into how to architect a solution for the unmanned aircraft systems airspace integration problem that had eluded me for two straight years working the problem in my day job.

The difference stems from having an intentional process by which to bring together dissimilar bodies of information in a controlled manner. Too often organizations are satisfied with an almost random or haphazard level of innovation. But without a structured process, dissimilar bodies of knowledge will typically collide rather than intersect.

One of the long-term benefits of SDM, which I am only now just beginning to appreciate, is the fundamental shift in the way that I think about innovation. SDM provides the tools and methodologies needed to successfully integrate disparate bodies of knowledge into efforts that will consistently yield innovation opportunities. Notice I said "opportunities." This is not to say the next "killer app" can be reduced to a series of repeatable steps. However, with the right tools, methodologies, and mindset, it is possible to create an environment in which innovation can thrive and grow instead of showing up by accident.

This is the most valuable lesson I learned from working at the intersection of the LAI, SEAri, SDM, and The Air Force bodies of knowledge in my research. In the final analysis, it was the synthesis of these four perspectives into an integrated methodology that paved my way forward.

Integrating knowledge

Each of the above-mentioned organizations made key contributions to my research in ways that were both distinct in nature and that built on the strengths of the others (see Figure 2).

Figure 2.

The Lean Advancement Initiative taught me the importance of value definition. No matter what the context or the nature of the task at hand, properly identifying what is of value to those involved is always the first step to success.

The Systems Engineering Advancement Research Initiative provided the needed methodological rigor and practice for me to move beyond an ad hoc application of enterprise architecting principles and to implement a full, systematic approach grounded in solid research techniques and principles.

The US Air Force, my employer, demanded practical, implementable results, which kept the "so what" of this research constantly at the forefront of my mind.

SDM provided the systems thinking imperative, management tools, and architecting framework to crank through the mechanics, making everything work together to produce the desired results.

However, it would be a mistake to think that rigor can create a completely objective view of the squishy, softedged problems that are typical of today’s complex socio-technical systems. Rigor can induce repeatability into the process, but not objectivity. At the end of the day, much of the system and enterprise architecting work that is at the heart of the research I’ve presented is still very much an art form. As with most complex undertakings, there is no substitute for experience.

Eight months after graduating, I find myself digging into the MIT tool bag on an almost weekly basis. The SDM way of thinking keeps finding new outlets for expression—even now that my job no longer has anything to do with unmanned aircraft systems.

It used to be that when people asked me what I did, I would tell them I was an engineer. Now I borrow a line from Professor Edward F. Crawley and tell them I manage complexity, reduce ambiguity, and focus creativity—in short, I architect solutions to problems.

Oliver Wendell Holmes knew what he was talking about.

Monday, October 5, 2009

SDM portfolio evolves to serve global business - SDM Pulse, Fall 2009

By Lois Slavin, SDM communications director

Created in 1996 in response to industry’s need for technical professionals who could lead across organizational boundaries, MIT’s System Design and Management Program (SDM) is at the forefront of graduate and executive education. Its portfolio of career-compatible offerings, including a master’s program, a systems engineering certificate program, and an organizational leaders seminar series, incorporates state of-the art on-campus as well as distance learning options, flexible matriculation options, and an interdisciplinary perspective.

SDM Industry Codirector John M. Grace notes that because SDM combines business courses from the MIT Sloan School of Management and technical courses from the MIT School of Engineering, it provides graduates and their employers with a unique competitive edge. “SDM’s interdisciplinary curriculum teaches systems thinking and leadership geared specifically for engineers who want to collaborate and innovate in both technical and nontechnical arenas,” he said. “For this reason, SDM goes beyond the MBA and traditional executive education programs.”

The centerpiece of SDM’s portfolio is its rigorous 13- to 24-month graduate program. Originally created for corporate-sponsored students as a 24-month master’s program that could be taken primarily at a distance while students continued to work, SDM has evolved with the marketplace over the years. Its master’s degree program can now be taken in 13 to 16 months on the MIT campus or in up to 24 months either on campus or primarily at a distance (some on-campus time is required). Graduates receive an MS in engineering and management conferred by MIT Sloan and the School of Engineering. Several SDM alums have also gone on to pursue the ESD PhD.

Grace explained that SDM’s evolution is not surprising, as one of its primary academic thrusts is new product development with an emphasis on how to evolve products in an ever-changing world.

“The economic conditions and the increased scrutiny of the cost of fully supported educational programs in the late 1990s caused many of SDM’s founding companies to reduce the number of their employees fully sponsored in the program,” he said. “We found, however, that a larger number of self-sponsored students were applying and that they wanted to be on the MIT campus. This led to the development of flexible options that enabled students to complete the master’s program according to their needs.”

Today, thanks to lower costs in distance learning technologies, an SDM cohort is almost evenly split between on-campus and at-a-distance students.

What hasn’t changed—although it is continually updated to reflect the latest research—is SDM’s foundation: core courses in system architecture, systems engineering, and system and project management and their integration with classes in engineering and specially designed courses in management. Today, whether students enroll as fulltime on-campus students or part-time commuters/ distance learners, all SDM fellows work together in global teams on class assignments throughout matriculation.

As a result of the success of the master’s program, SDM has developed a portfolio of complementary programs. These include the one-year graduate certificate in systems engineering, offered at a distance in conjunction with three one-week business trips to MIT, and an oncampus seminar series in system engineering for organizational leaders. These programs address the corporate need to embed systems engineering principles and practices into the organization.

“SDM will continue to evolve with distance technologies and the need for technically grounded systems thinkers,” Grace said.

For further information, please contact John M. Grace, SDM industry codirector, at jmgrace@mit.edu or 617.253.2081.

Sunday, October 4, 2009

SEAri summit to highlight latest research - SDM Pulse, Fall 2009

The MIT Systems Engineering Advancement Research Initiative (SEAri) will present ongoing research related to the theory, method, and effective practice of systems engineering at its annual research summit on October 20, 2009, at the MIT Faculty Club.

The SEAri summit provides an opportunity to share research outcomes and in-progress efforts, and engages attendees in a dialogue on needs and problems facing the systems community.

“This event provides insight that enhances our research program while expanding our understanding of how research outcomes can be applied in practice,” said SEAri Director Donna Rhodes.

SEAri’s research projects run the gamut from exploring design tradespaces to socio-technical decision making. Topics include methods and practices for evolving systems of systems, leading indicators for predictive program outcomes, economics of human systems integration, and systems engineering practice in the enterprise.

SEAri works across multiple domains, including aerospace and defense, intelligence, transportation, and energy on a multinational basis. “Our research portfolio is designed to blend theory-based and practice-based approaches to result in predictive approaches for implementation by practitioners,” said Adam Ross, SEAri’s lead research scientist.

Several important theses were completed in 2009, and alumni will present these results at the summit. Interim results of the research projects have already been shared at various conferences this year, receiving positive recognition—including the IEEE systems best paper award for student research. SEAri authors also received a best paper award from the International Council on Systems Engineering.

The summit will also feature a student research poster session, a highlight of last year’s event.

For more information or to attend the invitation-only summit, visit the SEAri website at seari.mit.edu or contact the leadership team at seari@mit.edu.

Saturday, October 3, 2009

SDM culture embraces broad view of diversity - SDM Pulse, Fall 2009

By Lois Slavin, SDM communications director

From its inception and throughout its evolution, diversity has been a key component of MIT’s Systems Design and Management (SDM) Program. Systems thinking—the hallmark of SDM—requires an ability to appreciate and embrace diversity, so SDM has always sought students from a range of academic, professional, and personal backgrounds.

Diverse project teams in SDM classes are purposely
created to maximize students’ learning from their peers
in other industries and functions. This team shows
the results of its first design challenge—a remote
controlled robot. Members, from left to right, are:
Haiying Ren, project manager at Pratt & Whitney;
Arlan Sheets, project team lead at Raytheon Company;
Rajeev Kozhikkattuthodi, integration services delivery lead,
Tata Consultancy Services; Daniel Ledger, web tools
product manager, Analog Devices; Mark Moran,
technology architect, John Deere; and Jui Lim,
senior product manager, Amkor Technology.
Diversity at SDM both embraces and goes beyond the traditional categories of race and gender, said SDM Industry Codirector John M. Grace. “Because SDM is interdisciplinary and much of the academic work is team-based, we carefully select each year’s cohort to include not only women and underrepresented minorities, but mid- to upper-level managers who have a wide range of industry experience,” he said.

The SDM class that began the program in January 2009 is no exception. Almost 20 percent are women, including an MD and research fellow at Massachusetts General Hospital, an engineer at Sony Ericsson Mobile Communications, and a strategic planner in naval operations at Sikorsky Aircraft. The men are equally diverse, including a senior engineer from John Deere, a design engineer from Ford of Mexico, a director at Blackrock investment firm, and an assistant engineer from the United Nations.

The 2009 cohort also brings cultural, linguistic, and geographic diversity to the program. Members hail from across the United States and around the world, including India, Russia, China, Chile, Malaysia, Mexico, Pakistan, Singapore, France, Germany, Greece, Thailand, and Cote d’Ivoire. Students have experience in a range of industries—from automotive and aerospace to high-tech and the military, and a variety of companies—from IBM and Microsoft to Lockheed Martin and Boeing. They hold such positions as program director, senior engineer, technology architect, software development engineer, and R&D manager.

Grace notes that for virtually all projects except SDM’s required thesis, students are assigned to teams that are intentionally mixed. “This enables the students to learn from each other by sharing different perspectives and experiences. Knowing how to work together effectively is a critical attribute in today’s global marketplace,” said Grace. “It will serve them and their employers well.”

To continue to recruit the best and the brightest, an important component of SDM’s marketing involves reaching out to professional organizations, such as the Society of Women Engineers (SWE) and the Society of Hispanic Professional Engineers (SHPE). For example, in March 2009 SDM hosted a special information session at the MIT Faculty Club exclusively for members of SWE’s Boston chapter. SDM received special recognition at the chapter’s annual membership meeting and banquet for its support of SWE’s professional development and outreach programs.

SDM also plans to recruit potential students at the annual SHPE conference in late October 2009.

Grace said that SDM welcomes inquiries from human resources professionals at companies that may be interested in sending students to the program. For further information, please contact John M. Grace, SDM industry codirector, at jmgrace@mit.edu or 617.253.2081.

Friday, October 2, 2009

Three from ESD win Best Journal Paper Award - SDM Pulse, Fall 2009

Three members of MIT’s Engineering Systems Division (ESD)—the administrative home of the System Design and Management Program—recently received the 2008 Best Journal Paper Award from the International Council on Systems Engineering (INCOSE).
ESD research scientist Adam Ross (in striped shirt), joins co-author
Senior Lecturer Donna Rhodes and INCOSE President Pat Hale (who
also heads the SDM Fellows Program) in Singapore after receiving
the 2008 Best Journal Paper Award from the International Council on
Systems Engineering (INCOSE). Their co-author, Professor Daniel Hastings,
was unable to attend the symposium.

ESD research scientist Adam Ross, along with coauthors Senior Lecturer Donna Rhodes and Professor Daniel Hastings, were honored for "Defining Changeability: Reconciling Flexibility, Adaptability, Scalability, Modifiability, and Robustness for Maintaining Lifecycle Value."

The award was presented at the 19th annual International Symposium of INCOSE on June 13, 2009, in Singapore. The paper appeared in the fall 2008 issue of INCOSE’s scientific journal, Systems Engineering, which disseminates scholarship to practitioners and academics in the field of systems engineering.

The winning paper, which is an extension of Ross’s doctoral work, describes how designing and maintaining systems in a dynamic contemporary environment requires a rethinking of how systems provide value to stakeholders over time. Any ambiguity in the definition of “value” used in various system domains can derail the success of the system. And yet, decision-makers tend to change their minds over time, thus shifting their views about value.

Developing either changeable or classically robust systems are approaches to promoting value sustainment. But, ambiguity in definitions across system domains has resulted in an inability to specify, design, and verify to the qualities (what system thinkers often term “ilities”) that promote value sustainment. In order to develop domain-neutral constructs for improved system design, the definitions of flexibility, adaptability, scalability, modifiability, and robustness are shown to relate to the core concept of “changeability,” described by three aspects: change agents, change effects, and change mechanisms.

Since change is inevitable, a truly “value-robust” system must be one that can continue to provide value to stakeholders over time, in spite of changes in contexts, the authors assert.

Several SDM students have been involved in research related to this topic, which is ongoing within the MIT Systems Engineering Advancement Research Initiative.

For more information about INCOSE, visit www.incose.org.
For more information about SEAri, visit seari.mit.edu.

Thursday, October 1, 2009

Annual conference addresses health care, energy, environment - SDM Pulse, Fall 2009

Knowing is not enough; we must apply.
—Johann Wolfgang von Goethe


Some of the most accomplished systems thinkers from MIT and industry will convene at MIT on October 22–23, 2009, for the annual MIT conference on systems thinking for contemporary challenges, sponsored by the Institute’s System Design and Management Program (SDM).

Speakers at this year’s event will discuss best practices for applying systems thinking to four critical and complex global challenges: health care, energy, space, and the environment. The conference is designed to provide practical information to attendees that can be applied to interdisciplinary challenges within their own work environments and extended to diverse stakeholders both inside and outside of their organizations.

MIT Associate Professor Olivier L. de Weck, associate director of the MIT Engineering Systems Division, will open the conference with a talk that outlines some of today’s most pressing societal challenges, laying out the case for taking a systems approach to finding solutions.

He and others from MIT, including Institute Professor Joel Moses, will frame the three-fold nature of systems thinking—technical, managerial, and socio-political—and outline how it is being applied in the critical areas.

Industry leaders will describe best practices that demonstrate the challenges they face within and outside their organizations, the benefits achieved through systems thinking, and the lessons learned that illustrate the need for a more holistic view of complex systems.

The first day’s talks, focusing on energy, space, and sustainability issues, will highlight experiences from within NASA, IBM, GE, John Deere, and the MIT Energy Initiative. On day two, speakers will focus on health care issues, providing perspectives from academia as well as from Partners HealthCare and Beth Israel Deaconess Medical Center.

The conference is open to members of the SDM community and invited guests. If you would like to attend, contact John M. Grace, SDM industry codirector, at jmgrace@mit.edu or 617.253.2081. Additional information is available at sdm.mit.edu/conf09.