Here's my FAQ I used when I was a Director for systems engineering for an aerospace and communications firm
(And, I tried to make this not too stuffy!)
What is this thing called system engineering?
- What is system engineering? Here's the way NASA defines it: "System engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system"
- What do systems engineers (SE) do? Primarily, they have three work areas: system architecture; system feature, function, and performance; and system validation. Included in these three work areas are the system 'ilities', system risk management, major interfaces, and optimization among competing constituents. And, SEs contribute to the major project plans as directed by the PMO.
- Why is system validation one of their responsibilities? First, SEs are independent of the developers -- and independence is a good thing for validation. Second, the SE is charged with maintaining a holistic view of the system; this view should inform system validation procedures. And, third, this puts accountability into the mix: SE is actually in the workstream that makes it work!
- Are there standards and protocols for what SEs do? Yes, like the body of knowledge for project management, there is a generally accepted body of knowledge for SEs. For instance, INCOSE -- the SE counterpart to PMI or APM -- maintains a body of knowledge in their System Engineering Handbook. Among free resources are those in the public domain from the US DoD/SE and NASA. Of course, there's also the ISO standard 26702, among other ISO standards on various disciplines with SE.
- Do SEs have their own workpackage or swim lane? Yes, it's customary to uniquely track cost, schedule, and deliverables of the SE activity
- Who do they report to? Typically, SE reports to the PMO
- What's a good benchmark for cost? Benchmarks depend on the nature of the project. For studies, the SE could be the whole project; for a typical development with a generous system validation activity, SE could be as much as 40% of the cost, but probably not less than 8%.
- Do they have deliverables? Yes, SE is not a level-of-effort; the deliverables depend on the specifics of the project, but for the most part they are plans, specifications, and procedures.
- If SE are the architects, what is architecture? Architecture is that which defines/specifies/describes the overall boundaries of the major components and defines/specifies/describes the interrelationships and behaviors among the components. In some situations, the overall physical appearance and presentation may be part of the architecture
- What are they thinking when a SE talks about a system? I've answered this before, but here's the simple answer: a set of 'things' -- constituents -- interconnected in such a way that they produce their own pattern of behavior over time. The way a system responds to stimulus is a characteristic of the system itself and not necessarily that of any of its constituents
- Should I use SEs to pursue new business? Yes, many have good customer skills and can communicate conceptually to the thinkers in the customer community
- Can I innovate without them? Anyone can be the innovator, but SEs are often cast in the role of coming up with unique and discriminating ways to do things.
- What do I give up if I don't have them? Many projects don't have a SE per se and do just fine. However, on larger projects with complexity and scale, the architecture function is essential. If not an SE, then someone else with that role is needed for the activity
- If my project team does this anyway aren't just redundant? Not really; they bring a mindset, attitude, bias, and skill that is unique to the SE tradecraft.
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog
