Why should anybody care about your Enhanced Functional Block Diagram? “WHY” indeed.
Any systems engineering diagram, no matter how meticulously built, is worthless if not widely accepted and utilized by organizations other than the originating author. The possibility of acceptance and adoption comes down to two factors: the right diagram for the right audience and the effective initial introduction of the diagram. The former is paramount when dealing with very specific audiences (or very zealous users) for very specific purposes. The latter will be the focus of this paper, using examples from the use of the Enhanced Functional Flow Block Diagram (EFFBD). How do we introduce team members, with various backgrounds in engineering and perhaps, in business to EFFBDs and achieve unequivocal buy-ins from the majority of the audience?
Is This Your World?
It is as beautiful as it is technically sound. You have spent hours in GENESYS to create the most comprehensive behavioral model of the Vehicle Management Computer (VMC), complete with relationships, attributes, and a bulletproof structure. Your simulation even runs. You invite the relevant stakeholders to a meeting to review the EFFBDs and lockdown the baseline. Half of the participants start the meeting by asking you what an enhanced functional block diagram is. The other half is mentally checked-out at the first multiple-exit construct. The explanation of the model goes on painfully. But at the eleventh hour, you get all of your buy-ins. You can’t decide if your stakeholders really understand everything you have presented, or if you have just worn them out for a yes-vote. You allow yourself a quiet celebration for a hard-fought victory. Then that much-dreaded question comes up, “So this looks nice and all, but why are we doing this? We already have the requirements.”
This is when you make the biggest mistake of all mistakes, “The boss wants you all to approve the model so we are clear on the interfaces. And you guys in VMS can develop the behavior into your own functions.”
But, we do already have all of the requirements, the look on their faces protests.
The meeting adjourns. The next time you need another round of buy-ins, half of the participants only want to review your work offline . The other half starts sending “delegation of authority”, which creates even more confusion and requires even more explanation. Do you and your colleagues really perform a job just because the boss wants it done?
An Alternative Approach
The example I provide may be an extreme case of challenges in teams communication. But, as systems engineering practitioners, we all have experienced push-backs on the importance of our work one way or the other. Selecting the right diagram and/or document for the right audience does alleviate some of the pain. However, at some point in your career, you will need to present a certain complex diagram to a diverse audience. Some people can never be won over; they will oppose your tool and methodology until the end of time. But with an effective communication strategy, you can change the minds of the majority.
We will follow some best-practices in planning and running a meeting. You would be surprised how a well-written meeting notice can promote clarity for the actual meeting. A well-stated subject line can enhance the audience’s interest even if they do not bother to read the actual description. The make-up of your participant list can also make or break the dynamics of the meeting. And believe it or not, the choice to host the meeting in-person or virtually can affect your success as well.
We will leverage the nature of the behavioral diagram, the EFFBD in this discussion, to do most of the talking and convincing. Whether you are dealing with an engineering logic or a social process flow, they are all behaviors. Humans are wired to understand behaviors innately. If you allow all the information that you need and nothing that you don’t, to speak for itself then the EFFBD is quite easy to follow.
We will apply Simon Sinek’s Golden Circle to our communication with the stakeholders.
The idea is to communicate from the inside of the circle out: starting with WHY (a purpose, a cause), moving through HOW (the method to realize the cause), and ending with WHAT (the actual products). In the earlier example, your audience has no idea WHY you are explaining an EFFBD to them. Hence, they have a hard time following HOW you have come up with it, and WHAT exactly that it does. The Golden Circle only works if it is in balance, with the clarity of WHY, the discipline of HOW, and the consistency of WHAT- in that order. “Start with WHY” can be applied to a wide range of endeavors such as running a business, selling a product, starting up a company, or doing anything that seeks undying loyalty and lasting success.
Before going into what we should do to set up the first “encounter” with the EFFBDs, let us look at what we should not do to a brand-new set of diagrams. The worst way to introduce your work to the audience is tell people to go into GENESYS and view the EFFBDs. There are always those members (even non-users) in your organization who want access to everything, GENESYS included. But, what are the chances of them actually going into the tool to do a review when prompted, and do it correctly? Even if they do, there is no context, no guidance, no available help for your audience as they attempt to understand your work. You are neither telling them your WHY nor explaining your HOW. And your WHAT is completely foreign to the majority of your audience.
What about sending the EFFBDs out for review in the HTML form or in a detailed report? You would probably get a larger audience to participate; the review format is more accessible and familiar. But again, there is no WHY and HOW, and the WHAT is confusing at best. Unless you are seeking a peer-review among GENESYS power-users, you should always introduce behavioral diagrams in a well-organized meeting.
Now that you have decided to call a meeting with all relevant stakeholders, would you rather hold it in-person or virtually? As virtual meetings have become more necessary in this day and age, you might lean toward this option, even if you still work in a physical office. However, being able to see the faces and read people’s emotions in the room often aids the ability to interact and resolve complex issues. Body language and facial expressions can offer clues to where is a lack of understanding or resonance with what they are seeing.
Selecting the meeting participants is the next important step of your preparation strategy. The Law of Diffusion of Innovations states that 2.5 percent of the population are the Innovators, while 13.5 percent are the Early Adopters. These two groups are the likely driving force for the spread of ideas. If you treat your work with EFFBDs as a new product to be adopted by the masses, include these “early” people in your overall strategy. It means that they will be more open to your “innovative” idea of using the EFFBDs. They will ask the right questions in the meeting and foster a healthy discussion. And once the meeting is over, they will keep talking and promoting your work. They are the first to share your WHY. They will help you sell your HOW and WHAT. So, who are the Innovators and Early Adopters on your project?
“Enhanced Functional Block Diagram Review for the Vehicle Management Computer,” the subject of your meeting notice reads. Is it an effective first impression? If I work Requirements or Reliability, does it sound like a meeting I want to attend? Let us consider an alternative: “Review the Effects of the Vehicle Management Computer’s Behavior on the Aircraft Design”. Yes, sign me up! (Mostly because I want to make sure your work does not muck up mine). The first subject states the WHAT, about which some could not care less, and most already have doubt and confusion. The second subject removes the WHAT, but states WHY we all should care about this review meeting. On a project, we might work on different WHATs utilizing different HOWs. But, we share the same WHY – in this example, the successful design of the aircraft. I am going to your meeting because you make me realize your WHY and mine align.
Starting the Meeting
Everybody who should be here is here; the meeting starts. You want to jump right into showing off your wonderful EFFBDs. But you will not. Simon Sinek’s Golden Circle also applies to starting a meeting: with WHY. People are here to be inspired by what your behavioral model (and the corresponding EFFBDs) can do for them and their work. A review is just a HOW, while the diagrams are just a WHAT. Fortunately (by design), as you and they go through the process of WHY > HOW > WHAT, they will naturally review the diagrams for you, which is what you wanted all along. And, with a little bit of help from your “early” allies, the majority will also accept and embrace your tool and methodology. So, start with WHY everyone should care to be here:
“The VMC behavior will drive the work of the Flight Science group, Subsystems group, and Communications group. We will also have an opportunity to identify gaps in our current requirements. There are some new functions that might affect costs, schedule, and risks. And there are a few redundancy issues Reliability might want to take a look at.”
It is sometimes amazing how people forget that Systems Engineering is supposed to be the connective tissue to bind the teams together. The work by the systems engineers should benefit everyone on the project. Starting with WHY reminds people of that.
Now that you and the rest of the team are on the same page, it is time to discuss the HOW. Keep in mind that you are trying to “sell” two things at the same time: your work with the EFFBDs and the meeting you are running. Set the stage so that no one will wander off the path. A little off-track wandering will lead to a complete loss of direction and a waste of time.
First, state how you will run the meeting, set an agenda that supports a disciplined relationship with your WHY. If your WHY mentions the tie between the behavior and requirements and reliability, you had better include those items in your meeting.
Second, explain how you came about to understand the behavior of the vehicle management computer and build the model using the EFFBDs. It is more difficult to demonstrate how disciplined this HOW is in one meeting. Once, you have conducted enough review iterations, people will be able to judge your tool and methodology over time.
At this point, the stage is set. Your WHY is clear and your HOW is disciplined. You are ready to unleash the power of GENESYS. But, you should wield this power responsibly. The metamodel is as comprehensive as it is complex. In my experience, “the first impression” is where typical “SysML diagram engineering” usually has a leg-up on “metamodel-based systems engineering”. To an unfamiliar audience, viewing simple (and usually disjointed) SysML diagrams allows them to focus on the comprehension of new engineering information, without the burden of understanding the metamodel. If you, as a GENESYS power-user, cannot strike the balance of presenting the engineering information and explaining the schema which conveys it, you are doing your tool and methodology a disservice. The enhanced functional flow block diagram can tell a very compelling story of the behavior using Entities, Relationships, and Structure. Let it speak for itself. If something is not related to the behavior shown on the EFFBD, you probably do not need to cover it during the first pass-through. Your schema is awesome, but your audience does not need to see everything, just enough for you to “sell your WHY”.
To be continued . . .
In the next installment we will go into how to tell the behavior-story in a review meeting, and go over some tips and tricks.
It been my experience that SADT/IDEF0 does a much better job if breaking down and displaying complex behaviors. It covers all the bases, hierarchial behavior context, inputs, outputs, mechanisms and control. It forms numerous useful hierarchies. These hierarchies neatly organize needed inputs, desired outputs, command and control structure, hardware and software. I really don’t understand why people quite using and improve it.