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

For many years I have been an engineering and business consultant. Previously as an engineer, I learned to direct engineering failure analyses that later evolved into a process for resolution of broader multi-system engineering failures, and more generally, business concerns. An engineering failure analysis begins with finding out: “What happened?” and “What failed?” Answering these questions identifies the engineering failure, the engineering functions required to determine the root cause, and that ultimately, will lead to a resolution. Scaling this up to address broader science or business issues (such as a national pandemic) must begin pretty much the same way.

As an example, let’s suppose that you have been tagged to lead a Task Force that is being set up to address a new viral infectious disease that has been declared a pandemic in the United States. How would you go about it? I’ll suggest that you might want to consider the following.

You will begin with the formation of a Core Team that will be expanded to include representatives from organizations—government agencies, Universities and commercial enterprises—that may be able to assist this task force, including organizations and experts that may be located outside the U.S. For a complex problem like a pandemic, sub-teams previously defined as part of planning for just such an emergency—by the Centers for Disease Control and Prevention (CDC), for example—will be activated as needed, or formed if not previously defined, with a representative reporting to your Core Team.

Formation of this Core Team begins with interviews of key personnel. During these interviews you will: refine the initial Core Team membership, develop an agenda for the Core Team kickoff, and confirm the project objectives (scope). The real secret to the success of this kickoff is to make certain the right people are available who will be able to clearly define the problem, in this case, the origin and nature of this pandemic. During your interviews you will make certain that these people have been correctly identified and will be made available for the Core Team kickoff.

Preparations for the Core Team Kickoff

For all that follows, we will assume you have been designated as the Core Team leader, and that you have been brought in cold, with little prior knowledge of the organization(s) that will be involved or the specifics of the disease (still largely unknown) that your Core Team will be addressing. Your first task is to quickly gain an understanding of the organizations and the issues or concerns you are likely to be asked to address.

Interviews of Key Personnel

You might want to do a little research first, even if just internet research while on travel to the work site, to scope the project within a larger framework and maybe to come up with a few questions for your interviews. Your research will help prepare you for these interviews by identifying questions you may want to ask to initiate discussions or to use for redirecting the dialog.

Core Team Membership

Your sponsors will provide a partial listing of key personnel for you to interview. You may add others after reviewing your sponsors’ organizational charts. Your interviewees may also identify others who have some specific knowledge or are also contributing stakeholders. These expanded lists of key personnel and stakeholders will become your list of candidates for the Core Team kickoff.

Kickoff Agenda Topics

During your interviews you will invariably find that your interviewees will address a broad number of “topics” related to this pandemic that you will write down. Some interviewees may be organized and will provide you a list of topics they feel must be addressed, but most will not be this organized. Be sure to capture new topics as they arise. You will use this list of topics to organize your kickoff agenda.

For a top-level straw list of starting topics for our pandemic, let’s consider the following (for this example, drawn from basic research on the Internet):

• Source
• Symptoms
• Methods of transmission
• Mitigations
• Recovery
• Liabilities

During and after your interviews you will try to organize many of the topics you collect into larger headings and subheadings. Recognizing where and how a stakeholder becomes involved may help you to flesh this out by providing some rationale for the structure of your agenda. Consider the following expansion to include subheadings with some stakeholder concerns identified in parentheses.

• Source:
  • Probable location of origin (country or jurisdiction of origin will impact agencies involved)
  • Probable mode of transference to humans (will help to define characteristics and the genome of the virus)
• Symptoms:
  • Common symptoms that identify the infection
  • Less common or rare symptoms (may need to be addressed in treatment)
• Methods of transmission:
  • (The methods of transmission will help to identify mitigations)
• Mitigations:
  • Identification and isolation of those most at risk
  • Prophylactics
  • Treatment of symptoms
  • Vaccines
  • Social distancing
  • Lockdowns
• Personnel Protective Equipment (PPE) and other medical equipment and supplies:
  • Critical equipment and supplies
  • Procurement and distribution
  • Safety stocks
• Recovery:
  • Government assistance, federal, state, local
  • Reductions of extreme mitigations, e.g. lockdowns, social distancing
• Liability:
  • Risks to all levels of government, private businesses and individual contractors
  • Limitations of liability—federal, state, and local government; private businesses; individual contractors

After cleaning up your list, turn it into a straw agenda for the kickoff. You may want to get some of your interviewees to review and comment. You are not obligated to accept all of their recommendations, which may get much too detailed for the kickoff agenda. Details will be fleshed out in the meetings, or in assignments, or by sub-teams to be formed and activated.

Objectives and Scope Limitations

Your sponsor or sponsors may have a pretty good idea of what they want you to do (or they may not), and with multiple sponsors for a complex problem, they may have some different objectives. You will now compare this expanded list of topics with your sponsors’ expectations. You may have to address this list with your sponsors to revise their expectations.

Now take another look at the expanded list of agenda topics. I believe we can agree that the last topic, Liability, should be split off and addressed separately, perhaps in parallel, as you will not want the legalities of the laws associated with this topic to distract yourself or the rest of the task team. For another set of reasons, much of the first topic, Source, may have to be split off into a separate task team or teams. But be careful, an investigation of the source of this pandemic is critical for your Core Team. The probable mode of transmission to humans, the characteristics and genome of the virus, constitute the “problem” that your task force is being formed to address. However, if this virus originated in another country, many more issues related to diplomacy and national security may arise.

The State Department, international organizations such as the United Nations World Health Organization (WHO), U.S. military departments and U.S. security agencies may raise other international and security issues. The objectives of these organizations will be much broader in scope than your task force’s immediate objectives and should be split off into a separate task team or teams that will operate in parallel.

These specific reductions in scope, even if viewed that way, will not constrain, nor degrade, the initial work of your task team. You should have no trouble getting your sponsors to agree with you, as these limitations will clearly increase the focus and initial effectiveness of your task team. What you will have really done is define some related areas that your sponsors may want to look into.

Facilitation versus Technical Leadership

I’m going to take a brief deviation for a moment. I’d like to discuss the difference between “facilitation” and “technical leadership” as it applies to leading a task team of this type. For what we are discussing I should distinguish between the two. They are not the same. A technical leader often uses facilitation skills, as will you as the Core Team leader, but the skills possessed by a technical leader go well beyond facilitation.

Many years ago, I facilitated strategic planning retreats for boards of directors of non-profit and not-for-profit organizations in the Atlanta, Georgia metropolitan area. For these retreats, I provided an orientation to strategic planning, but even when asked, I would refuse to make a recommendation as to the future direction of a non-profit or not-for-profit organization. I did not feel that I had the background or knowledge necessary to make strategic decisions for these boards. In fact, this refusal supported one of my objectives, which was to get these boards to take ownership of their strategies. If I had just told them what to do…

This difference between a facilitator and a technical advisor is important in leading task teams of the type we are discussing. You will have been asked to lead this task team as a technical advisor, not just as a facilitator. So, what does this mean?

A facilitator focuses on process. His or her objective is to keep everyone on track with a singular focus. A technical advisor may sit in a meeting and say nothing for 20 minutes and then make an observation that changes the whole direction of the meeting. The focus of a technical advisor is on the substance of the meeting from a broad perspective.

Recall my comments earlier about how, during a failure analysis, the design engineers would “know” what had happened and “know” what the root cause of the failure was. These design engineers are very knowledgeable about their subdiscipline but are often out of their element in another’s area of expertise. That’s their job, to focus on their design.

But engineers often are forced to diversify, and some do as a matter of course. My expertise became trajectory analysis, applicable to missiles and spaceflight, but not much else. Still, as a systems engineer, I learned to lead troubleshooting efforts, and I learned to enjoy it. Soon, as a project manager, then as a program manager, I would lead more complex troubleshooting efforts encompassing multiple sites for support, or for launch conduct. This soon translated into problem resolution on a broader scale. I would sit in a meeting just listening, sometimes putting what I was hearing into a broader context. I would also pay a lot of attention to the speakers—not just what they said, but how they said it.

Was this speaker showing a concern that he or she just couldn’t put into words others would understand? This would often raise questions in my mind. But note that as a technical advisor, my questions would not be general, but cuttingly precise to help this person characterize this concern. General questions might keep the speaker talking but will not help with pinning down the concern. As a technical advisor you need both a solid general technical knowledge and development of expertise for doing this.

Problem resolution often entails asking the right questions and insisting on answers that everyone, especially myself, who is not a design engineer on this problem, can understand and restate. This forces analysis in plain language that often leads the discussion toward another related discipline. Another engineer, the one I’ve asked questions of or his counterpart, gets involved and runs with it, until another engineer picks it up, or I have to redirect it again.

Another visible distinction between a technical advisor and a facilitator may arise because of a technical disagreement. A facilitator will have conflict resolution skills, but these skills may be overwhelmed when the conflict is over a technical issue.

In this situation the loudest voice may win out especially when the loudest voice is an “expert” in a related area. The risk here is the same cavalier dismissal described for design engineers before being confronted with firsthand data (which may not be available, yet, for this pandemic). A technical advisor cannot allow a team member to overwhelm the discussion in this manner. To do this the advisor may have to drive the technical discussion.

I can’t give you a better explanation of what being a technical advisor means, except that you will have a breath of experience and the patience to explore the context, then find and ask the right questions to engage others who may lead the team in another direction. Sometimes the only arrow I have in my quiver is hard logic with a good dose of patience, and sensitivity…and tenacity. I can’t describe it any other way. But I’m often very successful. I assume you, having been chosen as this task team leader, have a similar skillset.

Coming in Part 2

In Part 2, I’ll look at the Core Team kickoff meeting, defining the problem, brainstorming, strategy synthesis, the action item plan, and closing out the kickoff meeting.

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: