Using your program management and leadership skills, how would you set up and lead a National Task Force for the next pandemic?

By Dan Harrison

The Core Team Kickoff

When confronted with a test failure, engineers will immediately think in terms of a pre-defined failure analysis tree or fault tree, but this leap skips the first critical step and will split the team down multiple false paths. Once you let this happen, recovery can be difficult and possible only after a large waste of time and energy.

Design engineers invariably feel that they “know” what happened and immediately want to jump to a root cause that they “know” is the reason for the failure. But their initial presumptions about the root causes are usually all different and mostly all wrong. In the first 20 years or so of my engineering career, as I either engaged in or led these failure analyses, I found firm agreement only once between several of the design engineers this early in the process. In this isolated case two design engineers were sitting next to each other at adjacent test consoles and had seen the exact same data on the same or adjacent console screens. (They had physically observed the data anomaly and would subsequently provide screen captures as firsthand datum to prove what had occurred.)

My first task is always to blunt the initial enthusiasm of a room full (or multiple sites full) of design engineers all of whom “know” what happened and insist on skipping the first boring step that I always require. I insist on first clearly defining what happened in sufficient engineering detail so that everyone will agree. This means identifying the individual(s) who physically observed the “anomaly” and having them describe this anomaly to the team with supporting data such as screen captures and other relevant firsthand datum.

It takes 10 to 20 minutes (20 minutes for a multi-site failure analysis team) just to quiet the dissention in the room long enough to get this started. Once the anomaly has been described with supporting data, many of the design engineers’ pet root causes will have fallen off the table. It’s a painful process that must be done to get the failure analysis headed in the right direction.

Scaling this process to address broader business issues changes the initial Core Team makeup but does not change what has to be done. Clear identification of a business problem is invariably painful but must be done using firsthand information. If it turns out that you don’t have the right people in the room, they will need to be called in or connected on a conference call, or the meeting must be rescheduled. Do not proceed without this firsthand information. In part, you are instilling within your team a discipline that must be observed.

Keep the introductions brief as you are likely to have a large number of attendees, but you will want to show your Core Team something that looks almost like an organizational chart so that you can describe both the structure and scope of this Core Team and its endeavor. You will be introducing organizational representatives and subject matter experts while showing their affiliation in this chart.

You may also be introducing individual experts and their fields of expertise. You may get recommendations for additions, but remember that this is your team, and you can add or move these representatives or experts to sub-teams as you deem appropriate.

After this orientation and introductions, you will review the agenda and the presenters. But before you are distracted with changes to the agenda, remind everyone that the primary objective at this meeting is to clearly define and document the origin and nature of this pandemic.

You should be prepared to kick this off in a logical sequence, or more likely, you will have identified a recognized expert to present what is known to kick the meeting off. What was the mode of transmission to humans, from what source? Is any history available for this virus? Is it known, a new variant, or unknown, and has the genome been determined?

This discussion begins with defining the problem this team is being formed to fight. Following this problem definition your Core Team will engage in a brainstorming session to expand and flesh out the agenda items. Next will be the beginning of a process where the team will lay out its course of action for this project. Finally, the team will build a network of these actions to encompass sub-team efforts with milestone dates and assignments.

Problem Definition

Prior to the kickoff, you will have discussed with the presenter(s) the content, the organization and the level of detail that will be presented. You should already have in hand a draft of the substance of this presentation in plain language so that you and all members of the Core Team will easily be able to understand it. This and subsequent documentation will become one of your biggest challenges for two reasons.

First, your team will be composed of experts in many fields some of whom may not be scientists. The problem you should be concerned with is not that the non-scientists will not understand what is presented. A bigger problem is that some of the experts in different fields may treat evidence from outside of their field cavalierly. Recall what happens when a team of design engineers first meets to determine the cause of an engineering failure. This is a problem you can expect to face at the kickoff. You must discipline your team to focus on clearly defining the problem with primary evidence from the field, upon first principles and in terms that all can agree upon. This is your first challenge.

Second, for any complex problem the documentation must be readable and understandable by non-technical business personnel as well as by technical experts from other fields. This requirement is absolute. You must take the time and insist upon making good notes whether you have an assistant writer, or not. This, and later documentation, will form the substantive output of this and future meetings, and the public actions your Task Force will ultimately recommend.

If you do not have the time, or cannot write well, bring someone with you who can. In the case of a complex Task Force with sub-teams, you will need writers for the sub-team meetings as well. Making this documentation readable and usable will become a major objective of your Task Force, as it will direct the nation’s mitigations and many other efforts.

If you are not able to completely define the problem at the first meeting, and that is probable, assignments must be issued to members of the Core Team perhaps for assignment to sub-teams they represent. Some of these sub-teams will still have to be formed and activated. Others may already exist but will need to be activated. These assignments must be documented as action items and tracked until closure.

All action items from the Core Team and all sub-teams should be compiled into one action item log for tracking all actions as a living document throughout this project. This log should contain the following:

1. Sequential action item number
2. Name of meeting
3. Date of meeting
4. Agenda topic during which assigned
5. Assignor’s name and contact information
6. Description of action
7. Assignee’s name and contact information
8. Requested due date
9. Date closed
10. Brief summary of the closure with references as appropriate

Do not accept an action without its being submitted in writing on a pre-printed action item form by the assignor. Do not accept actions that are trivial, or poorly thought out. Do not accept actions that are speculative (“What if?” actions). Review and discuss all actions in the meeting before acceptance. Force this discipline at the meetings and you will greatly reduce excessive expenditures of otherwise unnecessary effort that you cannot afford.

The Brainstorming Session

Following the presentation and the discussion surrounding the source of this pandemic, the next phase of this meeting will take the form of a brainstorming session. This will represent an analytical decomposition of this emergency. Your objective will be to expand and flesh out the agenda items to generate the team’s future investigations and other activities. Many of the investigations and actions that result will be assigned to individual experts or to sub-teams. Direct this portion of the meeting toward defining what needs to be done: what experts are available and what sub-teams need to be activated. You will get plenty of help—too much at first.

Earlier I described how, in an engineering troubleshooting meeting, the design engineers will want to jump to a pre-defined fault tree. Government organizations such as the CDC will have already developed something like this for a generic pandemic. Other government agencies will have their own pre-planned responses to a range of emergencies at local, state, and federal levels. Some of them will be on your task team and their experts will want to jump to their equivalent of the design engineer’s failure analysis tree.

You must resist all efforts to jump into your individual member’s emergency response plans at the kickoff. Acknowledge them, note them in your documentation and promise to return to review their plans later, but you must get through this brainstorming session first, or you may never be able to do so. This is a Requirements Definition Phase for your project. Failure to complete this process will cripple your Task Team’s efforts from here on.

A simple way to address this is to assign actions to all of these insistent experts to prepare and present their emergency response plan at a subsequent meeting (or sub-team meeting) at a date to be determined at the end of this meeting. That’s precisely what you will want to do anyway after the appropriate sub-teams are defined and activated.

Your efforts during this brainstorming session should be directed to fleshing out the content of the agenda items. This must be done in enough detail to identify subject matter experts or stakeholder organizations that will need to be called upon to address the issues being raised. This brainstorming session represents an analytical decomposition of the problem into a set of requirements that will define the rest of this project.

The Synthesis

We have reached the third phase of the kickoff meeting that begins what I like to call the synthesis. This portion of the kickoff may benefit from an existing emergency response plan that you happen to have in your back pocket. We’ll talk about that in a moment.

As the Core Team proceeded through the agenda in the prior brainstorming phase of this meeting, a set of investigations were identified that will need to be accomplished by subject matter experts or sub-teams (existing or yet to be formed). The completion of each of these investigations represents a milestone for this project.

You and your writer, or assistant, or volunteer will have been recording these “milestones” as the team proceeds through its brainstorming session. Many will also have been identified as action items. Now, at the completion of the brainstorming session, it will be time to find that emergency response plan that you had forgotten about in your back pocket.

Curiously, the team member who gave this plan to you during a prior interview before the kickoff is present. This team member has just assisted you by reinforcing your efforts to quell other team members’ attempts to skip the brainstorming session altogether. They had just wanted to jump directly into their organizations’ emergency action plans.

You now have (from your back pocket) an example to go over with the team. In addition, it will provide an example format similar to what your Core Team is about to produce: a comprehensive action plan for this Core Team’s pandemic response. You may now call upon your co-conspirator to present the format and high points of his or her emergency action plan as an example.

While your co-conspirator is presenting an example of an emergency action plan, you and another teammate, perhaps your writer, an assistant, or another volunteer from an interview prior to the meeting, are working in the back of the room to produce this Core Team’s list of milestones from your collective notes and the action items. This will soon be transformed by the Core Team into a first draft of a network with decision points and projected due dates for the Core Team’s emergency response to this pandemic. This will constitute the primary result of this kickoff.

The Core Team’s Action Plan

There are four steps required to produce this network beginning with the milestones that you and your assistant have been carefully noting throughout the brainstorming session.

1. You and your assistant will now review these notes and action items to extract as many of the milestones as you can identify while your co-conspirator is presenting his or her organization’s emergency response plan as an illustration. Once this is completed, the Core Team will probably be ready for a short meeting break during which you and your assistant will complete preparations for the next phase of this meeting.As the meeting recommences, you will announce your intent to build a network of milestones and decision points drawn from the earlier brainstorming session. Let your team know that you want to place these milestones in positions starting with the earliest completion dates at the top and the latest near the bottom. But you’re going to spread them out horizontally to show parallel activities. Let them know that they are expected to help with this. They are to jump in to help you place their milestones on the whiteboard, positioned near the front of the room, so that they can be related reasonably by dates. (This can be done with a computer and projector, rather than with a whiteboard, but I personally prefer the whiteboard.)
2. To begin this activity, you or your assistant will stand at the whiteboard and begin positioning the milestones as the other reads them off from the rough list you’ve just made. Members of the team will quickly jump in to correct your errors and omissions. That’s exactly what you want. Prompt them if needed.Once you have the milestones up, including the additions you had missed, it will be time to show how they are related to each other by drawing connecting lines. You may need to move some of the milestones about on the whiteboard to make this a little easier. With this done, some people may start to stand up to stretch, getting ready to leave. Let them stretch, and then suggest that they should take a few moments to put dates on these milestones.
3. It is time to put expected completion dates on these milestones and to add decision points as necessary. It will only take a few more minutes, and you may start anywhere you want. The team needs to provide what they feel are realistic, but aggressive, objective dates. When does the team really feel that they can have a vaccine with an accelerated schedule, for example? That will be one of the later milestones on this network. Work forwards and backwards from the first milestones for which teammates can give you expected dates. Now add decision points as necessary.
4. It may be time to stretch again, but it should be easy to assign names to each of these milestones, as most of the people who will track and report on their progress are in the room. This will go quickly.

Kickoff Close Out Activities

Congratulations, you have your first Core Team product, but you are not done, not quite. What’s left now is really just clean up. You started this project before the kickoff with a list of key personnel and Stakeholders from which you generated an attendance list for this Core Team kickoff. You need to confirm the Core Team membership at this time.

Put up a slide with the list of attendees to this meeting. In real time add or delete names and their organizations as necessary. This will be your updated Core Team membership list for notifications and minutes.

You will also need to confirm the sub-teams that will be activated. They were already added to the action item list, remember? If you have not taken a break recently, maybe it’s time to take a short break now before you go through the complete list of action Items prior to adjournment. After this all you will have left to do for this meeting following adjournment is the meeting minutes.

Congratulations! You’re off to a good start.

Dan Harrison is an SMA Principal Associate in our Technical Management & Engineering Services Practice, and has over 35 years of experience in aerospace engineering. 

If you’re building a team and you have positions you can’t fill, you need to use SMA Talent on Demand (TOD®)! With TOD®, you can find experienced talent, such as Dan, matched to your exact needs: