S w W13035 INTEL CORP. – BRING YOUR OWN DEV.docx

S w
W13035
INTEL CORP. – BRING YOUR OWN DEVICE
R. Chandrasekhar wrote this case under the supervision of
Professors Joe Compeau and Nicole Haggerty solely to provide
material
for class discussion. The authors do not intend to illustrate
either effective or ineffective handling of a managerial
situation. The
authors may have disguised certain names and other identifying
information to protect confidentiality.
Richard Ivey School of Business Foundation prohibits any form
of reproduction, storage or transmission without its written
permission. Reproduction of this material is not covered under
authorization by any reproduction rights organization. To order
copies
or request permission to reproduce materials, contact Ivey
Publishing, Richard Ivey School of Business Foundation, The
University
of Western Ontario, London, Ontario, Canada, N6A 3K7; phone
(519) 661-3208; fax (519) 661-3882; e-mail [email protected]
Copyright © 2013, Richard Ivey School of Business Foundation

Version: 2013-02-15
In January 2010, Malcolm Harkins, chief information security
officer, Intel Corp., was facing dilemmas
in taking forward the Bring Your Own Device (BYOD)1
initiative. The company’s information
technology (IT) division had been driving this initiative for
nearly a year. Now that senior management
had taken a strategic decision in favour of implementing BYOD,
Harkins needed to take the lead in the
opening up of the initiative broadly across the enterprise.
More than 10,000 of Intel’s nearly 80,000 employees worldwide
were already bringing their own devices
to work. Harkins foresaw that the number of employee-owned
mobile devices on the job at Intel would
triple in a year and that, by 2014, about 70 per cent of
employees would be using their own devices for at
least part of their job.
Said Harkins:
My dilemmas are three-fold. How do we extract value from the
initiative and turn BYOD
into a new source of competitive advantage at Intel? How do we
ensure security of the
corporate data on a device that an employee brings to the
workplace? How do we respond
to e-Discovery requests for information stored on a device that
Intel does not own?

CONTEXT
Early in 2009, Harkins had noticed a trend among the
employees of Intel. Employees were bringing their
own tablets and storage devices to their workstations and using
them during office hours. Concurrently,
the use of smart phones was rising. The distinction between
corporate data and personal data on
employee-owned devices was blurring because access to
corporate data was no longer limited to office
hours, just as personal data was no longer off-limits during
office hours.
1 “Bring your own device (BYOD) is an alternative strategy
allowing employees, business partners and other users to utilize
a personally selected and purchased client device to execute
enterprise applications and access data. Typically, it spans
smartphones and tablets, but the strategy may also be used for
PCs. It may include a subsidy.” Source: Gartner Inc., IT
Glossary, available at http://www.gartner.com/it-glossary/bring-
your-own-device-byod/, accessed December 21, 2012.
This document is authorized for use only by Nathan White
([email protected]). Copying or posting is an infringement of
copyright. Please contact [email protected]
or 800-988-0886 for additional copies.
Page 2 9B13E002
The trend was catching up. BYOD was causing apprehensions
among IT professionals mandated with
information security (IS). Their immediate concerns were two-
fold: The IT staff would be burdened with

supporting and troubleshooting unmanaged devices; and, instead
of using the devices for work-related
activities, employees would be distracted by applications
embedded into their devices, which could
potentially lead to a negative impact on productivity.
Harkins’s principal concerns related to issues of not only IT and
IS (which were his areas of domain) but
also finance, law, human resources development and the
company’s brand equity (which were not his
areas of domain). Employees had personally invested in laptops,
netbooks and mobile devices, and they
were using them for company work — whether at home, at
office or on the road. This practice reduced
Intel’s own costs of device procurement but increased its costs
of evaluating, configuring and supporting
a growing pool of smartphones, tablets and laptops. It also
meant greater risks in terms of data security;
company data was vulnerable to being compromised while being
carried on personal devices. Intel, as an
organization, needed to be able to access and control company
information; but doing so on employee-
owned devices without violating individual privacy was a grey
area. Harkins also realized that who
should be included in a BYOD program was a sensitive area.
Every year, Intel recruited professionals at
various levels, and its reputation as a preferred employer,
among young jobseekers in particular, would
also be affected by its stance on BYOD.
Intel had three options for dealing with BYOD as a trend. It
could have done nothing, in the hope that
employees bringing own devices to work was only a fad and
would soon pass. This approach would have
ensured status quo but would have also pushed “shadow” IT (as
the IT activities occurring outside of IT

management were collectively known) further into the dark. The
company could have issued a directive
stating a categorical “No” to the option of employees bringing
their own devices to work. Such an
approach would have ensured not only a uniformity of
technologies being deployed company-wide and
Intel’s ownership of all IT devices used in the company but also
corporate oversight. However, this
approach would have meant falling behind ongoing trends and
alienating a portion of its employees.
Studies by both Gartner and McKinsey had pointed out that IT
mobility was a rising phenomenon (see
Exhibit 1: Top 10 Emerging Trends).
The third option was to support BYOD, an approach that had
seemed logical in light of some irrefutable
“laws” of information security, as Harkins saw them:
These are unwritten laws that one must acknowledge. For
example: Users want to click;
when connected to the Internet, people will click on things.
Information wants to be free;
people are prone to talk, post, and share. Code wants to be
wrong; a software program
can never be 100 per cent error-free. Services want to be on tap;
some background
processes will always have to be switched on. Security features
are double-edged; they
help and they also harm. People set and forget; the efficacy of a
control deteriorates with
time. In such a context, compromise is inevitable for CIOs
[chief information officers].
They cannot enforce rules of their own.

Dating back to the early 1990s, Intel’s IT division had
acknowledged these laws. As personal computers
became common in the homes of its employees, Intel allowed
some employees to log in to the Intel
network from their home systems and to use that ability to work
from remote locations. Subsequently,
however, amid concerns over data security risks, Intel had
limited this provision to employees who were
undertaking mission-critical processes.
Page 3 9B13E002
The launch of laptops in 1997 had, for the first time, brought
the use of personal devices not connected to
the corporate network, to centre stage. Laptops were followed
by wireless access points, ultra-portables,
tablets and net-books. But it was the arrival of smartphones in
2006 that marked the beginning of the
BYOD trend. The increasing functionality of smartphones and
similar devices had, in some cases,
become comparable to laptops in their ability to not only
process data but store data. Smartphones could
connect to the data centre and plug into corporate applications
hosted on the cloud. The trend was
unstoppable; by early 2009, Intel recognized that it needed to
implement a strategy to address the BYOD
trend.

As part of developing a strategy, Harkins was keen on gathering
the input of not only employees who
were bringing their own devices to work but also those
employees who were not doing so. He organized a
two-day web jam in March 2009. Over an uninterrupted 48-hour
period, his team took queries, in turns,
from nearly 7,000 employees and responded to more than 1,000
cyberposts. The web jam was an
opportunity not only for Intel employees worldwide to provide
input on how they wanted to use their
smartphones but also for the IS team to explain what the use of
smartphones meant to the organization,
going forward.
Although only 30 per cent of participants were okay with
corporate access to their personal devices, there
was a near unanimous view in favour of Intel managing the
security of personal devices; and, in return for
the freedom to bring their own devices to work, 100 per cent
were willing to accept necessary training
and adjustments to their behaviour.
Accountability became one of the pivots around which the
policy evolved. It cut both ways. IT was
accountable for providing the technology footprint with which
to manage devices; and employees were
accountable for understanding the potential risk the devices
they brought to work carried for the company.
For years, Intel had been losing one per cent of its notebooks
annually; they were either misplaced or
stolen. But, under the terms of the BYOD initiative, Intel no
longer needed to buy the devices. Allowing
employees to bring their own devices would reduce the
incidence of hardware loss; employees would be

more vigilant about guarding them because of their sense of
ownership. An integrated personal and
business calendar on the device would also increase employee
productivity. Costs, per se, would decrease
because telecom carriers typically charged about 33 per cent
less for data plans for individuals than they
did for corporations.
It was evident that BYOD was not a technology issue; it
affected other company functions, such as legal,
HR and accounting, whose help was required in defining policy,
including such details as privacy and
software licensing and enforcing compliance. Also evident was
that a “one-size-fits-all” framework
would not work. Harkins developed a five-tier model to manage
the security risk inherent in BYOD (see
Exhibit 2).
Said Harkins:
A multi-tier architecture provides not only the greatest security
but also return on
investment. We classified the level of access to data and
services into five categories with
progressively higher degree of IS requirements. Level one, for
example, pertained to
corporate data, like stock price movements, which were
uploaded in real time on public
servers. Level two pertained to slightly confidential
applications like payroll. We had to
factor in issues of privacy at this level because the device was
owned by the employee.
Level three was what we called Basic and had the least
permissive level of access to

Page 4 9B13E002
corporate data. Examples of services included calendaring,
contacts and emails. Level
four, called Intermediate, consisted of applications pertaining to
specific lines of
business. Level five, called the Managed Equivalent, was the
most permissive level of
access to corporate data.
CONSUMERIZATION OF IT
For many decades, IT had been a standalone activity whose
understanding was limited to a few
employees in an organization. It still carried a mystique to the
vast majority, even as the giant mainframes
gave way to personal computers, and desktop computers made
data processing more accessible for
individuals. In the late 1990s, the arrival of hand-held
computing devices marked a new beginning of
employee empowerment that came to be called the
Consumerization of IT (CoIT), defined as “the
adoption of any consumer-facing technology for business
purposes.”2

Characterized by self-provisioning of technology, CoIT was one
of the most disruptive phenomena in the
workplace. It was encompassing many sub-categories of
computing, such as social media, cloud,
applications (apps) development and, of late, BYOD. From
CoIT, companies were securing business
gains, both internally and externally.
Internally, employees were becoming more resourceful and
innovative, leading to general gains in
organizational productivity. IT’s own productivity was
increasing because many consumer technologies
were self-supporting and end-users were readily shoring up one
another. IT could extend its capabilities
across the organization without requiring additional resources.
A company adopting CoIT could attract
and retain young and skilled employees, leading to
improvements in revenues, margins and market share.
Externally, CoIT improved the company’s engagement with
customers, vendors and business partners.
When CoIT was implemented as part of a multi-channel strategy
and for deploying tools of social media
in particular, it was easier for existing stakeholders to do
business with the company and for potential
customers to sign up for its offerings.
The greatest benefits came from the development of apps aimed
at delivering the right data to the right set
of users and managing both users and apps for the common
good. Mobile apps, in particular, could be
developed quickly and at a lower cost than traditional enterprise
apps. Employees were developing front-
end apps on their own, depending on their ongoing
requirements. This development and device freedom
had enhanced the spirit of enterprise in companies.

However, CIOs were facing several challenges with CoIT. First,
there were difficulties in securing the
buy-in for any CoIT initiative from functions such as legal and
accounting. These functions were
accustomed to a compliance mode; risk taking was not part of
their culture. A free-for-all culture, which
the CoIT phenomenon seemed to represent, was contrary to their
traditional mindset. Second, nurturing
the innovation that CoIT represented was difficult because
companies in general had no precedents for
how to encourage productive innovation within the context of
CoIT. The more dominant perspective was
that personal devices loaded with attention-diverting
applications were more representative of
2 “Consumerization of IT: How IT Should Manage Personal
Technology at Work,” InfoWorld Special Report, May 2012,
http://www.infoworld.com/d/consumerization-of-
it/consumerization-of-it-how-it-should-manage-personal-
technology-work-
194587, accessed December 10, 2012.
Page 5 9B13E002
productivity waste than enhancement; they were thus banned in
many firms, such as those on Wall

Street.3
To set up the systems and processes supportive of consumer
technologies, CIOs needed to secure the data
from threats of hacking, viruses and identity thefts; ensure
interactive apps experience; manage the load
on IT infrastructure and generally stay on the side of new
generation workforce. Also necessary was
keeping pace with changes in the legal and regulatory
environments in different countries where a
company’s employees were located. The singular challenge for
CIOs, however, was in keeping pace with
changes in their own domain of IT.
INTEL – COMPANY BACKGROUND
Intel was the world’s largest manufacturer of semiconductor
chips (see Exhibit 3). Its main products were
integrated circuits (i.e., chips etched with electronic switches)
and platforms (i.e., suites of digital
technologies), which were used as raw materials in computing
and communications industries.
Intel’s customers included both original equipment
manufacturers (OEMs) which marketed branded
products and original design manufacturers (ODMs) which
provided services to branded and unbranded
private-label resellers. In 2009, Hewlett-Packard Company
accounted for 21 per cent of Intel’s net
revenue (up from 20 per cent in 2008 and 17 per cent in 2007),
and Dell Inc. accounted for 17 per cent of
net revenue (down slightly from 18 per cent in both 2008 and
2007).
The semiconductor industry was characterized by a high

percentage of fixed costs in three areas: research
and development (R&D), employment of skilled workforce and
training of employees. The business was
subject to downturns because product demand was variable. The
product life cycle was limited, often less
than a year. As a result, the pace of technological development
and the frequency of new product
introductions were more rapid than in other manufacturing
sectors.
Intel was driven by the strategic mandate of “being the
preeminent provider of semiconductor chips and
platforms for the worldwide digital economy.” Its goal was to
“deliver a great ‘personal’ computing
experience across all types of devices and enable consumers to
move seamlessly from one type of device
to another.” 4 Intel was routinely launching products with
improved rates of data processing. It was also
innovating to continue to improve the connectivity, storage,
security, energy consumption, ease of use and
inter-operability of devices.
At the end of 2009, Intel had reorganized its business “to better
align our major product groups around the
core competencies of Intel architecture and our manufacturing
operations.” The company had nine
operating segments: PC Client Group; Data Center Group;
Embedded and Communications Group;
Digital Home Group; Ultra-Mobility Group; NAND
Solution

s Group; Wind River Software Group;
Software and Services Group; and Digital Health Group.
Said Harkins:
3 “Social Media Like Facebook, Twitter and Gmail Banned on
Wall Street,” New York Times, November 23, 2012,
http://articles.economictimes.indiatimes.com/2012-11-
23/news/35317526_1_social-media-youtube-videos-analyst,
accessed
December 5, 2012.
4 Intel’s 2009 annual report, http://www.intc.com/intelAR2009/,
accessed February 7, 2013.
Page 6 9B13E002

The growth of mobile microprocessor units has been outpacing
the growth of desktop
microprocessor units. This trend will continue. The escalating
demand for mobile
microprocessors will result in increased development of
products with form factors
requiring lower power. Their demand will be incremental to that
of desktop
microprocessors since a growing number of households have
multiple devices for
different computing functions.
In addition to its four wafer fabrication facilities in the United
States (in Arizona, Oregon, New Mexico
and Massachusetts), the company had manufacturing units in
China, Ireland, Israel and Vietnam and test
facilities in Malaysia, China and Costa Rica. It had sales and
marketing offices worldwide.
For the year ending December 2009, Intel had net revenues of
$35.1 billion5 and net income of $4.3
billion (see Exhibit 4). Intel’s revenues had declined by 7 per

cent over 2008, although the volume of
shipments had increased, as a result of falling prices. Asia-
Pacific was the single largest source of revenue
at 55 per cent, followed by the Americas at 20 per cent.
The company’s competitive advantages included scale, talent
pool, global reach and customer orientation.
ISSUES BEFORE HARKINS
Extracting value
Value from BYOD could be extracted from three sources: cost
reduction, productivity gains and
competitive advantage.
An obvious potential source of cost reduction was that Intel
would no longer need to pay for the 10,000
small form factor (SFF)6 devices already in circulation, for the
purchase of individual devices and for
their ongoing service and support. Although Intel had incurred
these costs in the past, once BYOD
became official, employees would assume these costs. The
savings could be large, based on the

expectation that, by 2014, nearly 60,000 more employees would
be bringing their own devices to work.
From reviewing the data over the past few quarters, Harkins had
accessed a vital piece of information:
Intel employees who were using their own devices were
spending, on average, an additional 57 minutes
every day on company-related work. This index of productivity
was known in IT parlance as “time back
per day per employee.” The company could use what was called
a “burden rate” of about $100 per hour
per employee to arrive at the gain in productivity. Additional
gains could be realized from employees
seizing every opportunity, outside the office hours, to carry on
the business of Intel through real-time
collaboration with internal and external customers. Employees
would also be generally happy about
BYOD, which would lead to gains like their rallying together in
the event of a deadline or an emergency.
Competitive advantage, particularly if it was to be sustainable,
could be built only on a long haul. Harkins
could see some potential sources of competitive advantage. For
example, networking would, over time,
lead to the development of better products and services. Use of

authorized device would also minimize
the general risk profile within IT.
5 All currencies amounts are shown in U.S. dollars unless
otherwise noted.
6 SFF devices were small computers, distinct from traditional
personal computers that had towers or conventional full-size
laptops. SFF devices included tablets and devices commonly
called netbooks, smartbooks or ultrabooks.
Page 7 9B13E002
Besides, Intel was making its debut in Fortune magazine’s 2010
annual list of the best companies to work
for in the United States, at 98th position in a list of 100. The

ranking, which would be useful for its annual
recruiting, was based on the facilities that Intel provided to
employees, such as telecommuting, job-
sharing programs and compressed workweeks. The provision of
BYOD would likely improve Intel’s
rankings, thereby leading to improved brand equity among
potential employees.
Said Harkins:
My difficulty is fundamental. How do I dollarize the risks and
returns of BYOD? There
are businesses at Intel which are sensitive to data walking out
the door. They would buy
into BYOD if they see, in measurable terms, how BYOD is
adding value. But we only
have intuitive information so far. What particular data should I
mine and apply in order to
arrive at the true value of BYOD?
Security

The security risk in a BYOD environment had two broad
components — device and data. The dilemma
before Harkins pertained to two areas: the extent to which
device security, which was new to Intel, could
be deployed and the extent to which data security, which was
prevalent in any case, could be extended in
a BYOD situation.
Traditionally, all the hardware that was owned and operated by
the company was equipped with such
built-in IS features as security settings, log-on procedures,
authentication protocols, access controls,
firewalls and anti-malware software (see Exhibit 5). The BYOD
situation would typically comprise two
types of devices — managed devices and unmanaged devices.
Intel layered its own security controls on
all managed devices; the controls took on two forms —
encryption and remote-wipe capability.
Like round pegs in a round hole, the managed devices fit
perfectly with the IT environment and IT
expectations. Unmanaged devices, however, were like square
pegs in a round hole. No single solution
supported all the devices owned by employees, thereby
representing a security risk.

Leaving a corporate footprint on the devices owned by
employees could be damaging for employee
privacy. Data encryption and remote-wipe capability would both
come into play when the data was
compromised or the device was lost or stolen. But the remote-
wipe would also affect personal data stored
by the employee on the device. The issue of privacy acquired a
serious tone, particularly when no
evidence of data compromise could be detected upon retrieval
of a lost or stolen device.
Another relevant issue related to the hourly employees. Intel
had 79,800 employees at Intel worldwide, of
whom 55 per cent were located in the United States. The
majority of Intel’s wafer fabrication activities
were also located in the United States. Hourly employees at
Intel US were required to report the hours
that they spent doing office work on their SFF devices while off
network and away from their
workstations. These hours counted not only toward their
overtime compensation but also for any related
expenses. Even routine activities conducted on an SFF device
outside normal hours, such as checking a
calendar or responding to emails, were required by Intel to be

logged as overtime. The log would leave a
trail, which would likely create a long-term liability for the
company in the event of any claim any time in
future by any hourly employee.
Page 8 9B13E002
Intel also had other concerns. Global IDs (such as Google ID
and Live ID) were gaining popularity, and
employees commonly had multiple global IDs, both on the same
devices and among their different
devices. Integrating global IDs into the corporate Active
Directory7 account was fraught with security
risks. A password that protected cloud-based email was not
adequate for protecting corporate data.

Data co-mingling was another potential hazard. If an employee
inadvertently placed corporate data on a
personally owned device of a friend or family member, who
then plugged into an USB connection to
charge up, the company’s data would be synchronized with
personal data. Another issue related to the
implications of jurisdiction (as in a country’s borders), where
normal data protection laws (including
one’s constitutional rights) did not apply.
Said Harkins:
At Intel, we follow what I may call the 4P framework for IS in
general: Prediction,
Persistence, Patience and Preparedness. The IS team should be
able to predict where the
security threats would be coming from, which parts of the
organization would be
vulnerable, and how the risk would manifest itself. It should be
persistent about things
that matter to Intel and the practices that we care about as a
company. It should be
patient, not alarmist, and refrain from screaming “the sky is
falling.” It should be

prepared with strategic controls, contingency plans and
mitigation procedures. My
dilemma is: How do we apply that framework in executing
BYOD?
e-Discovery
U.S. companies such as Intel had a legal obligation, under the
U.S. Federal Rules of Civil Procedures
(FRCP), to comply with demands from the courts of law for
inside documents in the event of litigation.
Everything in an enterprise — from terabyte-sized databases to
14-character tweets — was thus
potentially discoverable (i.e., subject to discovery) and
reviewable by litigants.
In December 2006, electronic discovery (or e-Discovery as it
came to be called) gained a mandate in the
United States. The FRCP were amended to expand the coverage
of e-Discovery to all document-intensive
information on which a company relied to conduct day-to-day
business. The amendment brought under
the purview of e-Discovery all computer systems and devices

storing digital information. It also brought
under its ambit all types of litigation — class action, corporate
fraud and employment. The changes gave
litigants wide-ranging powers to seek, as part of their review,
access to the whole range of data running
through the networks of an enterprise, including not only legacy
data archived on backup tapes but also
emails, instant messages, calendars and contact lists. Also
included in the accessible data were posts on
MySpace, a social media platform; records from the Global
Positioning System (GPS), a satellite-based
navigation protocol; and data from EZ-Pass, a toll-collection
system that automatically deducted tolls
from a prepaid account. All these data became part of what was
collectively …
Case Study Guidelines
Below, you will find the required format and the recommended
approach you should take in
analyzing the case study in this course.
The process you should use for analyzing a case study is:

• Read all assigned readings for the modules
• Read the case study using the Short-Cycle approach to
familiarize yourself with the case
• Read the case study using the Long-Cycle approach to analyze
the case
• Draft your analysis of the case (steps are on the following
pages). The deliverables for the
case are as follows:
o Problem Statement
o Problem and Data Analysis
o Alternatives
o Key Decision Criteria
o Alternatives analysis and evaluation
o Recommendation
o Action and implementation plan
o Executive Summary
Details on the Short-Cycle, Long-Cycle, and analysis steps are
on the following pages. Your
written analysis should follow APA guidelines and be free from
spelling and grammatical errors.

Required Format:
Your written analysis must have the following sections. Create
a document with these headers
and fill it in as you complete the deliverables. At the end of
your analysis, you will have a
complete analysis of your case when you submit your last
deliverable, the Executive Summary.
1. Title page (in accordance with APA format)
2. Table of contents
3. Executive summary
4. Problem statement
5. Problem and data analysis
6. Alternatives
7. Key decision criteria
8. Alternatives analysis and evaluation
9. Recommendation
10. Action and implementation plan
11. Reference List (if any)
12. Appendices (if any)
Note: Sections 3-12 should be level one headings in your paper.

These headings should be used
to automatically generate the table of contents for your paper.
Case Study Analysis
Analysis of the case should take the following steps (these are
not the headings for your paper;
these steps are the process you should follow to create the
sections in your paper):
1. Draft the problem statement
2. Analyze the case
3. Generate alternatives
4. Develop key decision criteria
5. Analyze and evaluate alternatives
6. Recommend and justify the preferred alternative
7. Developing an action/implementation plan
8. Write the executive summary
Problem Statement (Learning with Cases, pg. 41)

The problem statement should be a clear, concise statement of
exactly what needs to be
addressed. The problem statement should be one sentence, and
needs to be indicative of the
underlying business problem, NOT the technical problem. You
need to state why this problem is
important to a business.
Getting the problem statement correct is very important. The
problem statement will serve as the
basis for each of the following sections.
Many students also indicate that the problem is that the CIO or
other manager needs to make a
decision about some issue. If that were the case, the solution is
fairly simple—replace the
manager with someone who will make a decision.
Focus on what’s important to the business. You might want to
think about a sentence that is
structured like this:
(business problem) because of (technical problem)
The business problem is:

What will happen to the business if the technical problem
occurred?
What will the business no longer be able to do?
The technology problem is usually the technology issues present
in the case
As an example, you could state that a server has failed. From a
business perspective, that isn’t
much of a problem. However, if you reworded the problem to
state that the business would not
be able to process any customer payments because of a server
failure, that would be a problem
that would grab the business’ attention a lot faster.
It is also important not to include a solution in your problem
statement. If you wrote a problem
statement like this:
Customer payments cannot be processed because a server failed
and needs to be replaced.
By stating that the server needs to be replaced, you are
providing a solution that may not be the
best. What if the customer payment application could be moved
to a virtual machine? What if the

customer payment application needs to be replaced, regardless
of the state of the server? What if
the customer payment application could be collocated on
another server? By stating that the
solution is to replace the server, you have precluded any
investigation into other possible
solutions.
Problem and Data Analysis (Learning with Cases, pg. 43)
When analyzing the case, you should determine how the issues
in the case came about, who in
the organization is most affected by the issues, any constraints,
and any opportunities for
improvement. You should NOT be generating or discussing any
alternatives. This analysis
should further develop and substantiate your problem statement.
This section should be used to
summarize the basics of your case analysis. It should not be
used to simply retell the case
scenario.
A decent analysis of a case this size cannot happen in a

paragraph or two. There are quite a few
things that need to be brought up and discussed. The business
will be spending millions of
dollars because of the problem. A one or two paragraph
description of the problem is not
sufficient.
As you are conducting an analysis of you problem, you should
be highlighting the major parts of
the problem. Each of these parts needs to be fully developed
and explained in detail. Continuing
on with the example of the server failure, there may be several
underlying issues. What if the
server is very old? If so, parts not be readily available.
Additionally, the application could have
been written for an old operating system and may require
significant rewriting for it to work on a
modern operating system. Each of these issues should be a level
2 heading and will need
significant development. As you develop these issues, always be
sure to keep the business impact
in mind.
Be accurate in your description of the problem. Be sure that you
fully understand what the case is

discussing. You may need to read material outside of the case if
you don’t understand the
business environment at the time of the case or if you don’t
understand any of the technologies
mentioned in the case. You may also need to ask your instructor
for clarification. The bottom
line is that you need to write factual statements.
Do not use hyperbole. It’s doubtful that the problem is endless,
the risk is uncalculatable, or the
desired state is unattainable. If any of those were the case, we
wouldn’t have a case to analyze.
State facts without embellishing.
As you complete the problem analysis and learn more about the
case, you may find that you need
to rewrite your problem statement.
Alternatives (Learning with Cases, pg. 46)
Each alternative you develop should offer a different way in
which the problem could be
resolved. Typically, there are many alternatives that could solve
the problem in the case. Some
alternatives may even be discussed in the case. You should also

develop your own alternative(s)
as well. It is very likely that the alternatives presented in the
case are not sufficient to solve the
entire problem.
Each alternative should have a level two heading.
Fully describe each alternative. There should be no description
of any alternative in future
sections; it all should be described here. As you continue with
your analysis, you may find
yourself adding to these descriptions as you continue to refine
your alternatives.
In the alternative descriptions, you should address all issues
that you identified in the problem
analysis. For each of those issues, create a level three heading,
and discuss how the alternative
does or does not address each issue.
You should also discuss cost for each alternative. As you
discuss cost of the alternative, you

should indicate what will be capitalized. Additionally, you
should take total cost of ownership
into account for any new systems that you may be
recommending. You should also be taking the
time value of money into account if any of your alternatives
will take more than a year to
implement.
You should also discuss schedule for each alternative. How long
will it take to implement each
alternative? Anything that takes more than three years needs to
have a very good justification. If
a project takes fewer than six months, you should reevaluate
your estimation. Very few projects
of any size will be completed that fast.
Each alternative should fully address all parts of a problem. For
example, let’s say a problem has
two major issues. Don’t have an alternative that addresses the
first issue, another alternative that
addresses a second issue, and a third alternative that is simply a
combination of the first two
alternatives and fully addresses the problem. In this case, the
first two alternatives are not viable
as they do not fully address the entire problem.

Each alternative should be realistic and have a reasonable
expectation that it could be
successfully implemented. If you have an alternative that will
take ten years to implement, cost
more than the market value of the company, or is beyond the
ability of the company to
implement, then the alternative is not realistic.
If you present an alternative that recommends making a decision
pending further investigation, it
is not an acceptable alternative for any case study that you will
analyze. All the investigation that
is going to take place is presented in the case. No more
investigation is possible, and a decision
needs to be made.
If you recommend doing nothing as your strategy, you must
provide clear reasons why this is an
acceptable alternative. This may be an acceptable alternative. In
fact, many cases present this as
an alternative. However, you need to justify the alternative, and
you will need to describe how it
does or doesn’t address the issues you identified in the problem
analysis. You will also need to

analyze the alternative with the key decision criteria that you
create.
Avoid providing one desirable alternative and two other clearly
undesirable alternatives. This is
gaming the system and might not be the best for the company.
Do the work necessary to provide
at least three viable alternatives.
Do not compare alternatives here; that will be done in a future
section. Do not state things like
this will be the favorite alternative amongst the employees or
this is the cheapest alternative.
Those type of statements imply that you have already done a
comparison. This section is for
fully describing alternatives, not for comparing alternatives.
Key Decision Criteria (Learning with Cases, pg. 47)
Once the alternatives have been identified, a method of
evaluating them and selecting the most
appropriate one needs to be used to arrive at a decision. The key

decision criteria you develop
now will be used later to evaluate all alternatives and will form
the basis for your
recommendation. These criteria should take into account the
issues you have previously
identified. Additionally, the key decision criteria should include
cost and schedule.
Each criterion should be a level two heading. A description of
the criterion and how it will be
used should follow each heading.
As you develop your criteria, do not mention any alternatives.
You should only be describing the
criteria. The criteria will be used to evaluate each alternative in
the next section.
Each criterion you develop should be atomic. In other words,
don’t combine several things into
one criterion. For example, some students use Time and Money
as a single criterion. These are
two different criteria and are usually opposing. If you find
yourself using a conjunction in the
name of a criterion, you could most likely split that into two
separate criteria.

For cost, you should explain what expenses will be included in
the cost evaluation, e.g. salaries,
equipment costs, maintenance fees. You should explain how you
will account for the time value
of money. Additionally, you should indicate what type of
depreciation schedule you will use for
any capitalizable expenses.
Each criterion needs to be measureable, and you need to state
exactly how you will use each
criterion to evaluate the alternatives. Here is an example of a
criterion that is explained, but not
measureable:
Secure solution. The most important decision criterion is if the
proposed alternative
offers a secure solution. The best solution will be the one which
helps keep the
company’s data and intellectual property safe and secure.
Alternatives will be measured
by analyzing whether the proposed solution is more secure than
the current environment.
The security analyzation will consider hardware, software, and
the human user aspect.

There are several things wrong with this description. First, what
hardware, software, and human
user aspects will one look at to determine if it’s the best
solution to keep Intel’s data and
intellectual property safe and secure? If we could determine
that, what measurement scale would
we use to rate the alternatives? Here’s an example of a criterion
that is measureable:
Remote wipe. Having the capability to remotely wipe a device
increases the security of
the device in the case of it being lost or stolen. This criterion
will be scored as follows:
• If Intel can enforce remote wipe on all devices, 2 points will
be given for this
criterion.
• If remote wipe is possible, but not enforceable, 1 point will be
given.
• If remote wipe is not possible at all, then 0 points will be
given.

Compared to the first description, this description is
significantly better. Any reasonable person
could read an alternative’s description, apply the remote wipe
criterion, and come up with the
same score. The same can’t be said for the first criterion.
As you are developing these criteria, you may find yourself
adding to you alternative
descriptions. You might need to do this to ensure the criteria
can be used to evaluate each of your
alternatives.
Alternatives Analysis and Evaluation (Learning with Cases, pg.
49)
Measure each alternative against the key decision criteria.
Describe how each of the alternatives
do not meet, meet, or exceed all of the key decision criteria.
You should explicitly state the score
each alternative achieves for all of the key decision criteria.
Each alternative should also be a level two heading. Underneath
each level two heading, provide
an analysis of the alternative. Under this analysis, have a level
three heading for each of the key
decision criteria. Under these level three headings, state the

score the alternative achieved and
explain why it achieved that score.
Do not compare alternatives in this section. You should be only
measuring the alternatives
against the key decision criteria.
Do not describe or explain any part of an alternative here. The
descriptions should have been
written earlier.
Do not evaluate an alternative against any criteria that are not
part of the key decision criteria.
For example, if you wrote a statement that indicated that
employee satisfaction would be highest
for an alternative, employee satisfaction should be a key
decision criteria and all alternatives
should be evaluated against it.
At the end of this section, include a summary table that lists
each alternative, the key decision
criteria, and how the alternatives scored against the criteria.
The table should look something like
this:

KDC KDC KDC Total Score
Alternative
Alternative
Alternative
Replace Alternative and KDC with the titles of the alternatives
and the names of the criteria,
respectively. If you have more than three alternatives, add a
row. If you have more than three
KDC, add a column.
Recommendation (Learning with Cases, pg. 52)
Clearly recommend one, and only one, of your alternatives. This
should be the first statement in
this section, and it should read something like this:
The XYZ alternative is recommended for implementation.
Don’t beat around the bush or try to put in a lot of “flowery”
words. Make it clear which
alternative you recommend.

After that, you need to justify your recommendation. You need
to explain why the alternative
was chosen. Use the key decision criteria as the basis for the
explanation.
You should also state why the other alternatives were not
chosen. You should also compare each
of these unchosen alternatives to the chosen alternative. Again,
use the key decision criteria as
the basis for the explanation.
Do NOT include in your explanation any criterion that wasn’t
listed as one of the key decision
criteria. If you think a criterion is important enough to mention
here, it should be one of the key
decision criteria and all alternatives should have been evaluated
against it.
Action and implementation plan. (Learning with Cases, pg. 53)
Discuss how the recommended course of action will be
implemented. Include costs, schedule,
and scope in this plan. Include any stakeholders and their
responsibilities.

Here is an approach to developing your plan:
- Develop a Gantt chart with the high-level tasks needed to
implement your
recommendation.
- Determine if there are any dependencies between the tasks
- Estimate which type of people or roles (manager, systems
admin, programmer, etc.) and
how many of each type would be needed to perform the task
- Estimate the duration and effort would be needed by those
individuals to complete their
work
o Duration is how long it will take to complete a task. Not
everyone is available 24
hours per day to work on a task. Also, some tasks may have
external
dependencies that might delay completion.
o Effort is how many hours of actual work it will take to

complete the task
- Use that estimate to determine the length of the project
o The duration of the tasks along with the dependencies between
tasks will
determine how long it will take to implement the project
- Use the effort estimation to determine the cost of the
employees working on the project
o At the financial services company I worked for, we used an
internal labor rate of
$65/hour on our internal employee costs. Unfortunately, we
didn’t actually get
n average of salaries, plus a
percentage cost for
our parking garage, cafeteria, rest rooms, hallways, etc. As
employees used those
facilities when they worked on a project, our Accounting
department wanted us to
include those costs in the internal labor rate.

o For your estimate, pick a reasonable internal labor rate
- Estimate the costs of any hardware/software
o As we don’t know what the contract rate that the company has
with equipment
and software suppliers, just pick reasonable costs.
- Combine the labor, hardware, and software costs to come up
with an overall cost
Once you have the Gantt chart created, you will need to explain,
in detail, each task. I would
recommend that you have a paragraph for each task. Within
each paragraph, include the
following:
• State what will be accomplished by the task
• List any dependencies the task has on other tasks
• State the type and number of people needed to accomplish the
task
• State the effort needed to complete the task
• State the duration of the task
• State the overall cost of the task

Besides the above guidance, you may also want to review some
of the material from ADMG 574
Global Project Management. Additionally, here are a few links
below that might also help:
https://www.leadershipthoughts.com/project-schedule-and-cost-
estimation/
https://4pm.com/2016/06/11/estimate-project-duration-cost/
http://smallbusiness.chron.com/methods-estimating-project-
times-cost-43036.html
https://www.leadershipthoughts.com/project-schedule-and-cost-
estimation/
https://4pm.com/2016/06/11/estimate-project-duration-cost/
http://smallbusiness.chron.com/methods-estimating-project-
times-cost-43036.html

Executive summary (Learning with Cases, pg. 109)
The executive summary should summarize the entire analysis
and should be written last. NB, this
summary should be directed towards a C-level executive in the
organization that is being
analyzed.
This is NOT a summary of the case; it is a summary of your
analysis
The executive summary should stand on its own. This means
that the summary should contain all
the facts it needs to make its point without referring to the rest
of the report. At a minimum, you
should provide a high-level description of the problem, the
recommendation, and a summary of
the implementation plan. You may include a brief summary of
the other alternatives if you wish
The executive summary should be on its own page, and it should
NOT be longer than one page.
The goal of an executive summary is for an executive to be able
to read it and make a decision. If
the executive wishes more detail, the executive will then read

the more detailed analysis.
Table of Contents
Use Word to generate the table of contents. If you used the
appropriate level for each of your
headings, the table of contents can be created with the Table of
Contents function on the
References tab in Word.
Process for Analyzing a Case Study (Erskine, Leenders, &
Mauffette-Leenders, 2007)
The Short Cycle Process
1. Quickly read the case. If it is a long case, at this stage you
may want to read only the first
few and last paragraphs. You should then be able to answer the
following questions:

1. Who is the decision maker in this case, and what is their
position and
responsibilities?
2. What appears to be the issue (of concern, problem, challenge,
or opportunity) and
its significance for the organization?
3. Why has the issue arisen and why is the decision maker
involved now?
4. When does the decision maker have to decide, resolve, act, or
dispose of the
issue?
5. What is the urgency to the situation?
2. Take a look at any exhibits to see what numbers have been
provided.
3. Review the case subtitles to see what areas are covered in
more depth.
4. Review the case questions, if any have been provided.
The Long Cycle Process

The Long Cycle Process consists of:
1. A detailed reading of the case
2. An analysis of the case.
When you are doing the detailed reading of the case study, look
for the following sections:
1. Opening paragraph: introduces the situation.
2. Background information: industry, organization, products,
history, competition, financial
information, and anything else of significance.
3. Specific area of interest: marketing, finance, operations,
human resources, IT, or
integrated
4. The specific problem or decision(s) to be made.
5. Alternatives open to the decision maker, which may or may
not be stated in the case.
6. Conclusion: sets up the task, any constraints or limitations,
and the urgency of the
situation.

Construct responses for each of the topics listed below. Support
your responses with clear reasoning and additional sources, as
appropriate.
Combine these into a single paper, with a title page that follows
APA format. Each topic will require 3-5 paragraphs to cover
thoroughly. Use the topic titles as your level one headings.
Include subheadings as needed.
Cite all sources used, including the course text book, and
include a reference page. Each topic should include at least two
sources. Sources (such as the text book) can be used for
multiple topics.
COBIT 5
Discuss the implications of using the COBIT 5 framework
within an organization and how the use of that framework will
impact communications with an organization's board of
directors.
Risk Mitigation
As it’s nearly impossible to mitigate all risks, what risks should
an organization mitigate? How should those risks be chosen?
Key Risk Indicators
A key risk indicator (KRI) allows a business to monitor changes
in the level of risk. The textbook does a good job of explaining
the benefits of using KRIs. What might be some of the

drawbacks?
Governance
The word governance has already been used multiple times the
textbook. What does governance mean and what role does it
play in terms of cyber risk from an internal organization
viewpoint?
Measuring Training Programs
Many organizations currently have security training programs.
What metrics could be used to evaluate the success or failure
these programs?
Legal Challenges
What are the legal challenges faced by companies as they grow
from doing business in one state, to doing business nationally,
and then to doing business in multiple countries?
Assessing Cybersecurity Program Maturity
If you were the newly appointed CISO for an organization, how
would you assess the maturity of the cybersecurity programs in
place?
Cybersecurity Hygiene
The readings focus on several cybersecurity systems and
controls. With all of the publicity surrounding data breaches
and ransomware, what is preventing organizations from
adopting systems and controls such as those mentioned in the
readings?
Zombie Zero

What sort of policies and procedures would an organization
need to protect itself against an attack from malware similar to
Zombie Zero? What role does upper management play?

S w W13035 INTEL CORP. – BRING YOUR OWN DEV.docx

Recommended

Recommended

More Related Content

Similar to S w W13035 INTEL CORP. – BRING YOUR OWN DEV.docx

Similar to S w W13035 INTEL CORP. – BRING YOUR OWN DEV.docx (20)

More from rtodd599

More from rtodd599 (20)

Recently uploaded

Recently uploaded (20)

S w W13035 INTEL CORP. – BRING YOUR OWN DEV.docx