Systems engineering saves the day!

Cecilia Haskins Alexander Welland

NTNU Dept. Industrial Economics and Aker Solutions
Technology Management alexander.welland@akersolutions.com
haskins@iot.ntnu.no

Copyright 2012 by Cecilia Haskins and Alexander Welland. Published and used by INCOSE with permission.

Abstract. This paper is an experience report about how adding a systems engineer to a project
helped the team achieve a second-place result in a competition despite overwhelming technical
and programmatic obstacles. The setting of the case in this report is Trondheim where the
co-author joined a student team that should design and construct a car to compete in the Shell
Eco-marathon. The project started August 2010 and ended May 2011, but the systems engineer
joined the project late, and started his work in the middle of January 2011. The paper takes the
reader on a journey following the steps taken to introduce and apply systems engineering
techniques in a project that was time and resource constrained. The paper demonstrates the
effectiveness of simple techniques, such as the Systems Engineering Wall, to implement
systems engineering practices and improve team communications. The conclusion is that the
systemic and systematic approaches of systems engineering, in this instance, helped the team
achieve a winning result.

Introduction
The Shell Eco-marathon (SEM) is a worldwide competition to challenge students to design,
build and run the ultimate fuel-efficient vehicle (Shell 2011). The Norwegian University of
Science and Technology (NTNU) has competed in the SEM since 2008 and still holds the
world record within the Urban Concept Fuel Cell class (Shell 2009).

However, following their first class performance in 2009, the 2010 SEM team experienced
problems with further development of the car. They did not allocate any time for integration
testing before the race. And, although every component worked well individually, as a
complete system the car failed. When they participated at the race site they were rejected due to
problems with the brakes, hydrogen system and control system. There was no result in the 2010
SEM from NTNU (Stockfleth, et al. 2010). The goal of the 2011 team was to win again in the
Urban Concept Fuel Cell class.

Understandably, the team corporate sponsor was hesitant about continuing their support, and
delayed their decision until late in December 2010. Until then, the team was understaffed and
morale was low. When the sponsor commitment was received, the small team realized that they
needed to add a systems engineer to have any chance of success. Finally, in January, the team
reached full strength with one project manager, one systems engineer and 5 engineers with
educational backgrounds in mechanical, ICT and Cybernetics. The complete team totaled 17
with external help with expertise in media, chemical engineering, industrial design and
telemetrics.
 Background
The Shell Eco-marathon Project 2010/2011 at NTNU is the subject of this case history, which
was a practical application of systems engineering (SE) with one novice student systems
engineer co-coordinating the technical efforts through interaction with his team members. The
data collected includes the results from requirements collection to the verification phase, test
results and validation, the technical inspection and ultimately the competition. Conclusions
about the process and final results were drawn from this data and feedback from the team
members about the use of systems engineering in the project.

It should be noted that the SE methodology used was tailored by the student to fit the
circumstances of the project; namely a challenging problem, a very tight schedule, limited
resources, and a customer/sponsor who expected superior results. The description of the case
does not include a comprehensive description of the work, but follows a thread of examples
where systems engineering demonstrated some value to the project.

The novice systems engineer took inspiration from literature on prior projects in which SE
provided measurable value in the areas of time reduction, cost reduction and overall value. One
such example was found in an article, which reported on automobile prototype development
delivering in record time Dodge Neon, Ford Mustang, and Lincoln Continental prototypes by
creating a close relationship between the OEM (Original Equipment Manufacturer)
development team and the supplier company engineers. Such an approach required increased
communication effort between OEM and supplier but improved the outcome by making both
of their perspectives fully available early in the development cycle (Vanek, Jackson and
Grzybowski 2008).

As indicated, the 2010/2011 team struggled under the legacy of the prior year when the car was
not permitted to compete. Two areas received special attention; first, the need for careful
project planning and the inclusion of a project manager on the team. Second, one of the team
had just taken the systems engineering course offered in the spring 2010, and with his
encouragement, the team also recognized the need for a systems engineer to reduce the risk
when developing the car, coordinate team efforts, and organize the testing.

Research questions. The student systems engineer formulated the following research
questions to direct his readings and guide his thesis activities:

Is there any value having a systems engineer in a time constrained project?

How do a Project Manager and Systems Engineer work together on a project and is Systems
Engineering beneficial for the Project Manger?

Collaboration between project manager and systems engineer

Systems engineering is an inherent part of managing a successful project and helps guide the
engineering effort. This is done by setting objectives, guiding execution, evaluation of results,
and prescribing necessary corrective actions to stay on course. Management of the planning
and control aspects of the project fiscal, contractual, and customer relations is supported by
SE but not considered to be a primary SE responsibility. Recognition of the importance of SE
in a project is achieved by formally assigning the leader of the SE team both authority and
technical responsibility (Kossiakoff and Sweet 2003). Expressed another way, systems
engineers focus on delivering quality, while project managers focus on time and resource
management (Sage and Rouse 2009). However, there is an essential need for continual
communication between the systems engineer and the project manager (Bahill and Briggs
2001).

Kossiakoff and Sweet (2003) suggest that the common processes shared by the systems
engineer and project manager include task definitions, configuration management, risk
management and customer interaction. Project planning is necessary to establish the
infrastructure and direction, assess and control the progress of a project, and identify the details
of the work and the right set of personnel, skills, and the time and resources needed.

Systems Engineering Plan. The Systems Engineering Plan (SEP) is the top level plan for
managing the systems engineering effort, which is an essential for both the systems engineer
and project manager. It should be written to clearly explain how systems engineering will be
used during the project to avoid unnecessary discussions later (Haskins 2011). The project
manager uses the SEP in the project assessment and control process to generate the project
status report on a periodic basis. This information is used to analyze the health and maturity of
the project work effort. One important overlapping area that is closely monitored is
configuration management and changes to the baseline.

Risk and Opportunity Management. There are two basic types of risk within a project;
technical risk and programmatic risk. Technical risk refers to risk that the system fails to meet
its performance objectives; in this case, that the vehicle is disqualified or unable to compete.
Programmatic risk refers to two major subcomponents of cost overrun and delay in schedule
(Pennock and Haimes 2002).

During a project it is important to continuously assess risk. The cause and sources of problems
continue to evolve and change during the project progress, which leads to shifting priorities
over time (Pennock and Haimes 2002). In a project, this activity is shared between the systems
engineer and project manager. Generally, the technical risk belongs to the systems engineer
and the programmatic risks are handled by the project manager. However, the risk management
process should be a cooperative process between the systems engineer and the project manager.

Systems engineering to facilitate teamwork

Haskins (2008) extracts six attributes of systems engineers from a comparison of activities
commonly used in twelve of the most often referenced systems engineering frameworks. The
6Cs is a meta-framework of systems engineering enablers where the Cs stands for;
Comprehension, Communication, Coordination, Collaboration, Cooperation and Continuity.

Comprehension, Communication. In this project, the primary contribution of the systems

engineer was to keep communication channels open, and to create effective coordination
within the team of engineers. The systems engineer needed to be able to talk not only to the
engineers, but also to the stakeholders and customers. To function in this role, the systems
engineer needs to be knowledgeable in a multidisciplinary domain and able to listen well.
Coordination, cooperation, collaboration. Despite the similarity of helping people work
together, these enablers describe activities at different levels of the project hierarchy.
Coordination achieves a harmonious interaction between parts or personnel for effective
results. Interpersonal interactions are one of the biggest challenges for large projects and also
for projects under demanding schedules. Cooperation is achieved when a group of persons
work together toward a single goal or objective. It is the systems engineer who brings the
specialist engineers together and provides the linkages that make up a team. Collaboration
efforts are required when working together with people or agencies that are not directly
connected to the team, for example, the sponsor stakeholders.

Continuity. One might consider that this enabler is not needed for a four-month project.
However, as in the automobile industry where the development of a complete new car from
scratch is seldom done, this team needed to build on prior years contributions and extract
knowledge from whatever documentation could be uncovered, or perform reverse engineering.
Likewise, this project team was determined that they would leave a legacy of robust drawings
and documentation to future teams.

Additional attributes also were observed as important to ensure the smooth functioning of the
SEM team; namely, trust, simplicity, and change.

Trust. A culture of constructive confrontation pervades a project organization. When it comes

to applying the SE process, the project team must understand, respect, work and behave within
the defined process. Baseline management and change control is achieved by formal, oral
agreement based on make a promise, keep a promise. The decision gate agreements should
be confirmed with a binding handshake. The team constantly looked explored opportunities
and areas to reduce risk by capitalizing on expert consultations and rapid model verification.
Issues were actively sought, identified and recorded, and everyone felt empowered to identify
an issue and pass it on to the team. The goal was that no issue should be left unresolved and the
entire team took ownership for success; it was never someone elses responsibility. When it
came to personnel, the project was built around motivated individuals. They worked within an
enabling environment with the support they needed, and the mutual trust that they would get
the job done (Haskins 2011).

Simplicity. Implementing the SE process within the team was reduced to three simple rules;
facilitate communications, streamline controls and simplify paperwork. The way to effective
SE management was not through formal, formidable, massive documentation, but rather by
creating an interactive environment, which was conductive to the emergence and effective
utilization of creative and inventive talents oriented toward achieving a system approach with a
minimum of extraneous encumbrances (Haskins 2011).

Change. Coping with change was an important contribution of systems engineering where the
activities helped the team to detect changes between, for example interfacing components, so
that the responsible person was informed, and could make changes to the subsystems before the
design matured. Among other things, this reduced the risk of manufacturing wrong parts.
Change risk management can be illustrated and visualized and should be based on reliable
estimation e.g., on simulation (Fricke, Gebhard and Negele 2000).

Research questions revisited. The student researchers were convinced that SE and PM should
work closely together during the project and that it was important that the different work areas
were defined clearly for both disciplines. The most overlapping areas between SE and PM are
risk management, coordination and configuration management. The literature puts much
emphasis on good communication. If everybody understands the value and rationale for using
systems engineering, it should be easier for the team to actually use the tools. Commitment to
the process created a discipline such that the team did not succumb to temptations to skip
important activities because time was constrained.

Systems engineering in the Shell Eco-marathon project

This section describes the major activities and recounts some specific instances of both how
systems engineering was applied in this project, and how it sometimes made a difference to the
outcomes of the 2010/2011 Shell Eco-marathon project (SEM). This section is based on the
masters thesis submitted by Welland (2011).

Educating the Team. Before the systems engineer joined the team in January, the core team,
including the project manager, received a brief training session given by Dr. Haskins. This
convinced the team how important it was to have a systems engineer on board before further
development of the car, primarily to reduce the risk of making the same mistake as the prior
years team.

Shortly after the systems engineer, Alexander, joined the team, it was decided that there should
be a whole day devoted to systems engineering to explain why a systems engineer was included
and to get the whole team involved with defining the needs, gather documents for
requirements, agree upon the system boundaries, define the system architecture, and identify
the interfaces between the subsystems. The days agenda was lead by the systems engineer as a
demonstration of his potential contributions to the SEM team. The day went smoothly, and all
primary objectives were met.

After the systems engineering day the whole team shared a mutual appreciation of the
importance of the SE methodology. One important lesson learned during the systems
engineering day was that the team members should not make hasty decisions early in the
project, but rather collect the right information and do a thorough analysis to reduce the risk of
rework or going forward and facing the consequences of making the wrong system. The Gantt
chart that was made by the systems engineer and project manager to establish deadlines and the
SE milestones through the available project time proved invaluable during the remainder of the
project.

Architecture. To create an initial system baseline, the systems engineer created an Architecture
Design diagram. The final version of this diagram, which was continuously updated, is
provided in Figure 1. The Architecture Design itemized the 10 subsystems with the different
components making up the complete system. Simplicity was essential during this process, and
defining the system in a more detailed manner would result in making the process too complex.
Next, the responsible owners of each subsystem established a baseline configuration. Each
team member owned at least one subsystem based on their educational background and
expertise.
 Figure 1. The Final Shell Eco-marathon NTNU architecture (Welland 2011)

During the project, the team members were glad that the system had not been defined in more
detail. Feedback from the team members was that at a more detailed level, the complexity
increased which may have led to more confusion and less overview of the system both for the
engineers and the managers. This was critical and very beneficial during the project. Another
key point was making the subsystems and the components traceable. This was done by
assigning a letter and number on each subsystem and components such as S.1 Body and S.1.1
Chassis etc. This made it easy when allocating requirements to each subsystem. A second
reason for making the baseline traceable was to make all the documents produced from the
systems engineer beneficial for the next years SEM team. Traceability in the documents
should make it easy to modify and continue with further improvement of the system. The
architecture design provided an easy to follow overview of the complete system, but did not
show the connections and interaction of the subsystems.

Interfaces. After defining the architecture design, the process of analyzing how the different
subsystems interacted with each other started. The whole team gathered to analyze and define
the subsystem dependencies and interfaces. Basic tools such as whiteboard and markers were
used. The whole team contributed and there was a good discussion about where and how the
interfaces between different subsystems should be set. There was also a discussion between the
team members about the detail of the subsystems. The decision was made during the analysis
that all the subsystems were made up of the different subcomponents. The systems engineer
also defined responsible engineers between the interfaces which turned out to be a really
important decision to minimize the risk of confusion later in the development of the system.
The result of the interface documents led to changes in the placement of the engineers in the
office, where people with a lot of interfaces sat together so the communication was easier. A
further development of the interface document, to relate to the car design was made by the
systems engineer to get a better illustration of the system dynamics. This is illustrated in
Figures 2 and 3. The system was divided into two documents for electronic and mechanical
interfaces respectively.
 Figure 3. SEM car electronic interfaces (Welland 2011)

Figure 4. SEM car mechanical interfaces (Welland 2011)

Requirements validation. The system needs and requirements for the SEM car used the
official rules from Shell as source documents. All data from Shell was analyzed to define the
NTNU project requirements, since the goal of fulfilling the requirements from Shell would
qualify the car for the competition by passing the technical inspection. If the requirements
could not be validated at SEM, the risk of losing time by doing modifications to the car at the
race site could jeopardize the outcome. The systems engineer made a Total System
Requirements document connecting all the requirements from Shell mapped to the different
subsystems using the specified subsystem ids to improve traceability.
When the system requirements document was finished, new subsystems were discovered that
had not been included in the initial architectural design. These were added to the architectural
design, interfaces defined, and responsible engineers assigned.

Technical Review. The project manager and system engineer arranged a Concept day where
the engineers presented their alternative concepts on a single A3 sheet. All the team members
made A3 sheets of their subsystem(s) and their suggested concepts including a tradeoff
analysis, and risk analysis. The whole team used the opportunity to come with their opinions.
This was really important so everybody agreed upon the alternatives eventually selected as a
condition for passing the Final Design decision gate.

Construction. Before the different subsystem designs were sent out for production, an
extensive testing and verification phase was done on the mechanical subsystem using the
respective subsystem document, and CAD (Computer Aided-Design) software. The reason for
having these tests was because the systems engineer wanted to lower the risk of making the
wrong subsystems and to eliminate flaws during the final design phase, rather than in rework,
since the manufacturing took time.

For example, the subsystem S.6 Suspension had a complete CAD drawing and the systems
engineer and the engineer responsible for the subsystem went through the complete design
together with the engineers responsible for subsystems having an interface with the S.6
Suspension. More than 4 different design flaws were corrected during the CAD test and before
the production. After all the CAD drawings of the subsystems were checked and flaws were
corrected, the suspension components were produced.

Visualization. A problem was discovered after all the Subsystem Documents were finished and
published for the engineers. Even though all the files and information were accessible on
NTNUs server for the engineers, it was not referenced consistently by the team members. As
well it was not easy for the managers to have a clear overview of the status of each subsystem.
The systems engineer came up with the idea of having a Systems Engineering Wall as shown
in Figure 4, which should illustrate the subsystems and components and use colors to illustrate
the status of each component. In addition, the wall helped track configuration management.

Figure 5. The Systems Engineering Wall (Welland 2011)

The complete system was visualized through the Systems Engineering Wall and illustrated the
architecture design, the system interfaces, and the responsible engineers for each subsystem
and for the interfaces. The status of the individual subsystem and modules were recorded using
one of three different colors, with date when modified and the person who wrote the status. The
description of the colors is explained bellow:

Yellow: Critical, more than two weeks delay on the components, issue discovered
Blue: Medium, parts may be delayed less than two weeks, in process
Green: Ok, component read

The Systems Engineering Wall was used by the systems engineer for a 5 minute debriefing
with each engineer every Monday, Wednesday and Friday. This helped the team members to
focus on their work since time was critical during the project. It also helped the systems
engineer to see the status when it came to time and issues and configuration management. The
result of the Systems Engineering Wall was that the Monday meetings with the entire team
went from duration of around 2-3 hours to under 1 hour a week. In the beginning, the whole
team was part of the discussion about all the subsystems. With the 5 minute debriefing, the
individual team members met at the time that suited them best.

Configuration management was one of the key topics tracked using the wall. During the
debriefing the baseline was discussed since the different modules had interfaces connecting
other responsible engineers. If there were any configuration changes made, the responsible
engineer for the interface to the subsystem was invited to the debriefing. The complete baseline
was still discussed every Monday with the whole team since it was important to get the whole
team involved in the process.

An example of the resolution of a configuration management issue occurred between the sub-
systems S.10 Engine Wheel and S.6 Suspension. During the testing and verification process,
the S.5.1 Engine had to be changed due to low performance, making the system too slow and
unable to meet the average speed requirement in SEM rules. CAD models were used again to
illustrate and to simulate the baseline of these subsystems and during the whole process of
configuration only one part of the S.6 Suspension actually needed to be remanufactured, which
saved the team precious time and money.

Testing. This section discusses the Verification phase of the SE process with a focus on the S.6
Suspension and a comparison with last years team effort. The first verifications step which
tested the interface using CAD models and simulation was discussed above and was significant
because flaws in the suspension would affect other subsystems.

The test procedures for this project were made together with the engineers and for all the
subsystems. The required test beds were also on a critical timeline and evaluated. A customized
test bed for the S.5.1 Engine was made, and this later proved to be of great value for the team.
Suppliers were contacted and a Test and Evaluation Master Plan (TEMP) was written. It was
hard planning the testing weeks ahead because of delays from the suppliers, but the general test
procedure was not changed. After each subsystem had been verified to the requirements, it was
time to verify the complete system with the SEM requirements and the engineers requirements
which were included in the 10 documents. During the verification phase, 18 issues were
discovered during the first test. The system engineer made a rule, that all the issues must be
solved before any test could start could start again. During test 2, only 2 issues were discovered
and during test 3, another 8 issues were discovered.

One of the biggest issues uncovered concerned the subsystem S.5.1 Engine. The Engine had
been tested in autumn 2010, and based on the data from the 2009/2010 team, the engine should
be working fine. Even though in theory the engine fit, the reality was that it didnt. One mistake
had been made during the testing in autumn 2010, which was failure to verify that the engine
could reach the required speed with the approximate resistance torque of the system. The
engine was only tested to see that it functioned. After production, the engine was tested at our
sponsor Smart Motor, where it was discovered that the engine could only reach 10 kilometer
per hour (km/h) due to induction voltage. When the engine reached 10 km/t the engine stopped
with a braking force. This indicated that the prior years team could not have raced even if the
control system had worked (Stockfleth, et al. 2010) since the engine would not have reached
the required average speed. There were two alternatives, reduce the number of wires in the
stator or make the gap between the magnets wider. The latter option was selected, and
adjustments were made which impacted S.6 Suspension. The adjustments went well, and took
a lot of time, but the discovery had been early enough to repair the error.

The Race the ultimate Validation. This section will give an overview of the results attained
during the race, and what the systems engineer called the validation phase. If the system passes
the technical inspection and finishes the race with a result, the system is considered validated
by the customer/sponsor. The technical inspection is the first validation of the requirements to
fulfill the rules of the Shell organizers. The inspection was passed without any annotations by
Shell. Passing this first hurdle proved that the all the verification testing and the careful
analysis of the stakeholder requirements had been worth the effort.

In Germany, the system behavior changed when the team arrived at the race site. At first, the
team believed that the warm temperature was causing problems with the S.5.2 Motor
Controller since the electronics became hot. An adjustment was made by rotating the Motor
Controller in an upright position to improve cooling, thereby seeming to solve the overheating
problem. However, the actual problem was caused by a small change to the interface between
the shaft and the engine. Before the team packed the car for the trip to Germany, there was a
small change in the S.5.1 Engine. The system engineer asked the responsible engineers several
times if this would cause any changes to the control system and the engine, but based on their
knowledge they said no. Even though the system engineer did ask several times, the systems
really should have been tested and verified again. It wasnt until 3 days before the race closed,
that the team realized that this was the source of the problem. Last minute changes were done at
the race site and new calibrations to the engine and the control system fixed the problem. In
retrospect, the team learned a valuable lesson; even though complete testing had been done on
a prior configuration two weeks earlier and the adjustment made was seen to be negligible,
regression tests should have been re-run before travelling.

A second problem was uncovered during the opening run. The driver turned on the lights and
blew the smallest fuse of the S.9 Control System. The car completed the first unofficial
attempt, but used 15 minutes over the allowed time; otherwise the result was good. However,
the time had to be reduced. Suddenly, the largest fuse blew during testing. The cause of this
problem was that the cables into the S.9 Control System were not mounted properly. After the
fault was fixed the car was ready again. Then after three rounds the valve to the hydrogen
sources stopped due to a small bump in the speedway causing a loss of power from the S.4
Hydrogen Module and a disqualification of that attempt. Finally, in our last attempt, we
achieved an outstanding result of 1000 kilometers per liter (km/l) which meant that NTNU
came in second place at the SEM competition.

Discussion

Did SE matter? Before the rest of the team could be influenced by the final result, the systems
engineer interviewed some of the engineers on the way to the race and asked if systems
engineering had any impact on the project.

One team member said that discovering issues related to configuration management and CAD
testing before the production of the components had been beneficial. This also included the
discovery of the issues during testing before the race. Last years team did not do any testing
and had there been any test procedures before the race, the system would have failed.

Another engineer said that systems engineering worked well, especially by helping to discover
issues early. A third engineer said that the systems engineering approach was good and made
the engineers think over different things that werent thought about before. Having the systems
engineer around to ask questions and search for the reasons was helpful.

This quote is taken from the Masters thesis for the whole construction team:
Alexander proved the value of having a full time systems engineer on the team in addition to a
project manager. (Qviller, et al. 2011, 8)

The Project Managers Master thesis included this statement:

The system engineering approach is important while improving the car.(Schindler 2011, 64)

The construction team also integrated diagrams from the SE efforts into their final thesis; just
one more indication that these artifacts had value and helped them to describe their own
contributions (Qviller, et al. 2011). At the end they were able to declare, This year the team
finished in 2nd place in the Urban Concept Fuel Cell class. ... These results confirm that the work
described in this master thesis is in the European elite. (Qviller, et al. 2011, Schindler 2011)

The incoming team for the following year wrote in their Project Initiation Description that their
biggest challenge would be to coordinate the team during the development and testing of the
car, demanding a thorough understanding of the car and its systems with their interfaces.

The Wall. Team members were fascinated by the Systems Engineering Wall illustrating the
documents produced and the real time status update using the different colors. The team
members regularly looked at the wall and the system structure. The impression was that there
was always a lot remaining to be done, but the wall helped the team members to structure the
work they knew had to be done to finish their subsystems.

By using the SE wall, the project manager also could maintain a good overview over what was
on time and what was delayed and the reason why. The SE wall proved to be of even greater
value for the project manager when he got sick for around 2-3 weeks. Upon his return, the
systems engineer took him to the wall and gave him a real time update which helped him get a
fast and accurate picture of the status of the project. Another important aspect was that the SE
wall really helped to give an update for the team manager without interrupting the team.

Conclusions
Even though the definition of systems engineering may vary between authors, the essential
systems engineering methodology from INCOSE is important when developing a system for
large and small projects. This worked because the author customized the tools within systems
engineering methodology to fit the project. One of the aspects that INCOSE emphasizes well is
the mind-set of systems thinking, which is important during system development, and it is also
important that the whole project develops this mind-set. One of the key success factors was that
the whole team committed to the use and importance of adhering to systems engineering
approaches. This created a shared vision between all the engineers about the phases and the
decision gates.

Simplicity was essential during the project and helped coordinate the activity of team members
who each took ownership of a subsystem. Documentation uncovered from the prior years
work did not have any traceability for to the subsystems, nor were there assignments to a
responsible engineer for the different requirements. Ownership was critical during the process,
saving time and helping the team to reach decisions faster. Interface specification and
traceability from SEM requirements made it easy to understand the complete system, the
subsystems and their components and easier to trace configuration through the system.
Systems engineering really proved its value in the verification phases of the project because
this is where a lot of issues were discovered. Discovering issues during the verification phase
was possible because of the clear requirements and permitted the project to maintain schedule
and budget, notwithstanding supplier delays and other obstacles.

It is very hard to measure in quantitative terms the actual value of systems engineering within
this SEM project. However, the consensus of the participants was that system engineering
mattered. A comparison with the prior years SEM project shows that even when the team had
more engineers, more competence and more time, they had interface problems between the
subsystems and did no testing before the race. Without the essential discipline that systems
engineering provides there is a high risk that the system may fail. There is no doubt that
meeting the systems engineering milestones helped manage the project, even within the tightly
time-constrained schedule. The use of systems engineering gave a structured approach that the
engineers and project manager understood and appreciated.

The systems engineer and project manager share the important tasks to lead the project and
facilitate team coordination. The collaboration between the systems engineer and project
manager during the SEM project worked very well. One of the essential parts helping the
project manager was the Systems Engineering Wall. This helped the project manager to keep
track of time and the technical status of the system. It was also beneficial when the project
manager got sick and needed a quick real time update of status of the system.

The systems engineering approach is already being used by the next years team, the NTNU
Revolve team (formula I), and a start-up company in Silicon Valley. Reports from the
2011/2012 NTNU indicate that the team has been able to benefit from the legacy of artifacts
and practices reported in this paper. They face a whole new set of challenges that will be the
subject of next years paper.
References

Bahill, TA, and C Briggs. The Systems Engineering Started in the Middle Process: A Consensus of
Systems Engineers and Project Managers. Systems Engineering, 2001: 156-167.

Fricke, E, B Gebhard, and H Negele. Coping with Changes: Causes, Findings, and Strategies.
Systems Engineering, 2000: 169-179.

Haskins, C (ed). Systems Engineering Handbook, version 3.2.1. Revised by M. Krueger, D. Walden, and
R. D. Hamelin. San Diego, CA: INCOSE, 2011.

Haskins, C. Using systems engineering to address socio-technical global challenges. Proceedings of

the Conference on Systems Engineering Research, CSER 2008. Los Angeles, CA: USC, 2008.

Kossiakoff, A, and WN Sweet. Systems Engineering Principles and Practice. New Jersey: John Wiley &
Sons, 2003.

Pennock, MJ, and YY Haimes. Principles and Guidelines for Project Risk Management. Systems
Engineering, 2002: 89-108.

Qviller, A, TM Stockfleth, SH Bleie, and M Hoel. Shell Eco-marathon. Master Thesis, Trondheim:
NTNU, 2011.

Sage, AP, and WB Rouse. Systems Engineering Management: The Multidisciplinary Discipline. In
Handbook of Systems Engineering and Management. New Jersey: John Wiley & Sons, 2009.

Schindler, UWH. Managing Execution of an Environmentally Friendly Vehicle. Master Thesis,

Trondheim: NTNU, 2011.

Stockfleth, TM, H Jenserud, C Knudtzon, and M Hoel. Shell Eco-marathon. Master Thesis, Trondheim:
NTNU, 2010.

Vanek, F, P Jackson, and R Grzybowski. Systems Engineering Metrics and Application in Product
Development: A Critical Literature Review and Agenda for Further Research. Systems Engineering,
2008: 107-124.

Welland, A. Systems Engineering in Practice: Developing a worldclass car for the Shell Ecomarathon.
Master Thesis, Trondheim: NTNU, 2011.
 Biography
Cecilia Haskins
Cecilia Haskins entered academia after more than thirty years as an IT-professional. Her
educational background includes a BSc in Chemistry from Chestnut Hill College, and an MBA
from Wharton, University of Pennsylvania. She has been recognized as a Certified Systems
Engineering Professional since 2004. After earning her PhD in systems engineering from
NTNU, she conducts post-doctoral research on innovative applications of systems engineering
and mentoring student projects.
Alexander Welland
Alexander Welland is the student who served as systems engineer as described in this paper
and whose experiences are reported here from his Masters Thesis submitted at the Norwegian
University of Science and Technology. Alexander received a summer internship and multiple
job offers because of his knowledge of systems engineering. He is currently in a special
systems engineering training program in Aker Solutions to increase his domain expertise in
subsea systems.