During a recent discussion in regards to what is and isn’t systems engineering, something came up regarding that potential split between how the professional or “academic” ideal approach to systems engineering is actually a touch different to actually convincing people to use it and how you can actually apply it in the wild and dangerous lands of business and private enterprise…
Most systems engineers will follow the basic core concepts as:
- Understand the whole problem before you try to solve it
- Translate the problem into measurable requirements
- Examine all feasible alternatives before selecting a solution
- Make sure you consider the total system life cycle. The birth to death concept extends to maintenance, replacement and decommission. If these are not considered in the other tasks, major life cycle costs can be ignored.
- Make sure to test the total system before delivering it.
- Document everything.
Now, on many levels, that is a great and glorious approach to it.
You know (pretty much) exactly where you are with your work and how you’re applying whatever your favourite techniques and methods are.
However, as was pointed out, to many people who aren’t practiced in any way with systems engineering, it can sound just like witchcraft. Or quantum physics. – Which probably share an unusual amount of similarity to each other.
Now persuading someone who think’s you happen to be jabbering the equivalent of over-technical and potentially heretical sanskrit at them to actually use those techniques or that they can actually help him… can be an uphill battle. And if you do, then there’s the compromises that always occur. The nature of time, the costs of the project, all have to be taken into account for how you can actually apply yourself to whatever problem/system you happen to be looking at.
I’ve known a few people who just couldn’t let that search for the “completely right and perfect solution” go and then end up not delivering any result, let alone one that was half-way competent to getting the job done.
While it might be professionally “right” to consider the entire life cycle and make sure there are preparations for the eventual retirement of one system (or solution) for another down the line, it’s not always possible. Due to lack of knowledge of all the variables, lack of control in exactly what will happen, all of which have to be compromised to if you actually want to deliver some form of result.
So in a lot of ways, you can lose what amounts to a certain academic rigour, for the slightly fuzzier working situation of getting people to actually use the tools and results you provide. Convincing them you can actually be effective and useful, getting them to understand the basics of what’s going on without having them lost to the terms and methodologies, and successfully getting them to apply the results to solve whatever problem they had in the beginning.
Someone of my acquaintance has for years struggled with getting potential stakeholders to understand what he was trying to do for them. But then for a lot of that time his approach was attempting to compress; explaining the entirety of his approach, the tools and methodologies he used in it (and the history of how they came about), along with the nature of systems engineering, all into one short blurb that he presented to the potential stakeholders.
Which generally left people in a dazed “What is he talking about? Why is this relevant to me??”. At which point, they pretty much switch off and trying to convince them there’s some use to any of it… goes out of the window.
Nowadays, he’s broken it down to three relatively short phrases to cover it:
- The right benefit
- In the right way
- For the right price
By pretty much using only those three concepts to convey his approach, there’s a completely different reaction to the way of talking witchcraft at those who excel in talking managerese.
But by the same token, since that’s the way it gets explained to people, it allows a fuzzier element to creep into the nature of systems engineering. When you have to reduce the technique of your approach to make it understandable to others, then there has to be compromise in how well it translates across and in how they can apply whatever you leave them with.
Which after all wandering back and forth there, leaves the questions hanging:
Practical Business versus Academic Rigour? Where does the difference meet?
Time and Cost always reduce the time you can spend defining needs, establishing relationships and required functionality. Or just how long you can spend analysing and testing.
You don’t always get provided with all the details needed to establish the bigger picture when trying to look at the problem as a whole.
They don’t always understand what you’re talking about. Or even actively misunderstand the questions you ask when you try to define things.
Solutions provided can be just as misunderstood, or even only implemented in parts. If you’re only there to provide a potential solution and not oversee it’s implementation, when a half-assed job leaves it failing who gets the blame?