Following on from our previous discussion, here are five more strategies for improving your systems engineering projects. These ideas may be more technical than the previous ones, but they are valuable for any project:
Remember that consistent terminology is essential. For example, terms such as "power supply", "power source", "power supply module" and "PMIC" (power management integrated circuit) may refer to the same thing, but without consistency it's unclear. While using different terms may make storytelling more interesting, it's essential to be precise and consistent in systems engineering.
Humans are very good at automatically interpreting terms in a story or when talking to people. However, this automatic interpretation is based on context, individual experience and assumptions, and often leads to misunderstandings.
The problem is compounded, of course, when projects become international and involve many people who do not speak the same natural language.
Human communication has a verbal aspect, but is underpinned by many other factors. As discussed here, common ground, non-verbal cues, context and environment all play a role in face-to-face communication. However, when someone reads what you have written down, none of this additional information is present. In particular, when considering stakeholders, system team, external reviewers, international boundaries or a domain such as software or hardware, the common ground is simply not there.
When reading something, the words, the terms used, (and their context) are the only things available for communication. The importance of a common understanding of what they mean is greatly increased.
In a technical context, using multiple words for the same thing only leads to ambiguity, confusion and misunderstanding. Don't do it!
A common solution is to create a glossary for the project, but this tends to be unmaintained and incomplete. Ultimately, it is up to the team as a whole to agree what different terms mean, and up to each individual engineer to be consistent in their use of those terms.
You may disagree with the team's decision - but please, for the good of the project and to avoid misunderstandings, use the agreed terms.
Initially, the glossary can be populated using a technique such as domain analysis. However, in a large/long project, such a glossary can become large and terms can evolve to have different meanings as the project progresses (all languages evolve). Maintaining the glossary is important if you want to reduce ambiguity and misunderstandings.
In particular, try to maintain the same meaning for terms across team boundaries. I.e. make sure that the stakeholders, the systems team, the software team, the hardware team, etc. all use the same term for the same thing.
The requirements analysis part of the engineering process is usually covered in most good books on the subject. (If it is not, I would argue that it is not a 'good' book!) However, the importance of a good/thorough requirements analysis at the beginning of a project is often underestimated. Insufficient time/budget is allocated and it is rushed through or even skipped altogether.
There are multiple stakeholders, many of whom provide multiple documents containing hundreds or thousands of requirements. Almost all written in natural language (prose), with a few (probably informal) diagrams if you are lucky.
This is very short-sighted of the stakeholders. If they provided high quality, precise, consistent, formal requirements, they would get a much better (faster, cheaper, higher quality) delivery of what they want!
We cannot change what the customer (and other stakeholders) deliver. So we need to analyse what we are given and produce a high quality, precise, consistent, formal requirement specification for ourselves.
It is well known and documented that poor requirements are the number one cause of project failure. According to the Project Management Institute, 47% of project failures are due to poor requirements management.
Furthermore, the cost of poor requirements increases the later in a project the problems are discovered. The following chart, although based on purely fictitious data, illustrates the point.
Cost of issues due to poor requirements
How do we avoid this?
Simply spend the time/effort/cost at the start of a project to properly analyse stakeholder requirements and update this analysis as stakeholder requirements change.
A good system analysis should cover things like
Time invested in requirements analysis at the start of a project will be more than recovered by the end of the project.
Given the nature of today's and future systems, the analysis of stakeholder requirements and the architecture of a large and complex system cannot be done in the heads of engineers or using informal natural language sentences.
Analysing and architecting today's complex systems requires tool support and a formal (or at least semi-formal) model of the requirements.
The idea of using models to support requirements analysis has been around since (at least) the 1980s. In the 1990s, UML was standardised, and in 2001 the SysML (system engineering version of UML) initiative was launched.
SysML contains appropriate concepts (syntax and diagram types) for capturing the essential things that make up a good system analysis model and system architecture.
Good system analysis and architecture models will not completely eliminate the need for natural language (text) based system requirements - but they will
A good tip is to keep analysis and architecture models separate. You need to have traceability between them, but several smaller models are easier to manage than one huge one. In particular, (today's) commonly used modelling tools struggle with large models.
As a project progresses, the understanding of the problems becomes clearer (with any luck!), and so the decisions made at the start can be adjusted on the basis of the experience gained.
Initial decisions are based on guesses and past experience with similar problems. Over time, as knowledge of a particular project increases, better decisions can be made.
This is normal and should be expected as part of the development process. The processes, methods and tools used in a project should be designed to accommodate such changes.
There are different types of change:
Refactoring refers to the kind of changes in point (3). It may seem that these kinds of changes are pointless. They may not change the actual solution or affect the final product, but they do improve understanding, clarity and communication.
In the software world, refactoring is accepted as necessary and is supported by most software tools. Refactoring is a key process for reducing technical debt.
The same applies to system requirements and architecture. In particular, as you move from natural language requirements to more formal specifications, accepting refactoring as a necessary change will improve the quality, clarity and understanding of the system specifications.
Don't resist change - embrace it!
Communication is the key to human success. Just google it (or click on the link, I did it for you 😉).
A systems engineering project tends to involve many people (hundreds of them). Projects also tend to last several years. During this time, the people involved change. The new people don't know the history, they don't know why certain things were decided. Even people who have been involved in the project from the beginning sometimes forget or were not present at the meetings where decisions were made.
As a member of the team (and I mean the whole project team, not just a specific domain team) you have to actively seek out knowledge, actively learn. Learn about this particular project, and learn new things that might help the project.
Actively learn
All team members, especially team leaders (and I don't mean managers - I mean leaders, which can include managers), communicate constantly. Educate the people in your sphere of influence with information they may have missed. Don't assume that everyone knows something just because you do.
Never assume! Always communicate.
Make every day a learning day and never think you have communicated enough. Remember an aspect of Brook's Law:
"The communication overhead increases with the number of people".
So in a large team, you need to communicate excessively 😄
Conclusion
To conclude:
Train, learn and communicate - all the time.