Systems Engineering will assure a successful project. Fact or Fiction?

Ever heard a Systems Engineer or anyone else say this? Did you believe them?

Commissions of Inquiry relating to acquisitions of a complex piece of infrastructure have been known to recommend that Systems Engineering would have avoided the public humiliation of the project fail.

Consider the generic recommendation, that Systems Engineering would have prevented the politicians and key stakeholders embarrassment and avoided the front-page publicity of the project fail. Would it really? Does the Systems Engineering toolkit include a crystal ball? Could Systems Engineering have really have foreseen all those things before they went wrong? And fixed them before they became a significant issue?

“They” have heard the message loud and clear, “Systems Engineering”, “Systems Integration” and “Systems Assurance” and references to the Systems Engineering standard ISO 15288 can now be found in infrastructure contracts. Project Teams have responded and included Systems Engineering teams in the project team structure, so it should all be good now. Right?

If the commitment to Systems Engineering is founded on the assumption Systems Engineering is something done by Systems Engineers, it is unlikely to reap the hoped-for benefits. Systems Engineering is a way of delivering a project where the success is largely dependent on solving an integration challenge. Systems Engineering has evolved as the complexity of systems have evolved, a System being a integration of people process and technology, not just something with electricity flowing through it. 

The most complex systems to deploy have inevitably been those that integrate hardware and software in a way that is intuitive and safe for a human to use. Systems Engineering evolved in the most complex of integration challenges, where it was not possible to engineer things twice, it had to work right first time, or it was a fail. Think NASA, think Military Systems. Some projects have spotted an opportunity to adopt those right first-time methods and apply them in diverse contexts to reduce the risk of failure. Everyone on a project has a role to play in Systems Engineering because everyone on the project can have an impact, directly or indirectly, on the success of developing and deploying that system.

Systems engineering can provide a way to minimise the risk of time and cost overrun and assure a system that will meet the needs of the known and considered stakeholders, thus assuring a successful project. If Systems Engineering is left only to the Systems Engineers, if the Project influencers, Project Directors, Project Managers, Design Managers and the rest of the project stakeholders and team are not bought in to the Systems Engineering approach then it simply will not work as well as we all hoped. 

Systems Engineering provides a project toolkit to translate the needs of a sponsor or client into the requirements and assures that the right system is built, and the system is built right.

Projects using Systems Engineering are actively analysing and reanalysing the stakeholder needs to understand if they will be fulfilled by the system; looking for potential obstacles to meeting those needs as the understanding of the system capability matures.

Systems Engineering is useful when the system is simply too complex to understand in one pass and and integrate in one go, the development and integration needs to be done iteratively and progressively, checking what we are doing will be successful.

Projects using Systems Engineering have processes for managing the inevitable and emergent changes, changes because of things we could not have known of sooner because we have never done some of this stuff before. 

In my opinion the opening statement is fact. Systems Engineering will assure the project success, but only if everyone who has a stake in or influence on the success of the project commits to the Systems Engineering approach, not just the Systems Engineers.