Here are five tips to boost your systems engineering projects:
It's easier said than done, but this is really my number one suggestion. Having the right people in the right roles greatly increases the likelihood of a successful project.
When you find talented people, treat them well - they're your greatest asset. Trust skilled engineers to excel at their jobs without micromanaging them. A good engineer is passionate about their work, takes pride in it and wants to create a great product. They're often constrained by time and budget, but the best engineers understand this and work within these limits. Encouraging a good engineer to improve isn't usually necessary; instead, you often have to persuade them to scale back their ambitions to fit the budget.
Allow engineers to take pride in their work.
Avoid burdening them with inefficient processes, inadequate tools or unrealistic expectations. Listen to their input and create an environment where they can perform at their best. Recognise that a one-size-fits-all approach won't work - people are different, so establish working standards and processes that allow for individual variation while maintaining consistent quality. This can be challenging and may require some compromise.
Leadership, particularly in technical roles, is an often overlooked skill. Many people end up in leadership positions without adequate knowledge of how to be an effective leader. It's important to understand the difference between management and leadership. While this article won't focus on leadership skills, it's worth noting that good leadership can have a huge impact on a team's motivation and effectiveness.
Create a well-written system design based on all other stakeholder requirements combined. Customers (for example) provide requirements. There are no other requirements, i.e. no discipline (SW, HW, etc) specific requirements.
Requirements are part of a contract between two parties who want to be able to prove that something is or is not fulfilled for financial, security, etc. purposes. The two parties are not on the same team, one is providing something to the other and it is necessary to clearly define what is required.
Within the same company this should never be necessary, it is the SAME company, therefore the same team. There should be no need for contracts within the company, everyone should feel that they are on the same team and contributing to customer satisfaction.
From a technical perspective, the system design team must include the lead domain (SW, HW, etc) architects. The system can only be designed correctly if these people are involved. The system is the combination of what the different domains produce. The systems team is there to make sure it all fits together, to provide a bridge and communication path between the different domains.
Stakeholder requirements come in all shapes and sizes. Sometimes good, sometimes bad, the systems team has little control over customer requirements. However, the team should always be prepared to push back on a customer and tell them where their requirements are problematic, inconsistent, ambiguous, etc. - garbage in means garbage out, you can't produce a product that satisfies unclear requirements.There are stakeholder requirements. There is a system design and there are software (SW), hardware (HW), mechanical (Mech), etc designs that implement and contribute to the system design.
Why do I say that behaviour is king? Well, because if I just want to buy a box or a brick, I don’t need a system. Systems exist because of the behaviour they exhibit, not because of their size or their weight.
Most modern systems (certainly in the field I work in) include a lot of software. It would be nice and easy, if the systems team could simply delegate behaviour to software — “That is a behavioural requirement or issue, therefore it’s a software problem not ours.” — I have heard that said!
Maybe systems engineering can get away with that approach under certain restricted circumstances, i.e. one processor and the hardware and mechanical parts are just there to support the processor. However, interesting, modern day systems are rarely like that. Most include multiple processors, and involve hardware, firmware, mechanical, and maybe even other domains such as optical, security, etc.
The behaviour of the system as a whole is provided by the interaction of multiple parts from multiple domains.The system team needs and must take ownership of this distributed behaviour. They must design it and understand it and it has to be tested at a system level.
This is not a trivial task. Designing and modelling (writing down, describing, specifying) behaviour is not easy for complex systems, and simple text is a really bad (in particular ambiguous) way to do it.
To do it well systems engineering must take ownership of three things:
The system generally has complex behaviour and it can be broken down into sub behaviours. These are referred to by different names: Features, Use Cases, Scenarios, System functions, etc. The important thing is that they sub-divide overall system behaviour, but still treat the system as a black box. The sub-behaviours (I will use the term feature from here on) are still behaviours of the system as a whole.
How the behaviour is broken down and provided by parts within the system. This is probably the most important aspect of “system design”. This should be done in collaboration with the other domain leads, as it result in the definition of the parts (some people name these Functional Blocks) that are ultimately realised by specific domain parts. The breakdown at system level should be sufficient that one Functional-Block is implemented by one domain. i.e. a Functional-Block is realised by either HW or SW, not both.
Mapping
The mapping between behaviour and structure is a matrix. Features (behaviour) go on one axis, parts (structure) goes on the other axis.
The matrix content shows which parts of the system are used to provide which features.There may be “One Ring” but there is no one tool that rules them all. There is no single tool that can be used for every task involved in engineering projects.
The best approach is, in collaboration with the engineers who use the tools, to define the tasks that need doing, and look for tools that support that task. A tool that is design to support a single task is probably much better at supporting that task than a general purpose tool, or a tool that was designed for something else.
What is the best tool for opening a tin of food? A Swiss army knife, a tin opener or a screw driver?Let’s start with IBM DOORS. This tool is “the” tool in most System Engineering projects I have worked with. I could imagine a sales slogan from IBM along the line of “if you are not using DOORS then you are not doing System Engineering”!
As is says on the product website, IBM DOORS is “is a requirements management application”. Whether you think it is a good requirements tool or not (there are many other options, e.g. Jama or one of the others from this list), it is a tool that is designed for managing requirements.
DO NOT use it for something else!I have seen several miss-uses (or abuses) of DOORS and it pains me greatly. Why? because:
Some of the abuses of DOORS I have seen include:
Traceability is of course important and it can be easy to get tempted into misusing one tool for the wrong task simply because it enables easy traceability.
DO NOT do this!There are many independent traceability tools, that enable traceability tracking between multiple different 3rd party tools, often with no need for additional manual involvement. If your favourite tool is not connectable, I know a Traceability tool vendor who is more than happy to add a custom connector on-demand.
The following, of course, applies to all tools in your tools chain:
Use the right tool for the right task, and do not abuse a tool by using it for something it was not designed.Oh, and before you get tempted, an Excel sheet on a shared drive is NOT a good solution for anything! Although it is quick and easy to set up, in general there is a better, purpose built tool, to do the job.
I have seen such a lot of time spent by engineers on counting and collecting data for metrics, rather than on engineering work. This really is such a waste of company resources.
In this day and age of IT based work, if you can’t collect the data automatically, then there is a big problem with the way you are working. Collect the metrics automatically, or don’t collect them at all. Aside from the fact that it is a waste of time for the engineer doing the counting, people make mistakes when counting things, machines don’t. The metrics will be far more reliable and give more accurate information if automatically collected.
Secondly, make sure the metrics are a true indication of what you want to know. Explain fully how a metric is computed, do involve the engineers in setting up the calculations, so that they agree that the metric is a correct representation of whatever is being measured.
Ensure that part of the explanation of a metric, includes a range for where the value is OK, what it means if the metric is out of range and what should be done to bring it back in range. Basically, don’t measure something without knowing what to do with the result of the measurement.
To conclude, I will simply repeat how I started, though more briefly: