Contrary to my earlier ambivalence to System Engineering, something that I had previously documented,
I am actually starting to like and even enjoy this class. The problem
that I had with this class earlier was a result of my attitude that
most of the tools and frameworks that were taught in System Engineering
can only be applied in traditional large complex systems like
aerospace, civil engineering, and other infrastructure related fields.
Fundamentally, I didn't like the regimented approach of System
Engineering and I believed that System Engineering inherently stifles
and even contradicts innovation in Product Design and Development (PDD)
process at many organizations. Therefore, I had the tendency to reject
many of the concepts that were taught in class.
But as the course progresses, the concepts that we learned from
class appear more cogent, especially as I began to evaluate critically
on the underlying PDD processes at my company where I still work. Like
any established companies, there are PDD projects in my company that
have produced blunders as well as excellent results in the form of
highly successful products. But as I began to ponder on these processes
at my company, I can't help but to think that the causes of many failed
projects stemmed from ignorance, confusion, and bureaucracy. While I
acknowledge that some of the breakthrough products at my workplace are
the result of minimal management oversight and the lack of robust PDD
process tools, there were plenty of projects that could be improved
with the application of the tools from System Engineering.
All the tools and frameworks that we learn from System Engineering
have their flaws and merits. So I don't think there is a single tool
that can be applied broadly across different engineering environments.
Perhaps, to Yoav's chagrin,
this is why there're no real-life examples to support the frameworks
that the class discusses. One learns the tools and then applies them
critically in real-life.