Who’s in Charge of Establishing and Managing an Enterprise Drone Program?

Part 2 of Creating an Enterprise Drone Program: How to Avoid Communication Breakdowns and Time Wasted Between Enterprise Clients and DSPs

We know who runs the world, right? Girls. Beyoncé answered that question for us in 2011, but who runs an enterprise level Drone Program? This answer is not nearly as straight forward, but having an answer to this question is required for a drone program’s safety management system (SMS).  There are four critical areas that need to be explored in order to come up with an answer to this question:

1. The Industrial Context of the Corporation

1. The Intended Applications of UAS Technologies

1. The Hierarchical Structure of the Corporation

1. The Workflows Impacted by UAS Technologies

In the first article of this series, we took a deep dive into the Enterprise UAS Sales Cycle, which offered readers some DOs and DON’Ts to consider when navigating a complex corporate hierarchy and it’s subsequent business structures. Now it’s time to explore what it means for both Drone Service Providers (DSPs) and corporate technology stakeholders to establish the structure of a drone program and effectively manage it.

The Industrial Context of the Corporation

The first thing to consider is the industrial context of the corporation in question. If you are the technology stakeholder for your corporation, then this is an area where you can take the lead.

DSPs are most effective when they can focus on their expertise in drones and drone-related technologies. DSPs should not be expected to learn the ins and outs of all of their clients’ overarching industries. Many DSPs do take on the responsibility of becoming experts in certain industries where they’ve been successful in selling their services/products because this saves them time during the next sales cycle. This pushes DSPs into a niche market and restricts their access to new clients within other industries.

I would argue that enterprise-level companies suffer as a result of the continued specialization of DSPs. Any industry that hasn’t engaged with UAS technologies at this point is at risk of being left behind. DSPs are tailoring their software products, services and marketing strategies based on what’s worked in the early to mid-formation stages of the UAS industry. This progression excludes industries that haven’t been as aggressive and/or haven’t had the resources needed to engage with UAS technologies yet.

Industries that are late to adopt the technology are going to be at a disadvantage and will have a harder time finding appropriate DSPs to help them in the future, but it doesn’t have to be that way. With a little effort up-front, technology stakeholders and UAS champions can take this burden off of the shoulders of the DSPs and free them up to do what they do best.

The only caveat to this assertion includes drone service providers that began as specialized service providers who then expanded their existing services to include UAS technologies. In those cases (and only those cases), I would agree that remaining specialized in their approach is the most appropriate way forward. This exception aside, let’s dive into how technology stakeholders and champions can make an impact here.

Be the Champion

As the technology stakeholder or champion of your company, you need to be the expert on your industry. You should be aware of all the regulatory and safety requirements that are relevant to your business operations. Any business process or service offered by your DSPs should be reviewed by a member of your company and compared to your industries regulatory requirements. Any aspects of the process, product or service that fall outside of industrial requirements should be identified, rectified and communicated to your DSP. This review process needs to be a standard part of your working relationship.

You or someone from your team should maintain an awareness of changes to your industry’s regulatory requirements and establish a continuous review process for any and all existing DSP products, services, or processes. Moving forward, maintaining compliance should be a top priority for the program.

As an example of what this should look like, consider a DSP that lands a sale with a mining company and begins to provide them with drone services. Let’s say that DSP is conducting flights for that company in the field and also storing media content on their behalf. The technology stakeholder should be responsible for training the DSP’s UAS operators on the safety requirements specific to each and every work site that they are asked to fly on the company’s behalf. The technology stakeholder should also be responsible for verifying that their DSPs meet these safety requirements before, during and after every flight. As with any internal employee or on-site contractor, the company should also provide training to their DSPs on any and all workplace hazards, safety protocols and emergency procedures that may apply. Best practice would be to mirror the frequency with which these trainings are provided to existing contactors or employees that are expected to work on-site.

Additionally, the technology stakeholder should be responsible for flagging any safety critical findings within the data that is captured during flight and ensuring that data management and retention practices follow the existing industry standards.

Bottom line, technology stakeholders within any corporation should be responsible for ensuring that UAS operations are within compliance of their specific industries regulatory expectations. DSPs should take the initiative to become familiar with OSHA requirements, and any other regulations that are ubiquitous across all industries as they will apply to all of their business engagements. Most importantly, DSPs need to bring the expertise on FAA regulations to all of their client engagements.

The Intended Applications of UAS Technologies

The second item to assess when working to identify who’s in charge of establishing and managing an enterprise level drone program is how the company intends to apply drones to their business operations. This can be a collaborative effort with equal amounts of responsibility on both the DSP and the technology stakeholder because both parties have vital insights to contribute to this effort.

DSPs typically eat, sleep and breathe drones. They have a keen awareness of what’s happening in the drone industry and are excited about it! That’s part of the reason you should let your DSP be the expert on drones, even in scenarios where the technology stakeholder has a background in aviation. There is a reason why you’ve hired a DSP and this is one of those areas where you should allow them to take the lead.

That being said, the technology stakeholder is the expert on the corporation’s operations, so this needs to be a truly collaborative effort. The intended applications of drones should have been discussed during the sales cycle, so this next step should build upon the progress made during those negotiations.

The As-Is State

Technology stakeholders should outline the operational areas that they are looking to enhance with drones by first explaining in detail what those existing operations look like without drones. This is the “As-Is” state.

Be sure to include a good amount of detail when assessing the “As-Is” state of operations. Here are some examples of vital details that should be included during the assessment:

• Which job tasks could possibly be enhanced by drones?

• Which employee groups currently complete these tasks?

• Which department(s) are currently responsible for these operations?

• What is the management structure for this area of the company?

• Which cost center do these operations currently fall under?

• What are the existing metrics that are used to quantify success in this area?

• What are some of the biggest pain points?

• What is the most costly aspect of existing operations?

This process should be initiated by your DSP during a needs assessment, but if it isn’t, be sure to take the initiative and gather all of this information for your DSP prior to implementing your UAS enhancements.

DSPs should be responsible for conducting an intake of this aforementioned information and then processing it all through the lens of an aviation expert. DSPs should ask a lot of questions during this phase. They should be seeking to fully understand the extent of their client’s operations as they currently exist. The DSP should be responsible for documenting this information in collaboration with the technology stakeholder and both groups should maintain identical copies of the conclusive “As-Is” status write-up. This write-up should serve as a baseline and be used as a reference point throughout the program’s development.

The Ideal State

After the “As-Is” state is fully documented, the next step is to map out the “Ideal State” collaboratively. This should begin again with the technology stakeholder describing in detail the improvements that they are hoping to achieve by applying UAS technologies.

The DSPs expertise in UAS can help to flesh out some of these ideal state aspirations, as corporate expectations tend to be somewhat general and/or unrealistic. This is an area where the DSPs can add a lot of value. The DSP should also be responsible for documenting and communicating back to their corporate client exactly what it is they understand the intended outcome, or ideal state, to be from their client’s perspective. Once the DSP believes that they have all the information they need, they should begin to identify specific areas within the operations that are plausible for drone enhancements.

These recommendations should be guided by the corporate client’s existing operational state, their intended ideal state, and regulatory requirements (specifically FAA). As mentioned previously, it should be the technology stakeholder’s responsibility to be aware of and take into consideration any industrial regulations outside of FAA and basic OSHA requirements. The conclusive documentation at this point should outline specific job tasks and/or series of job tasks that can realistically be enhanced by drone operations.

“[We] work with some of the world’s largest companies, some of which have relatively siloed units overseeing different assets and operations. In the power utility sector, for example, companies can operate solar facilities, wind farms, transmission & distribution lines, thermal power plants, hydropower facilities, and more. Each one of these asset types can benefit from drone technology, but the applications are often unique to that asset.” –David Bowen, VP Product Strategy, Measure

The Hierarchical Structure of the Corporation

The hierarchical structure of the corporation creating a drone program is an often overlooked aspect of working with vendors in general. Drone service providers are no exception, but I would argue that in the case of drone vendors, this topic is critical and absolutely cannot be overlooked.

For the most part, DSPs enter into business relationships with corporate clients unaware of their corporate structure. Any good DSP (or vendor for that matter) will have done some research on the company prior to this point in the business relationship, but even the most thorough vendors are still going to have blind spots.

Every corporation is unique in how they go about structuring their workforce. Some companies even use unique terminology for their functional groups or departments. As an example of that, some companies say “People Services” instead of “Human Resources”. That’s why it’s absolutely impossible for a DSP to fully understand a corporate client’s management structure without explicitly being informed about it by an insider.

“There are always various opinions of how [a client’s] UAV program should be managed. We offer best practices and advice, but ultimately [our enterprise clients] make their own decisions.” –JT VonLunen, President, RMUS

Technology stakeholders should be using the previously established “As-Is” and “Ideal State” write-ups to confirm which areas of the corporation are already involved in the operations targeted for drone enhancements. They can use the same information to deduce which areas of the corporation are most likely to be impacted by the proposed drone enhancements. Stakeholders should try to be targeted and exhaustive in this effort. They should be able to identify the entire chain of command for all of the business units that are expected to be impacted by UAS enhancements. This is important for DSPs to know because it will feed into the workflow integration process that we will get into in more detail in the next article of this series.

Typical levels of the corporate hierarchy that are affected by UAS enhancements include operational employees (i.e. inspectors, survey specialists, engineers, site managers, project managers etc.), tactical operational employees (i.e. employees that are members of a workers union), middle management (i.e. regional managers, operations managers, senior managers, directors etc.), corporate functions (i.e. supply chain, finance, legal, HR etc.) and  C-Suite Executives. How these types of employees are organized and managed is completely dependent on each corporation’s unique hierarchical structure. Sometimes operational employees are divided into many subset departments based on the company’s business purpose. That’s why it’s critical to explore the relevant aspects of your corporate structure with your DSP prior to implementing drone enhancements.

“Many of our enterprise clients have distributed organizational structures making independent regional decisions. [We’ve had] situations where one region prefers to collect data flying their own drones, while another region prefers to outsource everything. As such [we] offer [our clients] a hybrid approach, enabling some end-users to fly their own drones [with Firmatek processing] their data, while also [providing an end-to-end solution] to other [regions] as a turn-key solution.  One client with two very different approaches internally.” –Andrew Maximow, Chief Drone Officer, Firmatek

The Workflows Impacted by UAS Technologies

In the final step of this process, technology stakeholders and DSPs need to work together to identify any and all workflows that may be relevant to the proposed drone operations. This should be relatively easy for the technology stakeholder so long as the three previous steps were completed.

At this point in the process, the technology stakeholder and DSP should have identified and documented any industrial regulatory requirements specific to the corporation in question. They should have documented the “as-is” and “ideal state” of the companies operations, agreed upon potential UAS applications and identified areas of the corporate hierarchy that are, or could potentially become, affected by implementing UAS operations.

However, this last step is about being able to take all of this information one step further. At this stage, we need to identify the specific workflows and subsequent systems that will be impacted by UAS operations.

This will need to be completed mostly by the technology stakeholder, but the DSP can serve as a conduit for this process by asking questions and identifying possible gaps that haven’t been considered yet. As an example, say you’ve identified work-site inspections as an ideal job task for UAS enhancements. The next step would be to break that down into several pieces, beginning with a list of all the different types of work-site inspections that are likely to be included in drone operations. Then for each type of work-site inspection, the following questions should be considered:

• What generates the need for a work-site inspection?

• What information is included in a request for a work-site inspection?

• Who has the authority to request work-site inspections?

• Who has the authority to approve / deny a work-site inspection request?

• What is the priority level given to these types of work-site inspections?

• What system is used to record work-site inspection requests?,

• What system is used to record the outcome of a work-site inspection?

• What types of data are included in work-site inspection summaries?

• How frequently do these types of work site inspections occur?

• How are historical work-site inspection records organized / reported on?

• What system is used for reporting on work-site inspections?

• Which work groups consume the data generated by work-site inspections?

These are just a few examples of the specifics, but you need to realize that you’re essentially listing every employee and every system that is involved from inspection request to inspection report at this stage. This may sound tedious, but it is important and it will save a lot of time further down the road.

This groundwork will prove especially useful when it comes to seeking approvals for various operational needs. Think about it this way: you can invest the time now or you can invest the time later, and later will most likely be rushed. That’s when you’ll be trying to get a drone on-site for a critical inspection, but you’re not sure whom to contact for approval and/or the unplanned nature of your need catches your DSP off-guard.

“One of the biggest challenges we face with our turnkey operations is responding to flight requests when little lead time is provided by our customer. We try to express the importance of advance scheduling with our clients, since quick-turn logistics can lead to excessive costs. Furthermore, [we] manage a complex and very busy flight schedule, so assigning personnel and equipment can be difficult on short notice. That being said, we understand fully that at times our customers will have sudden needs arise, and we always do our best to accommodate our customers’ requests” –David Bowen, VP Product Strategy Measure

Producing a comprehensive roadmap of workflows and systems ahead of time significantly reduces the need for reactive drone operations by enabling both the technology stakeholder and the DSP to anticipate work loads.

Mapping out all of the relevant workflows and systems will take considerably less time to complete if the technology stakeholder can pull together a cross-functional team within their organization to contribute to the effort. The reason that a cross-functional group will allow this process to be completed more effectively is that the technology stakeholder is going to have limited knowledge about the systemic details in other areas of their own company. That’s just the way it is with all large corporations. There’s simply too much to do, and too much to know, and no one individual could possibly know it all.

“Operations may interpret the data and results one way, whereas Finance may have a different interpretation or need. For example, [Firmatek has] one client that still prefers legacy LiDAR scans as the ‘official’ reported result presented to Finance and the auditors.  By contrast, Operations requests drone-based photogrammetry data for ongoing daily inventory management. The data and results are exactly the same.” –Andrew Maximow, Chief Drone Officer, Firmatek

So Who Runs the Enterprise Drone Program?

The short answer to this question is a cross-functional management team, but what that cross-functional management team looks like will be unique to each company.

Establishing who is going to be in charge of running and managing your drone program should be determined by four key factors:

• The industry that you’re in

• How you plan to apply drones at your company

• How your company is structured

• Which workflows/systems are going to be impacted by your drone program

DSPs can be a resource during this process, but they are reliant upon the technology stakeholder for a majority of the information necessary to succeed.

Girls may run the world, but running an enterprise drone program is as much about corporate insight as it is industry expertise.