Friday, November 13, 2015

True Systems Engineering

“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