“What field are you in?”
“Systems Engineering.”
“Oh, like computers?”
“No – like an infrastructure
of processes-” insert confused look here.
Government and military
organizations have been using Systems Engineering for over six decades now, yet
some people don’t grasp the concept. To be honest, when I first started my
journey in Systems Engineering, I didn’t quite know, either. I can confidently say I had a decent
engineering program that reviewed enough case studies in industry that I was
able to adapt it along the way and enter the industry the concept under my
belt.
But until you are involved
in a physical application, you don’t truly understand.
Infrastructure
of Processes
Let’s take a simple project
– business trip to Minneapolis. There are different elements that make up the
trip. You need to know when you need to fly and when you plan on returning.
There’s a weather check involved to help you pack. You may want to go eat some
locally caught Walleye fish and find the best restaurant to do so. And finally,
you establish the main purpose of this trip.
At its simplest form – you
have a system for your trip. Why? Each of these above categories, have elements
or steps within them. When they are sequential steps or actions, this is
typically how project or program managers depict their work breakdown
structure. When they are nouns, this is how a system can be depicted.
The processes are linked in
some way or another, with either two processes linking or all four processes
linking. And in this example, it just
so happens that every element links to the other.
For planning, I need to know
what I’m doing for business and leisure to book my travel arrangements. For
Packing, I need to know how long I’m traveling for, what my business activities
are and what my leisure activities. And so forth.
Where
we fail in not knowing the System
Reflecting over the last few
years, some of my early mistakes stemmed from not knowing where I was in the
system or worse, not knowing the system existed! Being a lead on past product
launches, I was in charge of making sure the highest quality product got out the
door when the customer needed it. I knew there were objectives such as “get it
out by Friday in order to meet clinical implant schedule.”
But earlier in my career, I
didn’t truly know all the pieces to get from my part to the clinical implant.
And after seeing the bigger system picture, it made sense as to why two hours
made a difference.
Other faults are not knowing
the interfaces well enough and seeing how something I did, affected the
downstream processes. Risk assessments, when done correctly, are the best
applications of Systems Thinking.
Continuing with my business
trip example, let’s say I’m booking my ticket for my flight back to Phoenix. I
pick the evening flight so that I can return to Phoenix at a reasonable time.
The risks? If I don’t know what my business objectives are, I may end up
missing an important meeting or miss my flight (if the meeting took
precedence). Or if I decided to go to the restaurant in downtown, not realizing
there was a playoff’s game in the area, I may detour towards the airport
without getting my Walleye or worse miss my flight.
System
Family
The processes create the
infrastructure of the system. But most of the time, the most important part of
the system are the team members that operate within it. Too often, we discount
this notion and that’s where issues occur.
I’ve said it before and I’ll
say it again – in my career, the hardest problem I face is never technical.
It’s personal and that is why relationship building is important.
On my business trip to
Minneapolis this week, I saw how the entire system for a product I supported
last year operates. I always questioned – well why does that tiny shape matter
or what happens if we had a capability lower than normal at this step? This
week I learned that the most minor feature from my perspective made or broke
(literally) the product’s performance.
And hearing the perspective
of the individuals from the other processes, helped me better understand why
things were done the way they were. The common example is holding up a dollar
bill to someone – I may see a face and swear on everything holy that I do. But my
peer shakes his head, knowing there is a pyramid in front of him.
Relationships are critical.
We ignore them because we believe we know how the system works and are
overconfident in our process to ask further questions. I had the pleasure of
learning the pains my colleagues had and the sacrifices they made. I was taught
how some decisions come about and why certain individuals are involved in these
decisions. My worldview has shifted dramatically and it’s not just seeing the
system but seeing the faces behind the system.
Another learning this week was
respecting everyone’s role and responsibility. When you understand what someone
owns and trust that they can perform it, you can focus on what you own and
contribute to the system.
Yes, computers are systems.
They’re made up of different hardware and software components that produce a
great tool for business and pleasure. Systems Engineering is more than that
(even though the principles are the same.)
Next time you’re working in
your world, stop and ask what your work is feeding into or what work fed into
your activity. Almost always, you will be operating in a system.
No comments:
Post a Comment