System Egineering challenges: I talk to the developers so the customers don't have to.

I find myself working between customers who are super intelligent mathematician's and super intelligent, very capable developers - so what's the problem you may ask, it's getting these two parties to understand basic Systems Engineering (SE) and development principles. I begin with the words "Requirements", "CM" or delivery schedules and it makes these two sides of the aisle cringe. They change the topic of conversation to when can we get the capability under development deployed within the larger corporate systems - "we'll never know what it can do until we have in the system". I've actually learned new terms that have been invented to circumvent traditional engineering processes. Terms like "toxicity testing", this basically means we'll test the product just enough to ensure it doesn't break the larger system or severely impact other components. My favorite is the colloquialism "Code and Pray" that implies that agile development can only be successful if you can view the initial operation and deployment of a product from a hardened bunker. I've never felt so inadequate in a work scenario - I spend most of my time trying to convince my organization about the value of what I bring and how process and planning are integral for long term sustainment of operational systems.

When I began to work in my current organization we were staffed with 14 SE's and about 100 Math/Computer Science engineers and nearly double that in developers. The organization had just sustained a massive systems failure to one of the core data warehouses due to years of patching and applying makeshift code to continue life support to a custom built, non-scalable, non-supportable (no interface documentation or consistent logistics support). Yet the recognized failures in SE practices did not dissuade them from shedding the repressive bonds of industry best practices and the cut our SE staff to 7 and boosted developers by and equal number. The theory being that now that the developers were not encumbered by all our restrictions, testing requirements and documentation generation rapid development would proceed. Wow... they just didn't get it. They spent months in Tiger Teams to analyze and document the circumstances surrounding the failure and although the recognition that certain CM and architecture level development and integration may have prevented this each organization just couldn't bring themselves to slow down and do the necessary pre-work to ensure long-term continuity of operations. Probably because my organization values actual delivery of new products and services and not how long they continue to run efficiently. Pretty hard to justify spending a year talking and writing I guess. I mean it's hard to try to convince management to just imagine how much we could save if the systems continued to operate with problems or delays - quantification of this benefit is challenging and without a strong champion I guess I'm out of luck. So I continue to try inject simple SE practices without actually labeling it as such. Everyone once in awhile during the infrequent meetings where no one takes notes or offers suggestions .. or heck has an agenda... I slip one in and get caught. Then there are the traditional jokes, scoffing and uncomfortable glances. I really would like someone in leadership to make it known that that SE and formal processes need to be taken seriously - We need a champion to carry the message and enforce the practices throughout each project before we experience another major systems failure.