cohost-Systems-Engineering-or-why-james-gets-p #

Once your project has multiple people working on it, sometimes with widely different experiences (e.g. the ‘software folks’ and the ‘hardware folks’ and the ‘manager folks’ and the ‘product folks’ and so on), the concepts of “what are you building” and “how are you building it” seem to get away from teams and organizations.

Why aren’t more people doing “systems engineering”? #

They might think about breaking a problem down in to parts as an individual engineer solving problems, but don’t have a lot of tools for breaking down “team sized problems”. “Classical engineering” folks in electrical and mechanical domains tend to have seen some of the processes and formality around systems engineering before, but haven’t necessarily internalized why certain approaches exist. This gets a little weird in the time between “the requirements say what the system will do”, and “the requirements say what the system does do”. In the ideal world, you should be able to:

• Have someone come in for their first day
• Know what they need access to, before they start
• Point them at one document (which might link to other ones)
• They should be able to read this document
• They should know generally how to start working with your team Again, you can capture this information however you want. These documents end up acting a bit like “process requirements”:
• They should be a living document over time
• Everyone should know where to find them
• If there’s a disagreement, the “process requirements” should have the answer, or if it doesn’t, you should come to a decision and write it down
• Incomplete is okay (but improve it as you go!