top of page

Business Continuity


This program is about the planning and execution of the recovery of business operations in case of an emergency. This was a program that had difficulty getting off the ground.


Mandatory training attendance was routinely 40% and a high fail rate of practice exercises. 





I learned the discipline & interviewed the recovery staff. I discovered that:


Unclear purpose of the program. 

  • Unclear roles & responsibilities 

  • Unclear recovery framework

  • Unclear recovery priorities 

  • Users did not feel supported while building a continuity protocol.


There was a conflict between what the executives wanted and what those expected to perform the recovery needed.

  • Staff performing the recovery needed a well thought-out and structured plan and needed to feel supported.

  • The executives wanted a simple protocol to check off as an audit item. 




Increase engagement from 40% to 90% 

Increase NPS from -100% to +90%




I took the previous top-down model and flipped it to grassroots, bottom-up approach with the goal of educating and empowering the recovery staff. During an incident, I oversaw the recovery, managed the needs and requirements of the departments, kept the C-suite and Sephora's parent companies updated and composed communications on behalf of the C-suite to the CEOs of Sephora's parent companies. 


Aside from the departments stating that they now finally understood how a recovery worked, there was a higher level of staff engagement and found substantial financial savings due to cross-functional data alignment.


It's all about





As an experience designer, I incorporated many design thinking/UX design principles into the program. I realized early on that the program must be user-centered to be successful. After all, there are times when the program asks users to put the needs of the corporation ahead of their own. The only way to motivate them to do so is to make users feel supported, competent, and valued.


This is a case study of the most wide-reaching and complex project I have tackled. 


Sephora, a $4 billion dollar company with over 20,000 employees, needed a program that could be initiated if an operational disruption were to take place (e.g. office/warehouse structural collapse, network failure, cybersecurity breach, PR/branding incidents, or staff safety concerns).


Various department heads were tasked to build the program but were unsuccessful. I was asked to help develop a program that engaged the users and set them up for success. 









The Previous Program & Challenges

There was a rudimentary program in place but it came with a number of challenges

  • Recovery procedures were unclear and confusing.

  • The program had a high degree of complexity. It had to also be flexible since execution of the program was situational (e.g. program execution was different if there was a terrorist attack at the headquarters vs a social media crisis vs a hurricane that impacts the stores).

  • The documentation that was terrible to slog through. Content was dry, formatting made it difficult to read, and goals and objectives were not differentiated between to various user groups. 

  • The users were clearly unhappy about being chosen as part of this program. No additional compensation was given and the program made demands on their time.

  • The nature of the program requires that staff participate in a recovery that would potentially put the company's needs over their family or their own.

  • The C-suite mandated that VP's and Directors across the company attend trainings. Participation rate was routinely 40%.

  • To be effective, the program required that the program leaders needed to exert influence without authority.

Problem Statement
How might we build a comprehensive program to recover the company that is simple enough for the users to understand and execute?
Initial metrics
Participation   40% show up rate to C-suite issued mandatory trainings
NPS   -100%


It was important that I uncover why the program was so challenging to get off the ground and the reason for the high degree of hostility towards the program from the staff. 


Exploration of the existing program included

  • Perform "competitive" and comparative analysis of programs implemented by other organizations

  • Literature review

  • Surveys & Interviews

  • C-suite interviews about the role of the program to meet business objectives

    • What did the executives (those in charge of recovery strategy) care about?

    • What metrics did they want to meet?

    • What did they think of the current (and previous) plans?

    • What were their pain points?

  • Business Unit Head Interviews

    • What did the departments (those in charge of recovery logistics) care about?

    • What were their pain points of the past plans?

    • What did they think would help them make this program easier for them?

    • What matters for the company in case of an incident?

  • Recovery staff interviews and surveys

    • Can we differentiate between core functions and fluff?

    • How quickly do we need to recover what and why? 

Comparative/Competitive Analysis

Business Continuity program asses is kept confidential as it maps out all the sensitive areas of a business. I instead reviewed continuity programs of government agencies (FEMA, CERT, Police/Fire) and asked targeted general questions of those in private industries (Target, Macy's, JC Pennys, The Limited, Kaiser Permanente, Mechanics Bank). 

The goal was to compare Sephora's existing program to other established programs. 

What I learned is that the program has roots in the military and takes a traditional top-down approach, a "command and control" approach if you will. Usability or service design is not an ingrained principle in business continuity. 

Literature Review

I reviewed a few books on implementing a business continuity program. Many had great ideas but leaned towards the theoretical. The challenge with Business Continuity is that different industries have different requirements which makes writing a "how to implement" book challenging for the author. 

In addition, because the field is traditionally a top-down "command and control" nature, I found the need to deviate from this way of implementation.



Tools Used

  • Affinity diagramming

  • Service blueprint diagramming for each of the various "users" involved in the program

  • Experience mapping

Affinity Diagramming

Four areas of concern about the program came from the interviews:

1. Don't see the value/waste of time; 2. User Roles are not valued within the organization/what's in it for me?; 3. Afraid the info given will cost them their jobs; 4. Don't understan the program

These findings were particularly troubling because this was a "voluntary"  (volun-told) program where users are expected to put the company's needs ahead of their own in a crisis. Staff were not given additional compensation for this service.


service design mission
To Motivate, Inspire, and Empower users to care about and execute the program

To accomplish this, I needed to rebrand the program to dispel of its negative impression on the staff and create a new User Strategy/Guiding Principles.


user strategy/
guiding principles
Friendly tone
Educate to Empower
Show we care 

Transparency: The program needed to show staff that the information given could not be used to eliminate their positions

Friendly Tone: No more manuals that looked like IRS tax code documents; they needed to look and feel simple

Educate to Empower: This is a scary role they have been volunteered for! Give staff the tools and knowledge so that they feel competent to do the job well

User-centered: self-explanatory :)

Show we care: If the staff did not feel like the program/company truly cared about their well being, they will not rescue the company when the company needs them the most.   

This program touched various aspects of the business, from the executives to finance to legal to communications and PR to the Emergency Response Team. I lovingly referred to the program as "the octopus."

A user-centered Business Continuity program was not the norm, as it is a program born from rigid hierarchical organizations (military). Business continuity has long been known for being challenging to learn and execute outside of governmental agencies. 

Senior industry experts attribute the lack of interest in the program as a "marketing problem." I attributed to the lack of focus on the users. 

Experience Mapping

The journey of bringing the user onboard with the the program was carefully considered. The user was almost always an unwilling participant. The experience map helped us think through the user's thoughts and feelings during the journey and opportunities for program improvement in order to turn them into promoters of the program. 

Service Blueprint

Each of the contact points for every user group was mapped through a service blueprint diagram. Touchpoints for the planning stage as well as the business recovery stage were mapped out as well. 

There were numerous touchpoints between the program and staff at large and each touchpoint was an opportunity to better serve, educate and influence the staff.


The initial version of the program included only departmental plans and strategic guidelines. As the company itself grew, it necessitated the redesign of the program a few times with the scope of the program increasing as well.


Each asset and business process redesign/reconfiguration amounted to a mini-usability project itself (from discovery to synthesis to design and iterative usability testing). To illustrate, I've selected a few to talk about in this section. 



  • Recovery Manuals

  • Recovery "Wallet Cards"

  • Business Impact Analysis Form


Usability tests were performed before the release of the assets. The idea is that a user may not have recently undergone a training on how to use the assets. The goal was to obtain at least 80% of current plan users understand how to use the assets without input from anyone in the program. 



Business Processes

  • Recovery Organizational Charts 

  • Communication Flows

  • Recovery Frameworks 


The organization of staff and communications during a crisis is markedly different from business-as-usual. Therefore the org chart needed to accommodate and target specific recovery functions. These business processes were iterated upon until we found a solution that worked the most effectively.


  • Recovery Manuals


Because we couldn't rely on electricity being available, recovery materials were created in analog. This made cross-referencing and hyperlinking a challenge. 


The old recovery manuals looked like pages ripped out of a law textbook, complete with sections, subsections, and clauses. With few exceptions, the manual was in black and white and protocols were written in paragraphs. The document was 120 pages in length and held together by a staple.



Feedback from staff included: 

  • Manual was too difficult to read and understand

  • It was too difficult finding items in the manual that was relevant to their needs

  • There was no onboarding from the consultants who created the manual; staff felt like they were left to fend on their own

  • The protocol was too difficult to remember under stress

  • It would be impossible for staff to remember anything about the recovery if they had not recently undergone a recovery training


To solve these problems and to adhere to the guiding principle of setting a "friendly tone" and making the program more user-friendly, the resultant manual looked like the below.


  • The information architecture of each of the manuals was mapped out.

  • Procedural steps were broken into checklists and owners of that step was made clear wither at the strategic, tactical, or logistics step.

  • Tactical and logistical steps were spelled out (not theoretical).

  • Important points were highlighted.

  • The text was edited for clarity and brevity. Jargon was kept to a minimum.

  • The color was shoved in when it made sense to do so.

  • Different colors were associated with different stages of the recovery.

  • The manual was created to be used and therefore, written in. The left side provided space for the staff to write notes during a recovery.


There were sections and tabs galore per our information architecture to aid in findability. Usability testing was a blast (not) and entailed putting binders in front of testers and asking them to find "information x" and see if they can find it and how quickly they were able to find it. 

Analog products are not condusive to hyperlinking. For items that needed to be quickly accessed but did not fall neatly in a tab, I created top level tabs.




  • Recovery "Wallet Cards"


The wallet cards were a condensed version of the manuals that folded into the size of a credit card. The staff could have on their person at all times. 


Below is one example of the over two dozen different wallet cards for the various staff user groups. 


The Tactical/Strategic Recovery Team Wallet Card

The card started off like this. It was minimally functional and fit the requirements of the senior staff: short, no elaboration, no extra paper.


On first glance, the senior staff liked the wallet card but quickly realized they needed more data and the color scheme was just difficult to read. In this version some information was taken out, some procedures were elaborated upon and the color scheme made more readable.


Later, other information was merged onto this card (to minimize the number of cards being carried), procedures elaborated upon, and the font more legible. 



  • Business Impact Analysis Survey


This survey is arguably the heart and soul of the program. It was originally an MS Word-based database that was later converted to an Excel workbook (with many, many tabs) survey about every aspect of every critical function across the organization. Each critical function is then mapped to every resource needed to keep the function running.


The old version was difficult to understand and difficult for the staff to fill out. The information gathered was additionally insufficient to create a comprehensive recovery plan.


The workforce allocation to the left was an interesting form and one that caused confusion due to the difficulty in understanding the purpose and how to think through the issues while filling out the sheet.

The formatting and coloring was difficult to read and users had to play "mix & match" with the form and instructions above. The language was unclear and left staff with more questions than answers, resulting in inconsistent answers.

The staff contact sheet to the left was one of the more challenging aspects  because it was a database originally created in Word and requried  departments to update each staff member's personal information. Departments would often not update due to the inconvenience it imposed. 

There were many more worksheets within the workbook not shown here, the above is to give you get an idea. 


  • Some other issues with the workbook included:

  • No data control as this was in Excel and not in a proper database. For example, some names were entered "first name, last name" or "last name, first name" or "nickname." This made analyzing data challenging.

  • It was confusing how to act upon the data collected during a crisis. 

  • Everything was compiled by hand, even the "rollup" of the data. 

  • There are restrictions within Excel itself (it's not a database) that made gathering data difficult.  



Through interviews (and staff complaints) I set out to redesign the workbook. 


To ensure we were capturing all the data needed, I worked with cross-functional recovery teams. To determine their needs.


In order to automate accurate data pulls into the workbook, I coordinated with HR, and IT.


The result was an easier workbook (there were Excel limitations to contend with) and the staff was relieved that they no longer needed to manually enter in staff personal information on every update.

Instructions were integrated into the table headings and examples were given if instructions were theoretical in nature.


At the very top are buttons that allowed users to complete common tasks.

Staff contact information were pulled directly from HR files (this required that I had to find a way to encourage the entire staff population of 2000 to update their HR records! - no easy feat!). 


This greatly reduced the amount of time individuals chased down coworkers to update their information for this program.


The type of information gathered also changed. Here, tactical recovery detail was broken down by time frame to gain a better idea of the resources needed for a recovery at any given point in time. 



I used VBA to make the workbook intelligent enough to determine when a staff member had left the organization (their name auto highlights in red, alerting all that this person's recovery responsibilities need to be reallocated to another staff member.



Part of a recovery that includes physical damage to the facilities. This necessitates understanding what recovery facilities are required for a recovery. This sheet automatically pulled data from other sheets to tally the minimum space and equipment requirements for one department.



To gain a clear understanding on the impact each of the functions had on the business, their financial and non-financial impact was calculated. This gave us an objective method in prioritizing recovery functions.




Site is under renovation.

Please pardon & watch for falling  debris. 

There are more screens but the above give a taste of the interface.


A recovery organization did not exist when I started. The first couple iterations of the recovery organization was challenging since it was a new way of rearranging resources than our usual day-to-day business.  It required literature review and I hired external consultants to help thinking through how the staff would best interact with one another to gain the best results.


The org evolved to:

1. Take on the language of Fire/police. The rationale was that if we use our own language, we couldn't communicate with the city and state emergency workers effectively. 

2. Structure the org so that it makes the most sense for a private company and fulfills the cultural needs of the company. It became a hybrid of how FEMA structures their recovery units, how Sephora operates and any necessary functions unique to the company. 


As the program grew to encompass more areas of the company, the recovery org became more complicated.



  • Recovery Organizational Charts 


The organization of staff during a crisis differed markedly from business-as-usual. Therefore the org chart needed to accommodate and target specific recovery functions. The organization of the staff was iterated upon until we found a solution that worked the most effectively.



  • Communication Flows 


The chain of communications from the staff to the executive team (and vice versa) was mapped out during a crisis needed to account for communications with internal and external stakeholders as well as the general public. 

The flow of communication upwards became a process to be formalized. The first few iterations were based on observation of the how the flow of information usually made its way up. In later iterations it was formalized and additional internal services were implemented to simplfy communication based on staff needs.



  • Recovery Frameworks 


The recovery framework are the flow diagrame of the overall recovery process, including questions the recovery staff must answer during and and after an incident.

The old framework had simultaneously too much and too little information and was not flexible enough to cover all possible scenarios. A new framework needed to be developed that was simple and flexible.

The newer framework was simplified and generalized and involved all areas of the organziation. No matter how complex the disruptive event, the framework could be scaled to accomodate the recovery.


Recovery Organization

  • There was a lot of confusion over how to recover and I realized that recovery framework needed to be an organization within the organization itself. Its mode of operation must be different enough to have staff think in a “crisis mode” as opposed to “business as usual” mode. This lead me to: 

    • Design the recovery framework and cross-functional recovery organization

    • Develop the procedures for the various roles within the recovery framework/organization


Plans & Other Assets

  • Designed to be comprehensive and cross-functional with all interdependencies mapped and prioritized

  • Catered to the needs of those performing the recovery in the forefront, before and during a recovery



  • Designed for understanding and efficiency 

  • Catered to the busy schedule of the staff



  • Centered around training, education and support

    • In the past: *mandatory* meetings yielded 40% staff attendance. My program: *Voluntary* meeting attendance increased to 90+%.

    • In the past: staff personal database accuracy (the database used to update staff during a crisis) 40%. My program: 98%


Program execution

  • The program successfully recovered from a number of incidents including:

    • Headquarters facilities shut-down due to inclement weather.

    • Cyber bot attack on the website.

    • Warehouse shutdown due to inclement weather.

    • PR incidents due to social media challenges


When I wrapped up my tenure at Sephora, the program had grown substantially due to requests by the C-suite and because the better we understood business continuity, the more complex we realized it had to become to be an effective and executable program. 


  • Crisis Management Plans. Recovery Strategy plans for the C-suite or strategic decision makers for the affected location. Assets delivered (updated annually): Plans for the headquarters and warehouses; summary plan; wallet card.

  • Incident Management Plans. Recovery Tactics plans, for non-C-suite executives. Assets delivered (updated annually): Plans for the headquarters and warehouses, wallet card.

  • Business Recovery Plans. Recovery Logistics plans, for the departments. Assets delivered (updated annually): Plans for the headquarters and warehouses, wallet card. Plan count: 20. 

  • Crisis Communications Plan. The PR/Branding crisis plan. How do we respond to a PR crisis (inclusive of social media)? Assets delivered (updated annually): Plan.

  • Internal Communications Plan. How to communicate to our staff. Assets delivered (updated annually): Plan, wallet card.

  • Emergency Response Plan. Respond to staff health and safety crises. Assets delivered (updated annually): Plan, wallet card.

  • Business Impact Analysis. Researching, data-gathering, prioritization and analysis of each departments’ critical functions. Deliverables (updated annually): Assessment report.

  • Risk Assessment. What incidents are we prepared for? What incidents are the riskiest to us and in what quick and easy ways can we mitigate that risk? Assets delivered (updated bi-annually): Assessment report.

  • Plan Activation. How do we know if an incident is worth triggering the recovery plan? What are the procedures? Deliverables: (updated bi-annually): flow diagrams, charts, reports.

  • Integration with the DR Plan. The whole program (above) needed to be routinely synched up with IT’s recovery plan to ensure they worked in tandem. This includes IT recovery due to network outages, cyber crimes, and retail website outages. (Frequency: annual).


Some of these assets are illustrated below.


Side Project

  • Personal Preparation Talk. I used my knowledge and connections within the Business Continuity world to develop a talk on personal preparation. Topics included:

    • What to expect during mass incidents

    • How to better prepare my family/home business

    • How to prepare personal finances

    • How to prepare for a family's emotional well-being

    • What resources are available to prepare for an event

    • What resources are available to recover from an event

Recovery Framework Flow Diagrams


These representative diagrams are used in training and give the recovery staff an idea about how the recovery process escalates and progresses, starting from the moment an event occurs to the time the recovery effort is deactivated. 


Information captured include

  • Duties/tasks of the strategic team, the tactics team, and the logistics team

  • Questions the lead staff needs to ask themselves at the various stages of the assessment and recovery


Design solutions to note

  • The basic recovery flow was structured to be as simple as possible for understandability

  • The candy color-coding of the assets was intentional to make it seem more friendly. Business continuity assets tend to look as if they were created by the IRS

  • The text in the diagram covers questions the recovery staff needs to ask themselves, potential answers and possible actions to take based on those answers. This helps the user visualize what could happen and how they might respond. These diagrams are paper scenario-simulations to aid in the learning process

Business Impact Analysis (BIA)


The BIA is the primary data collection tool for my Business Continuity (BC) Program. I designed and hand built this given version (using Excel VBA) after four major versions. It collects department-level major data points needed to understand and map out the most urgent needs of a given department. Data from each department is captured and analyzed.


Information captured include

  • What critical function needs to be recovered and how quickly during what time frame (e.g. the needs during March is wildly different from November in a retail environment and the needs for Finance in January is different from their needs in May).

  • What resources are needed to recover those critical functions (staff, software, hardware, facilities, equipment), how many of these resources are needed and over what period of time (e.g. how many laptops are needed within 12 hours after declaring a disaster vs. 1 week after?)

  • What dependencies do these departments have (e.g. how are the departments interconnected with one another and which vendors are they dependent upon?)


After information is captured at the department level

  • The data is rolled up into an overall corporate BIA and all functions are prioritized (not included here for confidentiality reasons)

  • Each individual SME is given a customized handbook that summarizes their role in the recovery and the resources available to them.


UX Items to note

  • Every worksheet gave a brief description about the purpose of the worksheet. Instructions were at the top and examples were also given as comments in the cells themselves. 

  • Every year I walked every department representative through the process. I didn’t just explain the workbook to them and expect them to understand how to use it. There’s an intricate thought process that goes on behind determining what information to input. I had discovered that no matter how simple the sheet/instructions (the first version was over-simplified) the users would inevitably become confused. Filling out the sheet with them allowed for two things:

    • Data consistency across the departments. I wanted to know we were comparing apples to apples.

    • When users became confused or lost in their process, I could guide them back and help them refine their thinking.

    • I built a detailed understanding about how each department’s function worked and connected the dots from a wholistic vantage point. 

  • There was also code running in the background that could auto-pull data from one sheet to another (and in some cases, one workbook to another) to cut down on the user’s redundant work. 


A few representative screenshots are shown here.



Not shown

  • Rollup of the overall corporate BIA (due to sensitivity of data)

  • Customized individual SME reports for the subject matter experts

Logistical Recovery Staff Assets


Audience: Sephora staff, headquarters + warehouses


Challenges & Solutions 

  • There was no budget to leverage 3rd party apps/systems. Assets were created using Microsoft Office and Adobe CC 

  • Layered needs. The information the dept leaders need is different from the dept subject matter experts which are different from the non-subject matter experts. Assets and trainings delivered are customized to each group's needs. 

    • Department heads - need info on how to recover their department. Trainings were leveraged to review asset usage. 

    • Subject Matter Experts are given a higher-level overview of the recovery program as well as detailed recovery information.

    •  All staffgiven basic communications and health & safety information.

  • Plans need to be flexible enough to recover a simple flooding of a floor to a 6-month relocation. To solve this, guidelines and a recovery framework were given to the departments as well as the specific details for each critical function. The logistics teams themselves determine which critical functions to recover based on the given incident.

  • Plans need to reduce the load of the department heads during a recovery. The core of the plan is written in checklist format and the hardcopy has multiple copies of each checklist. This assists the leader to delegate recovery tasks to others rather than performing all recovery tasks themselves.

  • Each department has very different needs. Each department’s binder is customized to their specific needs. 

Tactical Recovery Staff Assets


Audience: Department heads, headquarters + warehouses


Challenges & Solutions

  • Designing the recovery framework. The design was a highly modified version of the emergency management offices’ current framework. The modifications took Sephora’s needs and culture into account.

  • Ensuring the recovery framework is scalable. Depending on the scale of the incident, the tactical team can scale down (team of one) or up (all hands on deck). This not only allows flexibility for the size of the event, but also allows the team to scale as the recovery progresses. 

  • Designing the communication pathways to and from the tactical recovery staff. Communication was designed to be rigid and redundant. Ridged in terms of hierarchical structure: information must be reported to one specific person. Redundant reporting to one other person allowed for cross-checking and cross-documentation. 

  • Ensuring the tactical staff has the information they need for recovery but not so much to overwhelm. The roll-up of the departmental Business Impact Analysis resided with the tactical plan. However, all the intricate details provided at the department level was not provided at the tactical level.

Strategic Recovery Staff Assets


Audience: C-suite and location leaders (e.g. top warehouse leaders)


Challenges & Solutions

  • Documentation for the C-suite must be brief. Everything not critically necessary was stripped away. A one-page document was provided with a summary of do’s and don’ts. 

  • At the same time, the C-suite wants all needs anticipated. The rest of the documents go another level or two deep into the recovery process. Some were given the tactical document if they wanted more information. 

  • Strategic/tactical framework changes depending on the size and maturity of the company. As Sephora grew, the framework for the recovery changed from two primary recovery groups (strat/tactical & logistical) to three (strategic, tactical & logistical). All assets were revised and updated for the ongoing changes. 

Brand Recovery Asset


Audience: C-suite and Marketing/PR

Challenges & Solutions 

  • Communication flow unclear. The communication framework and flow for incidents was designed and outlined here. 

  • Unclear if responses will be successful. A running log of previous responses by Sephora an its sister companies was kept as a guideline in this document. 



Staff Communication Assets


Audience: Corporate communications + some department heads

Challenges & Solutions 


  • Flow of communication unclear. Designed the communication flow between the staff and the recovery teams, between the vendors and the recovery teams, and between our parent companies and the strategic recovery team. 

  • Unsure which communication tools would be available during an incident. Set up four avenues of communications and created a manual for each as well as when (or not) to use each tool.

  • Communication content unclear. Incorrect communication can lead to social media outrage. Created guidelines on what (or not) to say.

Staff Health & Safety Assets


Audience: All safety staff, headquarters, stores, warehouses


Major iterations/versions: 4


Challenges & Solutions 

  • Different response for different incidents. Brainstormed distinct emergency scenarios and created a checklist action plan for each scenario (tornado, earthquake, active shooter, etc.)

  • Communications. Since we had to assume a worst-case scenario with a power outage, I purchased two-way radios and designed the communication protocol. 

  • All staff needed to know general safety information, not just the safety staff. Protocols such as evacuation and basic earthquake/fire safety were combined onto the general staff wallet card.

  • Different countries have different safety requirements. We worked with specialists in other countries to ensure their safety procedures were in line with federal requirements.


Not shown

  • posters, signage

  • store manuals 

  • warehouse manuals


The great stuff

  • This was the first time I could use all of my previous training:

    • Analytical training (from the natural sciences): Analyzing the quantitative and qualitative data required precise thought and deep understanding of how all the components worked together.

    • Instructional design (my master's degree): Developing a training program with good pedagogical practices to maximize learning.

    • Coding: Building an Excel VBA-based program to organize and collect data

    • Basic UX: A program that expects its users to conform to it rather than the other way around is *always* doomed to fail. I designed the program with the end user (the tactical and logistical recovery teams) in mind.

  • I proved that an educated staff results in an engaged staff. 

  • Create a user-centered program, and you’ll be rewarded. I showed that if the staff felt like they had a voice in the process, they were being heard, and they were being supported the program was more likely to be accepted. 

  • Business Continuity is one of a few programs that allows a look at the intricacies of the corporate engine. I routinely interacted with IT, Facilities, HR, Operations, Dotcom, Logistics, Finance, Legal, etc. The program allowed me to see exactly how every aspect of the company is interconnected and to see their most important concerns.

  • I was unexpectedly able to find cost-cutting measures when I dove into our corporate data. 

  • I was able to drive a few policies of our parent company (LVMH) because I had built the most complete business continuity program of their subsidiaries.

  • I was able to interact with a variety of sister companies and mentor them on how to build a business continuity program within their companies.



  • So many stakeholders and users! It was challenging juggling so many needs and opinions.

  • Planning. One size does not fit all. All plans needed to be flexible enough to cover incidents that would result in operational disruptions from a week out to a year. This was extraordinary challenging to build because people believe they need a different plan for every possible scenario. 

  • Setting expectations. There’s a huge difference between building a plan so that it is executable (user-centered) vs. building a plan so that an audit item can be checked off a list (plan-centered). This goal wavered between the two extremes a few times. 

  • Talking people off the ledge. People naturally gravitate away from talk about preparation for disasters. I believe it’s because people just become overwhelmed, don’t know where to start, or don’t think it will happen to them and they disengage. In an act of either fear or rebellion, some challenged the program saying that it doesn’t cover every possible disaster. There were many repeated discussions regarding the likelihood of an Armageddon vs. taking reasonable precautions in preparation for more likely events. 

  • Data are difficult to measure. There were ways to test the plans but all are during non-crisis drills. The true test of whether the plan works during an actual crisis can only be measured after an actual crisis which fortunately didn’t occur frequently. 

  • Time needed to drill for muscle memory. Full-fledged trainings are incredibly expensive in terms of time and resources. Therefore they were discouraged. This required that the training time allotted to me to be as productive as possible.

  • Herding cats. My program had a lot of dependencies across the company and I had to quickly learn how to extract what I needed even though I did not have any official authority over the staff 

  • Length of time taken. It takes longer and more relationship-building to build a grassroots program vs. building a program mandated from above. 


Final conclusion

I believe this program was successful during my tenure due to its user-centered aspect. Business Continuity is infamous for being as complex, interesting, and clear as the IRS tax code. The only way to motivate and engage the staff was to take a grass-roots, bottom-up approach and cater to their needs. 


“Lucretia is a great business partner."

Carole Clausen, Director of HR Payroll, Sephora 

“Very impressive job on a very challenging business program."

Sherman Hoo, VP Finance Controller, Sephora 

“This is the first time I understood the program and how I fit into the recovery process."

Ann Leahy, Director of Kendo, Sephora

“You made the process incredibly easy to understand and provided us the resources to execute."

Alisa Mosler, VP, Analytics & BI, Sephora

“You're very good at what you do."

Mary Herald, EVP HR, Sephora

“Of our subsidiaries, you've created the most advanced and comprehensive program."

Claire Ascete, VP Treasurer & Risk Management, Louis Vuitton & Moet Hennessey (LVMH)

bottom of page