Overview
Enterprise IT is in transition again. Use of employee-owned devices in a work context
is an organically emerging trend in a wide range of enterprises. The challenge for
enterprise IT is to manage this transition to BYOD without exposing the enterprise
to unnecessary device management, data security and cost control risks, and without
stifling the innovation these devices may herald.
This research provides a high-level checklist (see Table 1) to use when implementing
a BYOD program. Each step is discussed in greater detail later.
Table 1. A High-Level Checklist for Implementing BYOD
|
|
Step
|
Key Deliverable
|
|
1
|
Deciding on a BYOD Strategy
|
Determination of Which Approach to Adopt to BYOD
|
|
1.1
|
Conduct a high-level BYOD issue review to scan for showstoppers.
|
Initial list of roadblocks and issues that may shape your response to BYOD
|
|
1.2
|
Justify the program and define the goals.
|
Evidence and goals for sponsor and stakeholders
|
|
1.3
|
Define the scope and identify the sponsor.
|
Charter for BYOD program, definition of goals, and identity of sponsors
|
|
1.4
|
Identify stakeholders and solicit input.
|
List of stakeholders and the issues/concerns that impact them
|
|
2
|
Grouping Employees, and Defining Support and Access for Each
|
Segmentation of Employees Into Three to Six Groups, and a Package of Policies and
Technologies for Each
|
|
2.1
|
Define employee groups.
|
Employee roles/needs matrix and a list of applications/services to be supported on
BYOD devices
|
|
2.2
|
Assess employee information sensitivity for each group.
|
Roles/needs matrix annotated with the sensitivity of information handled by employee
roles
|
|
2.3
|
Identify the delivery and security options for apps and services for each group.
|
List of options to deliver each key app or service onto an employee-owned device,
as well as management and security tools
|
|
2.4
|
Create scenarios for device/staff/application management regimes for each group.
|
Possible packages of policies and technologies to address the needs of selected employee
roles
|
|
2.5
|
Select a scenario for implementation for each group.
|
Detailed proposal for the selected master scenario
|
|
3
|
Implementation Planning
|
Scope of Tools, Network Services and Financing Models
|
|
3.1
|
Select the tools and technologies.
|
List of tools for application delivery, device management, security and virtual desktop.
|
|
3.2
|
Define the networking and connectivity strategy.
|
List of network services/providers, and a technical and financial policy for each
supported network type
|
|
3.3
|
Define the app management and licensing strategy.
|
Guidelines and policies for application licensing, management, sourcing and funding
|
|
3.4
|
Define/refine financial aspects and create a cost model.
|
Proposed reimbursement plans, expected networking costs and a total cost of ownership
model
|
|
3.5
|
Define employee education requirements.
|
Define education material for proper use and how to access corporate IT assets
|
|
3.6
|
Identify eligible employees.
|
List of employees taking part and line management approval for their participation
|
|
3.7
|
Analyze the risks.
|
Validation against social, business process, financial and data security risks
|
|
4
|
Project Setup
|
Staged Approval for BYOD Program
|
|
4.1
|
Create a detailed program proposal for stakeholder sign-off.
|
Detailed program description for stakeholder approval
|
|
4.2
|
Educate stakeholders and ensure their sign-off.
|
Approval from stakeholders and sponsors
|
|
4.3
|
Create policies and procedures.
|
Internal policy documents, procedures, staff BYOD contracts and agreements
|
|
4.4
|
Define support processes.
|
Supported principles, processes and budgets
|
|
4.5
|
Obtain external stakeholder deliverables.
|
External policy documents (such as finance policies and legal wording for contracts)
|
|
4.6
|
Create instructional material.
|
Training materials (such as presentations and webcasts)
|
|
4.7
|
Select employees and obtain agreement.
|
Lists of participants and signed employee agreements
|
|
4.8
|
Roll out employee education.
|
Rollout of education material on proper use and how to connect to corporate IT assets
|
|
5
|
Proof of Concept
|
Successful Pilot and Key Lessons
|
|
5.1
|
Pilot the program.
|
Updated program deliverables addressing issues identified in the pilot.
|
|
6
|
Implementation
|
BYOD Rollout Plan
|
|
6.1
|
Roll out the program.
|
Trained employees and related staff (such as support and managers) and replaced devices
|
|
7
|
Program Renewal
|
Periodic BYOD Health Check
|
|
7.1
|
Monitor and evolve the program.
|
12- to 18-month review of BYOD employee satisfaction, value and risk, as well as needed
corrective actions
|
Source: Gartner (June 2012)
1. Deciding on a BYOD Strategy
It may seem odd to need a strategy for BYOD. After all, why should enterprise management
do anything? Isn't it just a case of sitting back and waiting for employees to bring
in their devices, create new business models and improve productivity? Unfortunately
not.
The consumerization of IT with mobile devices and their ecosystem of applications
— what we are calling BYOD — may have gone into overdrive of late, but IT leaders
and their enterprises still need to make a considered trade-off between freedom of
employee action, and the costs and risks of supporting these devices. In short, IT
leaders need to balance a new set of potential business benefits with a new set of
business risks.
One of the first considerations is what the enterprise's broad approach to BYOD should
be. Options range from laissez-faire to lockdown:
- HR takes the lead: Ban employee-owned devices being brought onto enterprise premises and prevent them
from connecting to any enterprise network assets.
- HR takes the lead: Allow devices on-premises but offer no access to enterprise network assets.
- Enterprise IT takes the lead: Allow devices on-premises but limit the connection for everyone to email, name and
address book, and contacts.
- Enterprise IT takes the lead:
Segment employees, allow the use of BYOD for enterprise business, and
provide support
in a way that is appropriate for each
group (see "Use Managed Diversity to Support Endpoint Devices").
- Enterprise IT takes the lead: Segment employees. In addition, offer enterprise-purchased and enterprise-funded
mobile devices to some categories of employees.
- No one take the lead: Allow employees to do what they like with their own devices.
Most risk-aware enterprises go into their early BYOD initiatives with enterprise IT
playing a leadership role. In the rest of this research, we assume that, like most
enterprises, the best strategy for you to follow is similar to Option 4.
1.1 Conduct a High-Level BYOD Issue Review to Scan for Showstoppers
Before embarking on a BYOD program led by enterprise IT, it's useful to consider fundamental
questions:
- Is this a high-security environment that precludes BYOD for anything but personal
information management (including email, contacts and calendars)?
- Are there legal or compliance issues that preclude BYOD for anything but personal
information management (for example, especially in multinational organizations governed
by different legislations, this might include e-discovery, data privacy legislation,
employers' requirement to provide necessary equipment for an employee to do his/her
job and so on)?
- Do issues regarding remuneration, audit, taxation, industrial relations, and employee
terms and conditions make enterprise-IT-managed BYOD unattractive?
- Do any management, technology or policy barriers prevent robust, scalable and secure
access that isolates enterprise digital assets on BYOD? Do any hardware, software
or bandwidth requirements threaten to scuttle BYOD?
- Do service-level agreement and support constraints — regarding uptime, remote support,
availability of applications, and business processes — limit BYOD attractiveness?
Does the enterprise need to make loaner devices available to high-value workers? Can
the IT organization effectively deal with a mixed support model that would blend direct
support, limited support (supported applications on nonsupported platforms), community
support and self-support?
- As a principle, should the enterprise mandate insurance, warranty and maintenance
contracts for all employees using noncompany devices? If so, who pays — employees
or their business units?
- As a principle, what will IT pay for — the device, telecom charges and downloaded
apps? What will employees and/or their business units pay for?
- Can employees opt out of the program? What happens if an employee doesn't want BYOD
(for example, older employees who prefer simple feature phones to mobile email)? A
better option might be for this to be an opt-in program, and to offer an alternative
if the employee doesn't want to opt in. This entails the provision of tools to ensure
that employees can do their work if they don't want BYOD. In managed diversity, this
is a platform-level device (see "Use Managed Diversity to Support Endpoint Devices").
- How will the current application portfolio be impacted by employee-owned devices (for
example, whether existing applications support multiplatforms, such as Microsoft Office
for Mac)? Are existing Web-based applications written to run on multiple platforms,
or are they written to run on a specific browser?
- How will future application delivery be impacted by employee-owned devices (for example,
whether IT can ensure that devices and contracts are compatible with planned or likely
new application versions)? What happens if new applications have substantially greater
data needs that exceed an employee's personal contract limits or process needs exceed
the processing capacities of the most common BYOD devices?
- Do software licensing, hardware sourcing or support issues make BYOD unattractive
(current software licenses, for example, may not extend to employee-owned devices)?
Are required third-party support schemes available for the proposed BYOD scheme?
- Should limits be placed on any existing vendor relationships to control device choice?
- Who oversees user behavior? Who will educate users on the data risks of BYOD? These
may be subsumed into a broader question: Who, if anyone, monitors social discourse
in public media?
1.2 Justify the Program and Define the Goals
Even though, in theory, enterprise management may see the wisdom of funding enterprise
IT to play a leadership role in BYOD, when it comes to paying the check, they may
change their mind. The challenge initially is that no one has experience running an
enterprise-IT-managed BYOD program. In addition, the benefits case may be unclear,
because adoption, business use and business value are all evolving along with the
devices.
A proven way to avoid this trap is to define the BYOD program's goals and costs at
a high level. To fill in the blanks, conduct a high-level strength, weakness, opportunity
and threat (SWOT) analysis to identify what confronts the enterprise when employees
adopt BYOD. This need not be onerous:
- Collect evidence about the level of informal BYOD by surveys asking how many employees
use personal laptops, tablets or smartphones.
- Discuss the potential benefits (such as increased innovation, need to allow choice
to recruit the best staff and displacement of support costs to employees) with key
enthusiastic adopters.
- Highlight the risks of uncontrolled BYOD (such as data loss and costs).
- Review the network's capacity and security arrangements, and IT's ability to support
employee-owned devices. Armed with the results of the SWOT, it should then be possible
to fund a pilot to test out the opportunities and challenges. When conducting this
analysis, be mindful that one of the biggest challenges with enterprise-IT-led BYOD
is for support. Employees want anything they want and blame IT for anything that goes
wrong.
If, on the other hand, the implications for BYOD are better understood, a more traditional
business case approach can be used to justify investment. This business case typically
features a range of benefits, such as enhanced brand image, improved field and sales
effectiveness, potentially reduced cost, employee efficiency gains, employee satisfaction
improvements and so on.
1.3 Define the Scope and Identify the Sponsor
BYOD pilots and programs seldom involve the whole organization. Instead, it's generally
sensible to choose a small subset of employees — perhaps belonging to a single department
— or a few job roles to start with and to roll things out from there.
All process change demands a sponsor, and BYOD is no exception. Ideally, sponsors
should come from a business background and be in a position to influence or direct
employees participating in the pilot. Many organizations will find they have passionate
BYOD supporters among the senior executives who may be candidate sponsors.
1.4 Identify Stakeholders and Solicit Input
Any major BYOD initiative relies on many stakeholders and raises wide-ranging technical,
policy, financial and legal questions. These stakeholders should be identified and
contacted as appropriate to obtain inputs and opinions that will shape the program.
Example stakeholders include insurers (as risks change), HR (for changes to terms
of employment or contracts), IT (application delivery and deployment, support), employees
and their representatives (such as unions and workers councils), lawyers (to validate
contractual changes) regulators and tax authorities, enterprise architects (architecture
changes), auditors, and so on.
2. Grouping Employees, and Defining Support and Access for Each
A one-size-fits-all approach to BYOD is suboptimal. Instead, segment employees into
three to six groups, and determine which package of policies, mobile device management
and network access technologies to adopt to support employees choice of devices for
each.
2.1 Define Employee Groups
Diversity of employee needs and the assortment of mobile technologies mean that one-size-fits-all
management is not ideal. It means costs are too high, risks are too high or both.
Instead, enterprises should segment their employees into three to six groups based
on how much mobility and secure access to enterprise data they need. The Gartner managed
diversity model takes this approach (see "Use Managed Diversity to Support Endpoint Devices").
To do this, a good starting point is to model employee location and BYOD work style
and usage pattern (which may be simplified) and their business requirements. Showing
role versus business requirement as a matrix whose rows are the job roles and whose
columns are the applications or services that a job role needs when mobile aids analysis
(see Table 2). These employee groups should be cognizant of porous boundaries where
the definition of an employee may include noncontract, part-time and ecosystem co-workers.
(Think R&D communities, nomadic project and construction endeavors, marketing campaigns
that attract and coalesce feedback from customers, outsourcing representatives working
on internal systems, prospects outside organizational boundaries, and so on.) An intersection
is highlighted when a job role needs a particular mobile service. It is also useful
to capture the likely employee context for each intersection. For example, determining
whether the employee is in the office, in the corporate Wi-Fi cloud or in cellular
coverage will help when considering application delivery and networking options.
Table 2. Illustrated Roles Versus Needs Matrix
|
|
Mobile Email
|
CRM
|
Board Papers
|
Lead Tracking
|
Document Sharing
|
Meeting Notes
|
Risk
|
|
Sales staff
|
x
|
x
|
|
x
|
x
|
x
|
$
|
|
Sales manager
|
x
|
x
|
|
|
x
|
x
|
$$
|
|
CEO
|
x
|
|
x
|
|
x
|
x
|
$$$
|
|
(Add others)
|
|
|
|
|
|
|
|
Source: Gartner (June 2012)
This planning matrix can be used in many ways and provides several key pieces of information
required in later steps of this process.
2.2 Assess Employee Information Sensitivity for Each Group
For each job role identified, define the sensitivity of data that the role accesses.
This assessment by role is necessary, because some tools (such as mobile email) may
be used by staff accessing information of very different sensitivity. A coarse scale
will suffice, focusing on an agreed measurement of risk, such as potential financial
loss. For example, 0 equals no material loss, and 5 equals high material loss.
2.3 Identify the Delivery and Security Options for Apps and Services for Each Group
To optimize application delivery and architecture across the BYOD program, consider
each application or service in the planning matrix, and identify alternative options
for how it might be delivered with adequate security in a BYOD context. BYOD commonly
triggers changes to application architectures and, in many cases, to application delivery
architecture and security.
Common methods of securing applications include:
- Mobile device management (MDM) tools that can provide application containerization,
control access, inventory security levels and generally serve to lock down a device
- Application delivery tools to isolate business applications from the consumer side
of the device
- The use of thin-client architectures that obviate the need for a device to contain
data
Other popular approaches include sandboxing (for example, email systems that separate
personal and corporate email).
2.4 Create Scenarios for Device/Staff/Application Management Regimes for Each Group
Now that the groups are in place, it's time to strike the right balance between employee
freedom of action with respect to their devices and enterprise control for each. When
doing this, bear in mind that BYOD is different. Why would anyone bother with BYOD
if his or her machine (particularly if it's personally paid for) ends up weighed down
with corporate security and device management software, along with stifling rules
and regulations regarding its use and associated costs. BYOD is not the same as employee-purchased
corporate device (EPCD).
Usually, there are several equally plausible ways to deliver and secure applications
and support that have different costs, benefits and trade-offs (for example, MDM tools,
thin clients, sandboxed email, virtual desktops and even not using any tool at all
if the decision has been made for a very risky approach).
To determine which combination is best, develop a series of high-level scenarios that
feature different approaches to device management, application delivery and application
design, and funding and support. Although the scenarios may lack a highly detailed
definition of a program, they do contain enough details to enable a rational selection.
For example, two simple scenarios might include:
- Scenario 1 for sales staff and sales managers: Deliver email using a sandboxed solution from Good Technology, develop thin-client
HTML interfaces for all applications, and implement a system to allow access to SharePoint
for secure document cloud storage. In this scenario, there is no need for MDM, provided
SharePoint is configured not to allow offline downloads. Funding will be via a stipend.
Although this is OK for services, stipends for devices leave the enterprise on the
hook for support. Employees will be liable for networking costs, and the corporate
element will be covered by the stipend.
- Scenario 2 for all staff: Port key applications to native iPad implementations (so they can wrap and secure
their own data), implement email using the new iOS 5 mailbox partitioning approach,
allow employees to take meeting notes using any tool they want, but secure the device
and application data using an MDM tool. Implement a board portal tool for directors
only to secure sensitive meeting papers. Funding will be via a stipend. Senior staff
will use company-provided cellular contracts to allow for the negotiation of roaming
costs. Junior staff will use employee-liable cellular networking funded by the stipend.
These examples illustrate that some job roles may require additional tools or special
treatment because of the applications they need or the sensitivity of the data they
access. Scenario selection will be driven by many factors, including usability, cost,
acceptability to employees and so on.
2.5 Select a Scenario for Implementation for Each Group
In consultation with stakeholders, select plausible scenarios for implementation to
support each employee group. Bundle these scenarios to create a master scenario for
implementation.
3. Implementation Planning
Determine the scope of tools, network services and financing models.
3.1 Select the Tools and Technologies
Select technologies and vendors to implement the chosen master scenario. Examples
include mobile development tools, MDM tools, VPNs, hosted desktop tools, cloud storage
and so on.
3.2 Define Networking and Connectivity Strategy
- Which networking and voice technologies will be used (for example, cellular and Wi-Fi)?
- Will personal devices be permitted to connect to corporate networks? If so, what controls
and restrictions will be applied?
- How will connectivity be funded — for example, through stipends, through the provision
of corporate data accounts, through employees claiming connectivity on expenses or
through some other method?
- How will personal and corporate use of network services on the same device be managed?
Some organizations may allow personal calls and data usage on corporate contracts,
for example, if they can negotiate flat rate plans. Or, if the employee is liable
for the data, contract reimbursement beyond the stipend may be necessary.
- What mechanism (for example, identity management) will be used to identify the user
and control application access (see "Roundup of Identity and Access Management Research, 1Q12")?
- Are additional supporting technologies or services required (for example, VPNs, network
access control systems, network auditing and monitoring systems, or telecom expense
management solutions)?
3.3 Define the App Management and Licensing Strategy
BYOD models also pose challenges in application licensing and funding. These include:
- Licensing existing software products for potential access by many more endpoint devices: This is more complex under BYOD because it includes a mix of personal and corporate
devices. Review license agreements and ensure that cost models reflect the true cost
to provision (see Section 3.4).
- Funding essential mobile apps: Do the app store owners offer a bulk licensing arrangement? How will bulk licensing
be managed (the options differ between app stores and even countries)? What should
you do about apps that are not available for corporate licensing? Establish guidelines
for each jurisdiction and ensure that cost models reflect the true cost to provision.
- Employees expensing the cost of certain apps for personal devices: Expensing apps can be complex. Because most apps are of low value, treat them like
any other expense. Establish guidelines by jurisdiction, instruct employees to submit
expense claims as usual, and instruct local management to approve the expenses if
they are within the guidelines.
- Apps purchased by employees who then leave the enterprise: If an employee leaves the organization, what happens to the apps and content on his
or her personal device that were purchased with corporate funds (many mobile app vendors
have no mechanism for transferring licenses on low-cost apps, so the investment may
be lost)? Because most apps are of low value, most enterprises are willing to write
off these small sums, as they would for employee-purchased books and other small items.
- Required apps as part of a mobile application management (MAM) solution: Some organizations choose to adopt a MAM solution as part of their BYOD strategy
—essentially a minimum set of apps that should be present on all BYOD devices. This
may be provided in several ways (for example, by a dedicated corporate app store product
or as a feature of an MDM tool).
- Common app management among multiple platforms: One of the challenges of BYOD is that it is highly likely multiple different devices
will be in use from different vendors. Identify the most common devices in use, and
create different app stores, different settings for MDM tools, different platforms
and different policies for each.
- Apps purchased from consumer stores that have different and inconsistent licensing
terms and conditions: Although this is true, and may well be an issue surfaced by the audit or finance
departments when considering the enterprise's BYOD, in practice, few consumer apps
represent a real licensing issue. A realistic risk assessment and measured advice
(as a policy) on what to do if you are an employee with one of the shortlist of problem
apps is appropriate.
3.4 Define/Refine Financial Aspects and Create a Cost Model
The goal of this step is to produce a detailed cost assessment for future approval
by stakeholders. At this stage, we know and can cost the technology and processes
required for proposed BYOD scenarios. We also know and can address issues such as
employee data requirements and stipends. Nevertheless, issues remain that may make
BYOD unattractive from a tax perspective. These include:
- Software licensing: Some license agreements are based on endpoints (device licenses), which may imply
substantial additional costs as new endpoints are added (such as employee-owned tablets).
- Tax implications: There are two broad tax implications of BYOD. There is no ability to write off against
tax devices the organization does not own. An employee may also face an increased
tax bill if the enterprise provides taxable benefits to employees to fund corporate
use of personal devices.
3.5 Define Employee Education Requirements
Although users shouldn't need enterprise IT to tell them how to use the devices, they
still require education on acceptable use policies, as well as how to connect to and
use corporate information assets and networks.
3.6 Identify Eligible Employees
In many organizations, not all employees, qualify for participation in an enterprise-IT-led
BYOD program. Identify groups, and seek line management approval.
3.7 Analyze the Risks
BYOD programs introduce new risks, including financial, security, data loss and employee
satisfaction risks. Validate the proposed program from at least four directions:
- Test against likely scenarios. Examples include lost or stolen devices, failure of
key vendors and invalid assumptions (for example, about how much data employees might
need).
- Validate from each of the four (somewhat conflicting) goals of a BYOD program:
- Social: Will the employees be happy?
- Operational: Can the process continuity be assured?
- Financial: How are costs controlled and managed?
- Risk management: What bad things could happen, and how will they be prevented?
- Ensure that all key stakeholder issues identified in Section 1.4 have been addressed
(particularly any legal issues — for example, whether it is acceptable to wipe an
employee's personal device).
- Consider implications of corporate applications and device usage coexisting with personal
applications and device usage.
4. Project Setup
Gain final approval for the proposed BYOD approach. Set up conditions to run the pilot.
4.1 Create a Detailed Program Proposal for Stakeholder Sign-Off
Create a BYOD proposal with sufficient details for stakeholders to approve it. This
should follow your usual project proposal format and process.
4.2 Educate Stakeholders and Ensure Their Sign-Off
Submit your BYOD proposal to all the stakeholders identified in Section 1.4 for comment,
discussion and ultimate approval. Ensure that all are aware of their responsibilities
in a BYOD program (for example, IT staff can't roll out new applications without first
understanding whether they might cause employees to exceed personal contract data
caps; if employees travel abroad, additional reimbursement procedures may be required
if stipend models are inadequate for roaming data charges). Iterate as required.
4.3 Create Policies and Procedures
All device management is a blend of policy
and technology. In consultation with legal,
audit, HR, insurance groups and so on, extend
these to include BYOD-created ones (for
example, to define the permissible use of
corporate data, to allow e-discovery, to
audit devices and to permit wiping personal
devices). See "Toolkit: BYOD Mobile Device Policy Template" for a
powerful tool to define BYOD policies.
On a related topic, given the rate of evolution of employee-owned devices, specification
(which forms part of a BYOD policy) that describes the minimum device features should
be issued at least every two years (the practical useful life of a smartphone or tablet).
The danger of not doing so is that, if no update is issued, employees may perceive
that they can keep their device and enjoy the same level of access and support indefinitely.
If this situation occurs, it is highly likely that the device would slip below the
specification needed to match the requirement for enterprise applications.
4.4 Define Support Processes
New support principles and processes must be defined. BYOD demands a new tiered approach
to support. No organization can afford an open-ended commitment to fix any problem
on any device. When a device is unsupported, alternatives include increased use of
peer support and social networks, and techniques such as time-boxed support to limit
costs (see "Gartner's View on 'Bring Your Own' in Client Computing").
4.5 Obtain External Stakeholder Deliverables
Some deliverables must be created by external stakeholders (for example, changes to
reimbursement processes and updates to contracts of employment). Ensure that all the
necessary external deliverables are available.
4.6 Create Instructional Material
It's likely that employees participating in a BYOD program will need training in new
policies and procedures. Create the necessary material.
4.7 Select Employees and Obtain Agreement
Identify employees who will participate in the program or pilot. Ensure that they
understand it and sign any necessary agreements.
4.8 Roll Out Employee Education
Roll out education material on proper use and how to connect to corporate IT assets
developed in Section 3.5.
5. Proof of Concept
Conduct a pilot, learn from the results and adjust the implementation as required.
5.1 Pilot the Program
Typically, organizations run a pilot involving a limited number of users and/or device
types before fully deploying their BYOD program.
6. Implementation
Roll out the BYOD program.
6.1 Roll Out the Program
On completion of a successful pilot, rollout activities will include training, perhaps
reclaiming corporate devices, rolling out new tools and applications, configuring
tools such as MDM, and providing additional support for employees.
7. Program Renewal
Periodically monitor the progress of the program.
7.1 Monitor and Evolve the Program
It's unlikely that the first version of a BYOD program will be perfect. Even if it
is, circumstances change. Regularly track costs, support issues and security issues,
and conduct surveys regarding employee satisfaction. Every 12 to 18 months, review
the results, and be prepared to tune the program as issues are discovered.
