By David Long, Vitech President
Just like simplicity, not all precision is helpful. Heresy? Not for engineers. Engineers are taught to use the appropriate degree of precision for the circumstance at hand. Unfortunately, as systems engineers, we too often forget those lessons. The quest for precision can lead us astray, and some of our processes, methods, and tools actually feed this negative tendency.
At its very foundation, systems engineering is both systems (the big picture, holistic thinking, and emergence) and engineering (rigor and analytics). It is the second aspect – the need and drive for rigor – that can be a source of trouble. Rigor correctly understood leads to the appropriate level of precision given the current level of knowledge and the task at hand. Rigor misunderstood leads us to prematurely delve into detail design while still working at the systems level, to project precision where analytics don’t support it, to overwork a problem when a higher level statement of feasibility is more appropriate.
Too often, we present ourselves with a false choice. The alternative to precision is framed as “ad hoc” or the absence of rigor. That false choice is used both ways – to engage in analyses that are premature or unwarranted and to avoid all rigor because the time is not right or detail is absent. But the choice is not about precision vs. ad hoc. It’s about accuracy and the right degree of accuracy for the circumstances.
Scrum – the most frequently used approach for agile development – is deliberate in its focus on accuracy. In fact, a tool called “story points” is used to intentionally avoid precision. When estimating a task, the team assigns a given story a number of story points as a measure of relative size, complexity, and effort. It is not a measure of duration and is not precise. Story points are constrained to use the Fibonacci series (1, 2, 3, 4, 8, 13, 21, …). The team is not permitted to look at a story and say, “That is a 16.” Instead, they are limited to saying it is a 13 or a 21 (or any other Fibonacci number). In fact, when the team says a story is a 13, they are not saying it’s a 13 at all. They are simply saying it is somewhere between an 8 and a 21. The point of the story (and of story points) is that while sometimes we strive to be precise, it is always more important to be accurate.
What does that mean for systems engineering? We can begin with three basic concepts.
The right requirements. As we define the concept of operations, capabilities, and requirements for our systems, it’s about getting the right set of system requirements rather than enumerating every possible detail. As NASA physicist and businesswoman Ivy Hooks framed in so many requirements papers and in the book Customer Centered Products: Creating Successful Products Through Smart Requirements Management, we shouldn’t celebrate those who as an indicator of their system complexity brag about 10,000 or more system requirements. Instead, we should learn from those who identify the minimal set of tens or hundreds of fundamental system requirements at the top level and then appropriately stratify the other requirements at lower levels – always being accurate and then providing the right level of precision at the right time.
The right use of time. As we analyze the problem, explore the solution space, and ultimately specify the solution, we should use good engineering judgment. First, develop the top-level end-to-end descriptive architecture from need to logical to physical to test. Ensure the systems characteristics are accounted for, the key constraints known, and the fundamental drivers of system performance understood. Within this big picture, invest time and energy around the unknowns, the risks, the new requirements, the new technologies, and those aspects with high consequence of failure. Invest less where aspects are well known, well understood, and have been successfully addressed in prior projects. One of the traps of model-based systems engineering in particular is the desire to over-model and over-analyze. We fall in love with our models and modeling and forget the real purpose at hand. If we had infinite time and budget, exhaustive modeling would certainly maximize the likelihood of technical success. However, we are charged with meeting a customer need via the system of interest within time and budget, so good engineering judgment rather than precision for precision’s sake is key.
Tailoring communication. I recently sat in a breakout session that was addressing visualization and communication, specifically in a model-based environment. For over 30 minutes, person after person spoke of the difficulties of getting other people – particularly non-systems engineers – to understand them. When it came time to wrap up that topic, I pointed out that perhaps we (the systems engineers) were the problem. It may have been cathartic to share the challenges, but good technical communication is the responsibility of the systems engineer. Good technical communication – and good communication in general – begins with understanding the receiver and the receiver’s needs, not by focusing on the sender’s knowledge and desires.
To successfully deliver systems, we must begin by aligning the entire team around the big picture and then maintaining that consistent awareness throughout the life of the project. Within that understanding, we can then focus on specific details and operate effectively. However, as a colleague once pointed out, “You cannot understand the elephant by looking at it through a jeweler’s loupe.” In communicating the big picture – and sometimes in communicating smaller pieces from various subject matter experts and stakeholders – detail and precision become our enemy rather than our ally. That is the time for “architoons” (architectural cartoons), SysML lite, or other representations that accurately portray the concepts in a notation and a level of detail that the audience can understand.
There is absolutely a time and a place for precision. We don’t need to convince engineers of that. We must be precise in our use of language to ensure we align around our understanding of the problem, the solution, the impacts, and key considerations. We must be precise in our detailed designs as we specify the ultimate implementation to avoid ambiguity and the unintended consequences that too often follow. We need analytics and rigor at all levels – first order analytics at the system level to understand the critical system parameters and corresponding system performance, more detailed analytics as design detail increases.
Fidelity of analysis is always important, focusing first on accuracy and uncertainty and second on granularity and detail. It is the right level of accuracy and uncertainty – rather than arbitrary precision – that is key to the successful engineering of systems.
