In this fourth lesson about systems engineering,
we focus on the impact of systems engineering on business in terms of improved quality,
reduced cycle time, and less rework.
So since the scientific revolution,
we've made most of our progress by reductionist thinking
by becoming specialists in smaller and smaller areas.
And that's a wonderful thing,
it's allowed us to make great technological leaps and,
in fact, that's what tailor-made an art in the 19th century.
But that works well when you're dealing with narrow domains and,
to be honest with you, relatively simple problems.
What we're dealing with in the 20th and now,
21st century are cross-domain problems.
They're complicated and they're moving into complex.
At that point, the value doesn't come out of one specialty alone.
It comes out of multiple specialties working together to find the right answer,
or to understand the problem,
get to the right solution.
And the real value of a system comes out of inter-relationships, out of interactions.
Now you can either plan those and have them go
well: a 787 flying safely to its destination,
putting a man on the moon.
Or you can fail to plan and understand;
the Samsung Galaxy Note 7 and the battery
issue that wiped out an entire product line and did great damage to a brand.
So systems engineering is all about prework rather than rework.
Understanding those interactions, looking at those inter-relationships,
bringing multiple specialists together to see a problem from all angles,
gather all the information,
devise the best solution,
and minimize unintended consequences.
Systems engineering demonstrated, even in early project,
methods to effectively manage complexity and change.
In modern designs, complexity is increasing as well as the rate of change.
And as a result, managing risk becomes increasingly
important as life cycle costs are committed early even though
they're not expended until later which results in a lag of
decision impacts on budget and schedule.
A study, published by Haskins in 2004,
focused on the costs of corrective actions when compared to
the cost of correcting them at the requirements stage.
The reference case is taking corrective action at the requirements stage.
In the design phase,
corrective action costs three to eight times what it
would have cost to make the change during the requirements phase.
In the build phase,
costs increase to seven to 16 times.
Once you reach testing,
it costs 21 to 78 times what it would
have cost to correct the issue during the requirements stage.
And then issues identified during operations,
cost 29 to 1,615 times what it would have cost to correct in requirements.
With a mean of 250 times that it would
cost you to correct it before the design process starts.
In 2014, Incose pointed out
a useful explanation of the motivation for systems engineering,
"It is not hard to know when systems engineering fails.
Because when something important goes wrong it usually makes the news fast.
People get hurt, programs are delayed and over budget,
and the law becomes involved.
But when systems engineering goes right,
no one notices which is how it should be."
In 2012, a group that included
the software engineering Institute of Carnegie Mellon published a study of 148 projects.
At low levels of systems engineering capability,
only 15 percent of projects achieved
high project performance measured with respect to budget,
schedule, and technical requirements.
Fifty two percent of the projects resulted in low performance.
At high levels of systems engineering capability,
57 percent had high project performance with only 20 percent at low performance.
A separate study published in
2013 investigated return on investment of systems engineering and found,
investment in systems engineering efforts had
significant and quantifiable impacts on projects.
The ideal level of systems engineering effort for
projects is around 14 percent of total program costs.
In the study projects,
the median level of systems engineering effort was only seven percent of
total program costs or about half of the recommendation.
If a project adds systems engineering effort to a project that has none,
there is an ROI of seven to one.
The thing you have to understand about systems engineering is it is
designed to be entirely scalable and tailorable.
You do not have to take on the billion or multibillion dollar problems.
In fact, one of the organizations that we're dealing right now is
Keurig the organization who makes the pod coffeemakers,
not a system that we would think of as overly complex.
But as you deal with problems in the marketplace and you
wish to be as effective as you can, obviously,
you've got multiple interacting pieces,
you've got mechanical issues,
you've got electrical issues, et cetera.
The key to bringing it "down to that level"
is to get away from process and get back to principles.
It's about looking at the problem from all angles.
All of the specialties who are going to be involved.
What are the reliability concerns?
What are the manufacturer ability concerns?
What are the usability concerns?
Looking at the problem from all those angles.
Collecting and organizing all the information and jointly finding the right answer.
If you can stay at a principal level,
then you can scale the practice,
the processes, the methods,
and the tools up or down to solve the particular problem at hand.
In projects with the median level of systems engineering effort,
that seven percent I referred to before,
there is still a 3.5 to one ROI for additional investment in systems engineering.
This is a thumbnail sketch of systems engineering.
To learn more, there are multiple options for formal learning.
Incose has a multi-level systems engineering
professional certification program with
three levels: Associate Systems Engineering Professional,
Certified Systems Engineering Professional,
and Expert Systems Engineering Professional.
There is also an Introduction to Systems Engineering course
developed by the University of New South Wales in Australia and offered on Coursera.
And to learn more at your own pace,
I'd recommend the following for
in-depth reading: The INCOSE Systems Engineering Handbook,
fourth Edition; the ISO/IEC IEEE 15288 Standard;
and the Systems Engineering Body of Knowledge or SEBoK located at sebok.wiki.org.
Finally, the 2015 video from
the Chesapeake Incose meeting that includes a presentation by
Garry Roedler provides an excellent perspective
on the recent evolution of systems engineering.