We have good systems engineers just like Victor Frankenstein(1)!
We offer sophisticated systems or simple units doing sophisticated things.
Or we just fix your stuff.
Multi-level Project Resource Management (MPRM) Group Canada Est. 1986 Contact us. Phone or Text: Toronto/Southern Ontario Canada 437-887-1905
(1) This is 2017-06-25 but going way back to 1818 was Victor Frankenstein a good systems engineer by today's standards?
He built a complex system with many components.
His system worked! Ours do as well.
We are like Victor. We get our top marks for being able to simply explain the complicated things we do well.
We like Victor get high marks for low cost, high performance, on schedule and great reusability.
Victor, however, gets low marks for risk analysis, total life cycle analysis & final system test. We would fix our predecessors' errors with little or no fuss.
The following discussion is based on Mary Shelley's 1818 novel, not on the movies. ->Note: Read the bold bullets to see how we engineer a new system to last forever.
Stating the problem: Frankenstein was depressed when his mother died. So he wanted to conquer death by infusing life into an inanimate body.
Understanding customer needs: I think he blew it here, compassion and grief consoling might better fit the needs of his customer.
Discovering system requirements: The only requirement he considered was creating life, so he did a poor job of discovering requirements.
Validating requirements: How could he validate them if he had no requirements?
Investigating alternatives: When the monster tracked down Frankenstein, the monster said that he was lonely and he wanted Frankenstein to build him a companion. In designing this companion Frankenstein considered a lot of alternatives.
Defining quantitative measures: He had no measures of effectiveness.
Modeling the system: He had mental models and sketches in his book, but no formal models. Consequently, Frankenstein was surprised at how hideous his creature turned out: thinking he was ugly [during construction]; but when those muscles and joints were rendered capable of motion, it became a thing such that even Dante could not have conceived.
Functional analysis: He did a physical (not a functional) analysis.
System design: He designed a very good system. And he gets high marks for reusability!
Sensitivity analyses: He did not know about sensitivity analyses. They are modern tools.
Risk management: He gets very poor marks for risk management. Indeed his monster ended up killing his brother, his best friend and his bride. But before Frankenstein finished his second monster, he considered the risks and destroyed his work.
Reliability analysis: His monster was very robust. It overcame lack of food, freezing cold and bullet wounds all by itself.
Integrating the system: This was his crowning achievement, he put all of the parts together and it worked.
Launching the system: Frankenstein did not launch his monster into the world. In fact Frankenstein ran away when it first came to life.
Configuration management: He couldn't do configuration management if he had no requirements.
Project management: He did an excellent job of project management: his system had low cost, high performance and came in on schedule.
Documentation: He kept a laboratory notebook. This notebook is what enabled the monster to track Frankenstein down a year and a half later in a different country.
Leading teams: Frankenstein worked alone and never told anyone what he had done.
Assessing performance, which includes prescribing tests, conducting reviews, verifying requirements and total system test. Frankenstein did not do any of these tasks.
Re-evaluating and improving quality. The reason Frankenstein went to England was to consult with philosophers there, because he wanted his second monster to be better than the first. He never got around to describing the lessons that he learned while doing the project.