Journal of Information Technology Teaching Cases (2014) 4, 70–85

© 2014 JITTC Palgrave Macmillan All rights reserved 2043-8869/14

palgrave-journals.com/jittc/

Teaching case

The City of Pittsburgh goes to the cloud:

a case study of cloud solution strategic
selection and deployment
Enrique Mu, Howard A Stern
Carlow University, Pittsburgh, USA

Correspondence:
E Mu, Carlow University, 3333 Fifth Avenue, Pittsburgh, PA 15213, USA.
Tel: 412 578 8729;
Fax: 412 578 8706;
E-mail: emu@carlow.edu

Abstract
Faced with diminished resources and a need to provide enhanced employee email services,
the City of Pittsburgh’s Chief Information Officer (CIO) had to navigate a stubborn bureau-
cracy to achieve his objectives. Using an IT-business alignment strategic approach to decide
on a suitable IT solution, the City was able to select and deploy a cloud-based system in an
objective and uncontested way. The City employed an Analytic Hierarchy Process prioritization
methodology, which used various criteria obtained from the stakeholders to develop a decision-
making framework to select the most suitable cloud solution. The case allows a review of best
practices in the cloud solution selection process, using theoretical lenses from the fields of IT
alignment, decision-making, and stakeholder management. This case study is particularly useful
for learning how strategic decisions to adopt IT are made in public organizations.
Journal of Information Technology Teaching Cases (2014) 4, 70–85. doi:10.1057/jittc.2014.5;
published online 4 November 2014
Keywords: IT alignment; IT strategic decisions; IT stakeholder management; cloud selection;
software as a service; analytic hierarchy process; AHP

Introduction

U
nable to dedicate sufficient resources to maintain its
existing email system, the City of Pittsburgh’s technol-
ogy department needed to explore alternatives. To make
this important decision, the City’s Chief Information Officer
(CIO) conducted a strategic analysis of the existing email
system and found that a cost-effective alternative – a cloud-
based solution – was worth considering. Therefore, the choice
was either to upgrade its existing infrastructure or to seek a
cloud-based alternative (a system that would host the City’s
email services off-site). To justify its ultimate decision, the City
developed a rigorous and transparent decision-making pro-
cess that would address stakeholder concerns while providing
an objective framework for determining the best cloud-based
solution for the City of Pittsburgh. This comprehensive
approach, as described in the following case study, led to a
decision that garnered the support and approval of City
employees, managers, elected officials, the vendor community,
the media, and the general public.
Background
The City of Pittsburgh, famous for its football team, the
Steelers, and its hockey team, the Penguins, has 306,000
residents and has been repeatedly named America’s ‘most
livable cities’ by Forbes.com, Places Rated Almanac, and The
Economist, a British magazine (Pittsburgh Post-Gazette (2010);
see Figure 1).
The city has left behind its past as the world capital of steel
to become a vibrant city, with several leading biomedical
firms, hospitals, and high technology companies, as well as
world-class higher education institutions such as Carnegie
Mellon University and the University of Pittsburgh.
The City of Pittsburgh functions as a strong mayor-council
form of government, and is made up of three governing
bodies: the Mayor’s Office, City Controller, and City Council.
The Mayor’s Office is the administrative and servicing branch
for the City of Pittsburgh. It includes operating departments
such as police and fire, as well as the economic development
and maintenance arms of the City such as Planning, Public
Works, and Information technology. The City Controller’s
office is the official ‘watchdog’ for the City of Pittsburgh; it
reviews, monitors, and reconciles all monies collected and
disbursed to ensure that expenditures are in compliance with
relevant rules and regulations. Finally, there is City Council,
the most inherently political of the three bodies. The Council
functions as a direct link to the public, as it is charged with
 The City of Pittsburgh goes to the cloud
Figure 1 View of the City of Pittsburgh skyline.
Source: Courtesy of Visit Pittsburgh
overseeing and approving any initiatives and actions that may
impact its constituents and the City at large. Whenever a new
policy initiative is proposed or expenditure request is made,
all three bodies need to be involved and consulted with
before approval and implementation can take place (City of
Pittsburgh, 2012a).
As the technical branch of the City of Pittsburgh, the City
Information Systems (CIS), which functions as the City’s IT
department, is responsible for providing computing services to
approximately 3000 City employees and for this purpose relies
on a centralized IT shop, 55 full-time IT employees, a $5.6
million operating budget and $500,000 capital budget. In
terms of server infrastructure, CIS employs VMware, Cisco
network core/edge, Microsoft Windows OS (Server/Client),
and Linux-based servers. The problem CIS is facing is the
increasing demand of City employees for mail services in
terms of quantity (3000 mailboxes at the time), mailbox size
(50–100 MB per mailbox at the time), cost, and support to the
system. CIS must choose between increasing its IT personnel
(as well as purchasing additional Microsoft Exchange servers)
or outsourcing its email services from a cloud service provider
(Software as a Service (SaaS)).
In September 2006, 9 months after the newly elected Mayor
of the City of Pittsburgh died of a rare brain cancer, the
26-year-old president of Pittsburgh’s City Council, Luke
Ravenstahl, ascended to the Mayor’s Office. Ravenstahl’s
appointment to Pittsburgh’s highest office created a great deal
of controversy and excitement for Pittsburgh. On the one
hand, the young mayor generated a lot of national exposure
and publicity for holding such a prominent position. On the
other hand, there were questions of maturity and inexperience
for such a young person commanding this leadership role. As
a newly appointed Mayor, Ravenstahl faced many challenges:
an underfunded pension program, rising municipal costs,
shrinking population, and a city still mourning the loss of a
beloved mayor. Fortunately, the young mayor realized that
technology was the key to innovation and efficiencies, and
thus he charged his CIO to search for creative and ‘outside the
box’ strategies to create an IT-savvy organization.
Aligning IT with the City of Pittsburgh’s strategic position
The City’s Information System (CIS) department does not
operate in a vacuum and for this reason it was important to
align the CIS modernization strategy with that of the City of
E Mu and HA Stern
71
Pittsburgh itself. To understand the City of Pittsburgh’s
strategic position, it is important to understand the nature of
the City administration and its technology department, as
shown in Figure 2.
CIS is responsible for the planning, acquisition, installation,
and support of the City’s proprietary and open computing
environments.1 This includes support of personal and mobile
computers and the development of specialized software pro-
grams for its Public Safety and Finance departments and for
other departmental initiatives. CIS provides network services
for its users and maintains the official City website (http://
www.city.pittsburghpa.gov). There are more than 3000 City
employees supported by CIS, with many of these employees
(such as garbage collectors and Parks department laborers)
having little or no contact with technology while at work. It is
this lack of exposure to technology, coupled with the City’s
inability to understand its IT alignment, that created an
organizational culture of obsolescence and inefficiency.
CIS is divided into five distinct divisions: public safety,
client technology, open systems, operations, and systems
development. Public safety develops applications for its police,
fire, paramedic, and building inspection personnel. Such
applications include the automation of police record reporting
and the digitized blueprints of city structures. Client technol-
ogy supports the voice and data needs of end users by
acquiring and installing hardware and troubleshooting tech-
nology problems of its workforce. The open systems division is
responsible for the design and development of the organiza-
tion’s enterprise systems, such as enterprise resource planning
(ERP) and business support systems (BSS) to run both the
financial and day-to-day operations of the City. The opera-
tions division serves as the help desk and training arm for the
City’s workforce. Finally, the systems development area is
responsible for the design and maintenance of home-grown
and proprietary computer applications such as real estate
taxation and human resource programs.
Each of these divisions has its own mission and responsi-
bilities and employs a group of technology professionals with
varied work experiences and backgrounds. Work experience
ranges from recent college graduates to long-term civil
servants, many of whom have only a high school education
but more than 30 years of government experience. This range
in work experience has presented unique challenges for City
IT managers. Unfortunately, many of the employees who have
significant work experience in technology are the same ones
 The City of Pittsburgh goes to the cloud
72
Figure 2 City organizational chart.
Source: City of Pittsburgh (2012).
who have the weakest technical skills. These seasoned employ-
ees have not always kept their skill sets current. As a result, the
City has many highly paid IT employees with abundant
mainframe and mini-computer experience, which is obsolete
in today’s technology environment. On the other hand, the
younger and newer employees, with skill sets in virtualization
and cloud computing, tend to hold entry-level positions, often
earning less money with less job security than their more
experienced colleagues. Because of these disparities, the newer
and sometimes frustrated employees often leave City employ-
ment for higher-paid private sector jobs that offer more
stability and greater earning potential. Put another way, the
younger and sometimes more technically savvy employees
tend to seek opportunities that reward outcomes rather than
longevity.
In order to deal with the strict limitations and challenges of
providing technology resources to the City’s workforce, a
strategic analysis of CIS, with respect to the delivery of email
service services, was performed as summarized in Figure 3.
As can be seen in Figure 3, the analysis2 of the internal
variables showed that CIS faced serious limitations of financial
and technical resources. This suggested that hiring additional
personnel to cope with the growing need of email services
would be very difficult. Assessing the specific personnel,
hardware, and software requirements was not easy since the
demand for services was hard to predict accurately, even as it
was growing continuously. Furthermore, due to City regula-
tions, any new hire would need to reside within the City limits,
which decreased the pool of candidates. On top of this, CIS
E Mu and HA Stern
had traditionally had a hard time retaining highly qualified
technical employees who were soon tempted with high
salaries, more commensurable with their skills, by private
firms in the City. At the external level, the City was being
pushed toward higher integration with other government
agencies, such as that of Allegheny County, to optimize
services and be cost effective.
To recommend a new email solution, the City’s CIO
understood that he was required to minimize costs while
keeping the same (at least) quality of email services, the ability
to scale services up as needed, and an openness to future IT
initiatives. His analysis strongly suggested that going to the
cloud (at its core, an extreme form of outsourcing) to contract
email as SaaS was also ideal for the City of Pittsburgh to fulfill
the needs for innovation and efficiency while keeping costs
under control.
The City’s CIO realized that his own technology employees
would be skeptical of going into the cloud and would be biased
against the quality of cloud services once contracted (what one
manager had called the ‘we could’ve done it better here’
syndrome). It thus became clear that the critical success factor
for cloud services would be a complete buy-in from the
employees at the CIS and City level. The CIO knew that the
importance of stakeholder buy-in has been traditionally
recognized as important in public administration and
that the City had direct experience with what could happen
when stakeholders felt they had not participated in
the decision-making process. A project to create a wireless
downtown in the City a few years earlier, for example, had
 The City of Pittsburgh goes to the cloud
Figure 3 City of Pittsburgh IT services strategic analysis.
Source: Roberts and MacLennan (2006).
faced numerous difficulties and resistance by unconvinced
potential users.
Based on the above, it was decided that stakeholder
participation was needed from the start. The most critical
activity that would require stakeholder participation would be
the selection of the proper cloud service provider for the City.
Particular attention to the participation of CIS stakeholders in
the Cloud decision-making process was needed. Furthermore,
once cloud computing was accepted as the way to go, the next
question would be: Whose cloud? For this, we need to under-
stand the fundamentals of cloud computing.
Cloud computing
Although there are several definitions of cloud computing, it
can be best described as ‘a style of computing in which
dynamically scalable and often virtualized resources are
provided as a service over the Internet. Users need not have
knowledge of, expertise in, or control over the technology
infrastructure “in the cloud” that supports them’ (Rhoton,
2009). In previous years, many organizations had questioned
whether they should go into the cloud at all; more recently,
however, the question has been which services, which cloud,
and whose cloud? Due to the need to support the services
locally, a business model emerged in which large cloud
providers such as Amazon, Google, or Microsoft would
E Mu and HA Stern
73
provide the services while local vendors (also called integra-
tors) would market and support them.
Cloud service could be provided at different levels of
service, called service layers, as shown in Figure 4. It is possible
to contract out only the computing infrastructure (IaaS) from
providers such as Amazon. In addition to this, it is possible to
contract the development platform as a service (PaaS) from
companies such as Google App Engine, Microsoft Azure, etc.
Finally, it is possible to outsource the entire software pyramid
by contracting SaaS from companies such as Google Apps,
Microsoft Office Suite, Salesforce.com, etc. The City of
Pittsburgh would require service at the top layer level, SaaS,
since it would require the provision of email services to their
employees.
In addition to the server layers, there are different types of
cloud deployment services available: public, private, and
hybrid cloud, as shown in Figure 5. In a public cloud, the
customer shares the cloud services with other customers. This
is the option with the lowest cost because the customer does
not have any ownership of any of the cloud infrastructure.
A private cloud is owned and operated by the company, which
then shares services with different departments in the organi-
zation. A hybrid cloud is a combination of the previous
options where the customer owns part (usually a small part)
of the hardware (i.e. virtualized servers) for some applications
and deploys the rest within the public cloud. The deployment
 The City of Pittsburgh goes to the cloud
74
Figure 4 Cloud service layers.
Figure 5 Types of cloud deployments.
needs of the City of Pittsburgh were rather particular,
although common to government agencies. Due to the
confidential nature of the information it handled and the
potential for liability should this information be stored or
disseminated outside US soil (remember that the nature of
cloud disperses and stores the information at a global level),
the City of Pittsburgh would require a government cloud. In
this type of public cloud deployment, the provider would
guarantee that the data cloud storage would always take place
within US territory.
For a cloud user, there are several advantages to using
cloud-computing services, many of them quite similar to the
ones used to decide on outsourcing. For example, given that
the service provider can obtain economies of scale by having a
portfolio of customers, cloud service users can benefit by
optimizing their costs (since the user would pay only for the
utilized services and would not need to acquire and support
servers and related personnel). Still, there are other benefits,
such as scalability (also called elasticity) and flexibility.
Organizations can scale resources up and down as needed
relatively easy. Flexibility, enabled by virtualization, offers a
large set of options (e.g. software, memory) to organizations.
This allows the control of computing resources by adopters to
be separated from owning and supporting the computing
resources themselves. However, cloud services also present
some challenges. Losing control of security, privacy, and
availability of resources is worrisome for many institutions.
Probably the biggest concern for many institutions is the issue
of security. For example, Sony only recently disclosed that
personal information belonging to more than 100 million
customers had been hacked from the Sony Online
E Mu and HA Stern
Entertainment Network on two separate occasions (Daily
Mail, 2011). Still, cloud service advocates point out that banks
are also robbed all the time, but the times when people stash
large amounts of money in their homes are gone.
The City decides how to decide
The City of Pittsburgh had experience with previous projects
and understood that an element critical to the success of a
project was setting up a proper decision-making team. In
terms of team composition, it was decided that group
members would be selected not in terms of position, but
rather expertise. For example, from the technical group, all the
experienced experts, regardless of position or longevity, were
invited to join the decision-making team. Special attention
would be given to include also key personnel who would be
responsible for implementing the solution once a decision was
reached. Managers would be also cautioned about playing
down hierarchies and the need to have and accept dissent
among the committee members.
Given the need to optimize the time dedicated to discus-
sions, a structured approach toward team communications
was adopted. For this purpose, it was decided that a facilitator
with experience in leading decision-making groups would be
appointed. The facilitator would instruct the committee
members to indicate what they had liked or not liked about
the specific proposal on the table, and once each member had
done so, a second chance would be given to add a comment.
After this, a secret vote (using paper questionnaires) would be
used to assess the vendor proposal. This ensured the different
judgments and decisions would move along directly and
within the allocated time.
Finally, with respect to the decision process control, it was
decided that the effort would be led by the City CIO (as the
senior officer involved in the decision) and the decision-
making facilitator, and the follow-up process (e.g. producing
minutes, collecting questionnaires) would be done by a project
manager. These three people would constitute the leaders of
the cloud-computing decision-making effort at the City. It was
also established that an AHP decision-making facilitator
would participate in the actual evaluation of vendors, but
would not vote on the selection so that his role could be
viewed as objective and impartial.
Developing a project timeline
After the ground rules had been defined, it was time to identify
the specific steps to follow and to develop a project timeline.
For many government organizations, developing a project
timeline can be a daunting task. For the City of Pittsburgh, the
process of exploring a cloud initiative was no exception. In
developing the roadmap for this initiative, the City had to:
(1) identify the stakeholders, (2) form a selection committee,
(3) write a Request for Proposal (RFP), and (4) develop a
credible, transparent, and legally defensible decision-making
methodology for selecting a vendor.
The first step in developing the project plan was to identify
all stakeholders who would be affected by the project. For the
email cloud initiative, the City’s CIO identified stakeholders
from the IT department, the budget office, City employees,
elected officials, cloud vendors, and the media. The goal
was to identify those individuals who had a vested interest in
 The City of Pittsburgh goes to the cloud
this initiative, and to develop a strategy to respond to their
concerns.
When the stakeholders for the City’s cloud technology
initiative were initially identified, we failed to consider the
City’s public safety officers – particularly police and parame-
dics – and their concerns for data privacy. It was only after the
media announced the City’s intentions to move its email to the
cloud that these public safety officials came forward. These
newly self-identified stakeholders demanded assurances that
only authorized personnel have access to the sensitive criminal
and medical information they collect. Once they came for-
ward, the selection committee was able to incorporate their
demands into the project’s requirements. Another self-identi-
fying stakeholder that played a significant role in the City’s
cloud technology project was a vendor that provides help desk
services to organizations converting their email systems from
one platform to another. Prior to the vendor’s communica-
tions with the selection committee, the committee had
assumed that the City’s existing help desk capabilities were
sufficient. Once the vendor raised the issue, however, the
committee evaluated the expertise and skill set of its existing
help desk staff and determined that an outside vendor
specializing in SaaS email should be retained to provide help
desk services during the implementation phase of the project.
Had the vendor not come forward, the City would not have
retained outside help desk services and the implementation
likely would not have gone as smoothly.
Next, a cloud computing selection committee was formed.
This committee included representatives from Pittsburgh’s IT
department, finance department, Mayor’s office, and the City
solicitor’s office. In addition, the CIO from the county in
which the City is located (Allegheny County) was invited to
participate. The hope, of course, was that an external CIO
would add credibility and an outside perspective to this
process.
Once the selection committee was chosen, an initial meet-
ing was scheduled to introduce the team members to each
other and begin the tedious process of developing an RFP.
This process turned out to be more time consuming and
laborious than expected. Each committee member shared his
or her own perspective on the project; accommodating each
committee member’s interest was difficult at best. In develop-
ing the RFP, the technology staff demanded language that
addressed security, backup, and hosting concerns. The finan-
cial stakeholders wanted assurances that a cloud project would
reap financial savings for the City. The Mayor’s office staff was
anxious about negative employee and media sentiment, while
the law department wanted assurances that the decision-
making process was reasonable and legal.
Fortunately, the selection committee was able to obtain an
RFP from another government entity, Los Angeles, which had
recently launched its own cloud-computing initiative. This
document proved to be a good starting point for the commit-
tee. After several meetings, the committee identified the
project requirements and attempted to address its own and
competing stakeholder concerns. The City was ready to release
its RFP.
Once the RFP was released, the City had to determine a
method for selecting the vendor that most closely fit the needs
of the City. The City’s CIO knew that selecting one vendor
over another could be controversial and potentially challenged
in a court of law. The financial and political benefits of being
E Mu and HA Stern
75
the selected vendor would be substantial. Not only would the
winning vendor enjoy years of business and guaranteed
revenue from the City, but a successful vendor would enjoy
the publicity garnered from being selected over its competi-
tors. Perhaps most importantly, the decision-making process
had to be defensible in a court of law. Undoubtedly, there
would be some unhappy vendors at the conclusion of this
process, and it was imperative that the City develop a process
that was reasonable, fair, and transparent. In fact, there is a
history of accusations and vendor challenges even in the
young cloud technology arena. For example, Google sued the
US Department of the Interior, accusing it of preparing an
RFP that made it difficult for Google to respond (Sarno, 2010).
Similarly, Microsoft did not hesitate to suggest that Google
misled the County of Los Angeles in its Federal Information
Security Management Act (FISMA) certification. Microsoft
alleged that Google does not meet the strict security standards
required for government agencies (Tsukayama, 2011).
It quickly became evident that selecting a vendor would
prove to be easier said than done. Certainly, the committee
knew the important players in the field and their particular
strengths and weaknesses, but how would the selection
committee differentiate among the competing vendors? Was
there a substantive difference between a Verizon and Micro-
soft offering? Was a Google solution more robust than an
Amazon product? Finding the answer to these questions
would not be an easy task, and a rigorous and sound
decision-making methodology would be required.
Fortunately, the City’s CIO had recently attended a pre-
sentation about a specific decision-making methodology at a
local university. The presentation provided an overview of the
Analytic Hierarchy Process (AHP) method for decision-
making. The presenter, a professor and expert on AHP
decision-making, demonstrated the virtues of AHP by show-
ing how people could make a decision to buy a new car, and
how to assess the importance of each factor in reaching a final
outcome. After seeing this highly structured yet still intuitively
clear approach, the City’s CIO concluded that such a process
might be helpful to the City of Pittsburgh.
The City’s CIO invited the AHP expert to speak with the
selection committee to discuss the merits of this decision-
making methodology. Once again, the AHP expert used the
car-buying example to demonstrate the power and resilience
of the system. The City’s selection committee had three
questions about this new and intriguing decision-making
methodology: (1) is AHP a proven and accepted decision-
making methodology?, (2) is AHP transparent and easy to
explain to all participants?, and finally (3) could an AHP-
based decision be defended in a court of law?
The AHP professor’s answer to the first question was that
AHP has been used for nearly 50 years by both government
agencies and industry. He explained that AHP is one of the
most widely used multi-criteria decision-making methodolo-
gies in the field. As for AHP’s transparency, the expert
explained that since the product is easy for administrators
and users to understand, few people question the process.
Finally, regarding the defensibility of the AHP process, the
AHP professor explained that he was not aware of any legal
challenge to the AHP process in a court of law. He further
asserted that if administered properly, he would defend the
merits of AHP before the City Council, the media and in a
court of law, if necessary.
 The City of Pittsburgh goes to the cloud
76
As it turned out, convincing the selection committee to
use the AHP method was an easy sell. Impressed with the
method’s transparency and power, the committee invited
the professor to serve as a decision-making facilitator
who would enable the committee to employ the AHP
methodology.
The essence of the AHP is the subdivision of a complex
decision-making problem or planning issue into its compo-
nents or levels, and arranging these levels into an ascending
hierarchic order. At each level of the hierarchy, the compo-
nents are compared relative to each other by using a pairwise
comparison scheme. The components of a given level are
related to an adjacent upper level and thereby generate
integration across the levels of the hierarchy. The results of
this systematic process are a set of priorities of relative
importance or method of scaling between the various actions
or alternatives. The relative priority weights can provide
guidelines for the allocation of resources among the entities
at the lower level. For further discussion of the AHP method,
the reader is referred to the AHP literature (Saaty, 1982). For
reference purposes, a summary of the methodology is pro-
vided in Appendix A.
The cloud evaluation process
A selection committee with representatives of the different
City stakeholders was appointed. This committee was con-
stituted by representatives from the different relevant areas in
CIS: technical, financial, and legal. See Appendix B for a list
Figure 6 Cloud SaaS technology decision-making AHP hierarchy.
E Mu and HA Stern
of committee members in terms of their functions. The
committee issued an RFP3 that was made public to invite
bidders. Once the proposals were received, the next step was to
determine a decision-making approach to select the best cloud
proposal. The committee led by the AHP facilitator assembled
the RFP as an AHP hierarchy (see Figure 6 – Cloud Selection
Hierarchy). The explanation of the criteria and sub-criteria is
provided in Appendix D.
Each criterion corresponded to a different domain (e.g.
technical, financial, vendor qualifications, opportunities, and
end-user transparency) and the responsibility for the assess-
ment and weighting of each sub-hierarchy was assigned to
different sub-groups within the main committee by the CIO.
See Figure 7 for the cloud selection hierarchy with weighted
criteria.
Seven vendors responded with proposals. The proposals
were reviewed by the committee and, afterwards, each vendor
was requested to give a presentation to the whole committee.
During the presentation, the committee members had the
opportunity to ask questions related to their area of responsi-
bility in the decision-making process. After each presentation,
committee members filled in a questionnaire to evaluate the
vendor score in each of the specific selection criteria/sub-
criteria (see Appendix C for a sample questionnaire). A project
manager collected all these questionnaires and entered the
judgments into an AHP software package for aggregation
purposes.
At the end of the process, the final results were obtained and
presented to the whole committee in a special final selection
 The City of Pittsburgh goes to the cloud
Figure 7 Cloud selection AHP hierarchy with weighted criteria/sub-criteria.
session. In this final selection session, the winner was revealed
– a Google solution provider (Company 4 in Figure 8).
A what-if (sensitivity) analysis was performed in front of all
the committee participants (see Figures 9 and 10 for examples
of the case of financial cost and technical requirements being
the most important criterion, respectively). The sensitivity
analysis demonstrated that in all cases the original selection of
Company 4 was still the best choice. All committee members
agreed to the vendor selection as well as the robustness of the
decision.
The aftermath of the decision
After months of interviews, discussions, and evaluation, the
City’s selection committee was ready to recommend Google
as the cloud provider for its email services. The Com-
mittee anticipated that its decision to award a contract to
Google would spur resistance from many stakeholders, includ-
ing the unsuccessful respondents to the RFP. To respond to a
possible backlash from those individuals and vendors who
would not be happy with a Google award, the committee
decided to obtain support from the City’s elected leadership
before a public announcement was made. The committee
believed it was important that the City’s elected leadership
E Mu and HA Stern
77
be prepared to respond to any naysayers or critics of the
committee’s decision to award the contract to Google.
The first elected stakeholder that needed to be informed
was the Mayor. As the highest ranking official in City
government, the Mayor is typically the first point of con-
tact for the media and the public. It was imperative that
the Mayor understand the value of the project and be
prepared to address any questions of process and transpar-
ency. At this meeting, the Mayor was briefed on the
composition of the selection committee and its choice to
use the AHP decision-making methodology. The Mayor
was also informed that a total of seven vendors responded
to the RFP, all of whom were invited for an on-site
interview.
The Mayor was pleased with the decision process and
the fact that the cloud initiative was aligned with the
City’s strategy of technology innovation and cost savings;
therefore, he ordered his communications director to craft
a press release to announce the decision. But before
the announcement was released, the CIO wanted to meet
with the City’s other elected stakeholders to inform them
of the committee’s decision. The CIO knew that the
decision to switch from Microsoft to Google would repre-
sent a sea change for Pittsburgh’s email services, and that
the City’s elected leaders should be prepared to address
 The City of Pittsburgh goes to the cloud E Mu and HA Stern
78

Figure 8 Final priorities for the selection of a SaaS solution provider.

Figure 9 Sensitivity analysis: if financial cost is the most important criteria.

any criticisms or questions from the media or unhappy scheduled a series of individual meetings with each of the
stakeholders. City’s other elected leaders, namely the nine elected City
Once the Mayor was satisfied with the committee’s process Council members and the City Controller. Again, it was
and decision to award a contract to Google, the City’s CIO imperative that these one-on-one meetings occur before a
 The City of Pittsburgh goes to the cloud
Figure 10 Sensitivity analysis: technical requirements are most important criteria.
public announcement was made, so that the City’s elected
leadership could be informed of the project, how the winning
vendor was chosen, and the project’s overall value to the
organization.
The decision to brief the City’s elected leadership before the
press announcement proved to be a wise strategy. Almost
immediately after the release, one of the losing respondents to
the RFP hired a high-powered lobbying firm from Philadel-
phia to challenge the committee’s recommendation. It was
obvious that the charge of the lobbying firm would be twofold:
(1) to encourage Pittsburgh’s elected leaders to reject the
Google decision on the grounds that it was too expensive and
that the current email system was sufficient, and (2) to
question the City’s process and method of selecting a cloud
email provider.
Within days of the official announcement, the lobbyist
attempted to schedule personal meetings with as many elected
leaders as would agree to see her, including the Mayor. Some
elected officials met with the lobbyist while others ignored her
completely. Eventually, the lobbyist was successful in convin-
cing one Councilperson to question the committee’s decision,
which led to formal public hearing. Such hearings are designed
to provide an open and public forum to discuss the issues
and concerns of any government initiative. In this case, the
initiative was the feasibility of selecting an email cloud
provider and to question the process of selecting the winning
vendor.
The City Council invited Allegheny County’s CIO,
who served on the selection committee, the university
professor who had introduced and facilitated the AHP
E Mu and HA Stern
79
decision-making to the City, a City lawyer who would vouch
for the fairness and transparency of the process, the hired
lobbyist who questioned the committee’s recommendation,
and any other stakeholder that wanted to voice their
opinions. After some enlightening debate and discussion,
the City Council was ready to vote to approve or reject the
initiative.
The public meetings on the merits of this initiative validated
the need for a citywide cloud solution. As it turned out,
the overwhelming majority of stakeholders that testified
before the Council were strong proponents of a cloud
solution and touted the virtues of a Google decision.
Furthermore, some council members praised the search
committee for its meticulous and transparent approach
in selecting a vendor. The reaction from these public
meetings led to a very positive media coverage and the
Council’s unanimous approval of the project. At this
point, the hired lobbyist realized that any continued
efforts to derail this initiative would be futile and decided
to abandon her efforts to overturn an award decision. The
cloud-based email system was deployed within the com-
mitted time and the Mayor of the City announced its
successful implementation in a press conference (City of
Pittsburgh, 2012b).
Suggested Questions for Class Discussion:
Q1. Why was it important to assess the strategic posi-
tion of CIS in relation to the City strategy prior to
proposing a solution for the provision of email services
for the City?
 The City of Pittsburgh goes to the cloud
80
Q2. Why is it important to involve stakeholders (internal
and external) in the decision-making process as early as
possible?
Q3. Why was so much time devoted to the development of
a sound decision-making process? Is this equally important
in both the private and public sectors? What are the
differences between public and private administration and
the deployment of IT innovations?
Q4. The decision-makers quickly assessed, in this case
and based on previous experiences, the readiness of email
services to be migrated to the cloud. Can you think of
other IT services that could be easily migrated to the
cloud? Why?
Q5 The case ends with the Mayor of the City of Pittsburgh
announcing the completion of the project on time and on
budget. What factor(s) contributed to making this cloud
migration project a success? What constitutes IT success in
the end?
Notes
1 This City Information Systems departmental discussion is based
on the information provided by the official site of the City of
Pittsburgh.
2 The analysis was made using a strategic execution framework
originally proposed by Roberts and MacLennan (2006) and more
recently updated by MacLennan (2012).
3 The original RFP is a public document that will be delivered along
with the teaching note to the users of this case. However, keep in
mind that Appendix D is a summary of the original RFP.
References
City of Pittsburgh (2012a). [www document] http://apps.pittsburghpa.gov/mayor/
2013_November_Budget_FINAL.pdf (accessed 29 September 2014).
City of Pittsburgh (2012b). [www document] http://www.pittsburghpa.gov/rss/
print.htm?mode=print&id=1220 (accessed 29 September 2014).
Daily Mail (2011). SECOND security breach as Sony admits hackers have stolen
details of a further 25MILLION customers, 3 May [www document] http://www.
dailymail.co.uk/sciencetech/article-1382945/Sony-hacked-Another-25m-
customers-details-stolen.html#axzz2K4He9us2 (accessed 29 September 2014).
Decision Lens (2008). Better decisions for better performance [www document]
http://www.decisionlens.com (accessed 29 September 2014).
MacLennan, A. (2012). Strategy Execution: Translating strategies into action in
complex organizations, New York, NY: Routledge.
Pittsburgh Post-Gazette (2010). Pittsburgh named most livable city again,
4 May.
Rhoton, J. (2009). Cloud Computing Explained: Implementation handbook for
enterprises, 2nd edn, UK: Recursive Press.
Roberts, A. and MacLennan, A. (2006). Making Strategies Work, Edinburgh:
Heriot-Watt University.
Saaty, T.L. (1982). Decision Making for Leaders, Pittsburgh, PA: RWS Publications.
Sarno, D. (2010). Google sues U.S. over bidding for e-mail contract. Los Angeles
Times, 2 November [www document] http://articles.latimes.com/2010/nov/02/
business/la-fi-google-government-20101102 (accessed 29 September 2014).
Tsukayama, H. (2011). DOJ, Microsoft says Google Apps for Government
isn’t up to standards. The Washington Post, 12 April [www document]
http://www.washingtonpost.com/blogs/post-tech/post/doj-microsoft-say-
google-apps-for-government-isnt-up-to-standards/2011/04/12/AFd1lIQD_
blog.html (accessed 29 September 2014).
Vaidya, O.S. and Kumar, S. (2006). Analytic Hierarchy Process: An overview of
applications, European Journal of Operational Research 169(1): 1–29.
E Mu and HA Stern
About the authors
Enrique Mu, Ph.D., is Associate Professor of Management
and Co-Director of the MBA Program at Carlow University in
Pittsburgh, Pennsylvania. He is also editor-in-chief of the
International Journal of the Analytic Hierarchy Process, the
official journal for the AHP/ANP methodology.
Howard A Stern, Ph.D., is Associate Professor of Manage-
ment and Co-Director of the MBA Program at Carlow
University in Pittsburgh, Pennsylvania. Prior to joining Car-
low, he served as the Chief Information Officer for the City of
Pittsburgh.
Appendix A
The AHP decision-making methodology
The approach proposed for cloud vendor selection is called
AHP and was developed by Saaty (1982). This method
has been widely used for selection and prioritization of
alternatives and is particularly suitable for group decision-
making (Vaidya and Kumar, 2006). An AHP group-
oriented decision support software package, Decision Lens
(2008), allowed the cloud committee to quickly develop a
decision model for cloud technology evaluation, based
on the issued RFP. One main advantage of the AHP
methodology is its ability to measure both tangible and
intangible criteria and for this reason it has been widely
used in multi-criteria selection analysis (Vaidya and
Kumar, 2006). The process may be described as involving
the following steps: (1) model the decision as a hierarchy of
goal, criteria/sub-criteria, and alternatives; (2) prioritize
evaluation criteria/sub-criteria; (3) evaluate alternatives
with respect to each criterion/sub-criterion; (4) synthesize
the model to obtain the best alternative, and; (5) perform a
sensitivity analysis. Next, a brief description of these steps
will be given. The reader is referred to Saaty (1982) for a
more detailed discussion of the methodology. Also, the use
of Decision Lens software hides the calculations discussed
here.
Developing the hierarchical decision model
The first step in the AHP approach consists of modeling the
decision as a hierarchy. The hierarchy starts at the top with a
goal (first level) and is followed by decision criteria in the
subsequent lower level. Under each criterion, a third level of
sub-criteria can be added. The bottom and last level of the
hierarchy is constituted by the alternatives to be evaluated.
Figure 7 shows the decision model developed for the cloud
vendor selection.
Prioritizing the criteria and sub-criteria
In the second step, prioritizing or weighting the criteria, all
the criteria are compared pairwise (e.g. what is more
important: ‘technical requirements’ or ‘financial considera-
tions’?) with respect to the goal at hand (i.e. selecting the
most suitable cloud vendor). This is important because
rarely the different criteria/sub-criteria will have the same
priority for the decision-making. The intensity of these
judgments is represented by a value in Saaty’s (1982)
 The City of Pittsburgh goes to the cloud E Mu and HA Stern
81

numerical scale, which ranges from 1 – equally important Appendix B

to 9 – extremely important in a criteria comparison matrix.
Next, the weights of the criteria are derived by calculating
the eigenvalues of the comparison matrix. This process can Table B1 City cloud-computing selection committee members
be done in two ways. In one approximate method, the
matrix of judgments can be normalized and the average of Technical Information Security Analyst [1 person]
each row will provide the criterion weight or priority. Network Analyst 3 [3 people]
However, the accuracy of the results depends on certain Exchange Administrator [2 people]
characteristic of the matrix of judgments called inconsis- Political Innovation & Performance Manager [1 person]
tency, be it 0 or very low (provided as an inconsis- Financial Senior Budget Analyst [1 person]
tency index by the software). In another method, more
accurate and used by software packages, the matrix of Legal Legal Counsel [1 person]
judgments is raised to powers consecutively until a limit, External Allegheny County CIO [1 person]
where all the columns are equal, is reached. Any column Decision-Making Facilitator [1 person]
values (called the eigenvalues of the matrix) constitutes
the criterion weights or priorities. The results are robust,
provided that the inconsistency index is less than 0.1
(as reported by the software package). Figure 8 shows
the criteria/sub-criteria with their respective weights or
priorities. Appendix C

AHP sample questionnaire for item 3.1, sub-item 3.1.1.

Evaluating alternatives and synthesis
The third step consists of evaluating the alternatives (in
our case, the different cloud vendors) with respect to
each criterion/sub-criterion. In this step, the decision-
maker has two possible lines of action. Similar to the
previous step, one can compare the alternatives in a
pairwise fashion with respect to each of the criterion/sub-
criterion, build an alternative comparison matrix with
respect to each criterion/sub-criterion, and obtain the final
priorities for each of the alternatives by calculating the
matrix eigenvalues. This last process of calculating the final
priorities constitutes the fourth step in the AHP approach
and is called synthesis of the model. This approach, how-
ever, is not possible when the number of alternatives is
large, or if the possibility of adding or deleting alternatives
exists. This was precisely the situation for the cloud vendor
evaluation. For this reason, a different method, called the
ratings approach, was used. Using this method, a rating
scale consisting of the anchors excellent, good, fair, and
poor was developed and each cloud vendor was rated with
respect to each of the selection criterion using this scale.
The cloud vendors were then prioritized according to their
score in the rating process.
Sensitivity analysis
The final step, sensitivity analysis, consists of varying the
weights of each of the criteria to determine how the prefer-
ences might change if the importance of selected criteria were
to change. Doing this provides considerable reassurance that
the outcome is stable to variations in the judgments (Saaty,
1982). The cloud vendor evaluation committee conducted the
sensitivity analysis at a later stage once other stakeholders had
a chance to analyze the model and discuss the results. The
AHP method is particularly easy to use when it is implemen-
ted with a decision support software such as Decision Lens™
(2008); which was selected for this project due to its strength
in group decision-making support as it allowed the group to
quickly and visually understand the results and sensitivity
analyses.
3.1. Email
3.1.1. Email City of Pittsburgh’s RFP requirements
Vendor’s proposal (shown on the next page) must address how
the proposed solution meets the following City’s RFP email
criteria.
(a) basic email functionality, including but not limited to
send, receive, format, and attachment;
(b) ability to integrate with the City’s mail client
configuration;
(c) ability to integrate with any mobile device that supports
standard mail protocol;
(d) ability to integrate with DAS (direct attached storage),
NAS (network attached storage), SAN (storage area
network), and other supported configurations with
Microsoft Exchange;
(e) ability to create user-defined email groups or personal
folders based on search criteria;
(f) ability to journal to any email archiving solution;
(g) ability to define roles for email handling;
(h) ability to add both personal signatures and notes;
(i) retention policy;
(j) ability to retain email (List per-user limit);
(k) ability to copy, move, save, and store information to
desktop or local storage;
(l) ability to print stored information to a City facility;
(m) ability to scan or fax from multifunction devices to
email;
(n) ability to send, assign, and delegate tasks;
(o) ability to use email system remotely;
(p) ability to delegate email functionality to another staff
member (i.e. proxy assignments, mail folders, etc);
(q) ability to define access levels (e.g., Read/Write; Subscribe
to Alarms and Appointments, Modify Options, Rules, and
Folders);
(r) recall and/or retrieve within City email system and/or
current/future City archiving system.
 The City of Pittsburgh goes to the cloud
82
Based on the above requirements and the vendor proposal to address them (shown on the next page), indicate to what extent you
agree or disagree with the statement below:
The vendor’s proposal meets the City’s RFP Strongly
requirements disagree
1 2
3.1.2. Email Vendor (VENDOR 4) Proposed Solution
Google’s Government Organization branded Google Apps for
Government (Google Apps for short) provides an email
solution that is comprehensive, functional, and scalable. It
provides the following non-optional requirements:
(a) Google has a comprehensive email environment that
provides functionality, including but not limited to send,
receive, format, and attachment;
(b) Google Apps is generally accessed from any widely
available Web browser (Chrome Browser, Firefox, Safari,
Internet Explorer, etc). Google support integration to
major email clients such as Microsoft Outlook;
(c) Google integrates with mobile devices such as Blackberry,
Win mobile, Android, iPhone, and iPad. Technologies
such as POP, IMAP, Active Sync, BES, and Web-based
emails are supported;
(d) Google Apps does not require Microsoft Exchange, or
any local storage solution to operate. Using our Appli-
cation Program Interfaces (APIs), Google has the ability
to integrate with on-premise local storage solutions
should the City require this functionality for other
solutions;
(e) Google Apps has the ability to create user-defined email
groups or personal folders based on search criteria;
(f) Google Apps has its own integrated archiving and dis-
covery solution branded Google Message Discovery;
(g) Google Apps has the ability to define roles for email
handling;
(h) Google Apps has the ability to add both personal signa-
tures and notes;
(i) Google Message Discovery allows for Retention Policies to
be implemented and distributed in a number of different
ways;
(j) Google Apps allows for the Government Organizations to
retain email. Individual Users may retain 25 gigabytes of
mail. Google Message Discovery also allows Users to set
their retention policy up to 25 gigabytes. Archive Admin-
istrators for the total email environment have no limit to
the amount of email they would like to store based on size
or time frame;
(k) Google Apps has the ability to copy, move, save, and store
information to desktop or local storage. Google provides
support for POP, IMAP, Google apps for Microsoft Out-
look etc. These will allow users to have local copies of their
email if permitted by the administrator;
(l) Google Apps has the ability to print stored information to
a City facility;
(m) Google Apps support scan or fax from multifunction
devices to email if the multifunction devices can connect
via Pop or IMAP;
E Mu and HA Stern
Disagree Slightly Slightly Agree Strongly
disagree agree agree
3 4 5 6 7 8 9 10
(n) natively, Google supports task creation for individual
users which they control. Also there are many partner
solutions that provide the ability to create, delegate, share,
and collaborate on tasks. Google apps marketplace is
located at google.com/enterprise/marketplace;
(o) Google Apps provides the ability to use email system
remotely;
(p) Google Apps has the ability to delegate email functionality
to another staff member (i.e., proxy assignments, mail
folders, etc);
(q) yes, Google Apps supports these concepts. Using colla-
boration, users access control could be controlled for
documents, spreadsheets, etc. Additionally, notifications
could be created for users who are subscribed to sites
where if something is added or changed they would be
notified; and
(r) integrated Google Message Discovery provides ability to
recall and/or retrieve within City email system and/or
current/future City archiving system.
Appendix D
Model element definitions in the cloud SaaS technology AHP
decision-making hierarchy
These definitions refer to the elements of the model
in Figure 7.
I. Goal. The goal is to decide on a fully hosted Solution to
meet the City of Pittsburgh’s SaaS Email, Data Recovery, and
Data Collaboration RFP. The Solution will transition the
City’s current on-premise email system to a secure, hosted
email system for its approximate 3000 users. The City’s goals
are to reduce expenditures and enhance productivity by
ensuring that the Solution meets the following criteria.
II. Assumptions. The following are the assumptions of the
City for review of the Vendors and their corresponding
proposed solutions:
1. All Vendors and proposed solutions fulfill all the City’s
requirements, including those related to disaster recovery.
2. It is assumed that the City has provided all the Non-
Optional and Additional Technical Requirements neces-
sary for the vendors to provide a Solution to work with City
resources.
3. All decisions made are based on the Vendor proposal and
clarifications made in writing.
4. Each proposed solution includes approximately 3000 City
users and the corresponding number of mailboxes.
5. The City of Pittsburgh must address the different training
requirements based on each employee group, and the
 The City of Pittsburgh goes to the cloud E Mu and HA Stern
83

Vendor is required to provide a customized training proposed (or as similar as possible) solution. The better the
strategy for each employee group within the Solution. The opinion and the more similar the solution, the better qualified
employee groups are defined as: the vendor is expected to be.
Knowledge Worker: a City employee whose job requires 50%– Quality of response Score
100%computer use; Excellent 1
Occasional Worker: a City employee whose job requires 20%– Good 0.75
50%computer use; Average 0.50
Light Worker: a City employee whose job requires 0%–20% Below average 0.25
computer use. None 0
The information provided by each Vendor is true and
trustworthy. Whenever there were questions, vendors have
been contacted and required to reply in writing. 1.3. MBE/WBE Participation. The third sub-criterion will
III. Criteria. The key criteria below will be used to decide be MBE/WBE participation by the Vendor. The Idea of equal
which Vendor/Solution to choose from Vendor proposals and opportunity required for in the City of Pittsburgh Code is met
written documentation. All these sub-criterion will be used in by making a good faith effort in accordance with the criteria
the assessment of each Vendor qualifications. established by the City for the participation by Minority and
1. Vendor Qualifications. This criterion refers to the ven- Women Business Enterprises (MBE/WBE). The awarded
dor’s ability to implement the proposed cloud-based bidder shall produce evidence that a good faith effort was
email solution. Four important sub-criteria to consider are: made to include the participation of Minority and Women
relevant experience, quality of references, vendor’s ownership Business Enterprises. The City’s current goals are 18% MBE
minority participation and vendor/subcontractor partners’ participation and 7% WBE participation. All things equal,
location. MBE/WBE participation is preferred for the bid winner. This
1.1. Relevant Experience. The first sub-criterion is the sub-criterion is compromised of two categories:
relevant experience of the vendor in reference to the City’s 1.3.1. MBE Participation, that is the participation of MBE
requirements. Relevant experience is comprised of: participation measured as:
1.1.1. Number of years. The vendor has been working with
and implementing the proposed (or as similar as possible) Percentage of participation Score
solutions.
Excellent (100%) 1
Number of years Score Good 0.75
Average 0.50
10+ 1 Below average 0.25
9 0.9 None (0%) 0
8 0.8
7 0.7
6 0.6 1.3.2. WBE Participation, that is the participation of WBE
5 0.5 participation measured as:
4 0.4
3 0.3 Percentage of participation Score
2 0.2
1 0.1 Excellent (100%) 1
<1 0 Good 0.75
Average 0.50
Below average 0.25
1.1.2. Number of mailboxes. The vendor is currently mana- None (0%) 0
ging. Obviously, the more relevant experience a vendor has,
the better qualified it will be to implement the proposed
solution successfully. 1.4. Location of the Vendor and partners/subcontractors.
The fourth criterion is location of the Vendor and partners/
Number of mailboxes Score subcontractors. This element will acknowledge the location of
the Vendor and Partner(s)/Subcontractor(s) in proximity to
Excellent 1 the City of Pittsburgh, Pennsylvania. Vendors and Partner(s)/
Good 0.75 Subcontractor(s) located in the proximity of the City of
Average 0.50 Pittsburgh have an advantage to respond more quickly. Also,
Below average 0.25 and more fundamentally, the City of Pittsburgh has an
None 0 obvious interest in further the development of local enter-
prises. This criteria is comprised of the following:
1.2. Quality of References. The second sub-criterion is the 1.4.1. Vendor Location. Vendors are those firms that have
quality of the references provided by the Vendor. It is expected assumed the legal responsibility to participate in the RFP, that
that each of these references has worked with the vendor in the is, those signing the offer.
 The City of Pittsburgh goes to the cloud
84
Location Score
Excellent (city limits) 1 90 days for system administrator), adhere to City policy or
Good (Allegheny County: excluding city limits) 0.75
Average (outside of Allegheny County but still in PA) 0.50
Below average (bordering state to PA) 0.25
Poor (any other state) 0 for the users.
1.4.2. Partner/Subcontractor Location. Partners and Sub-
contractors are those firms co-participating in the implemen-
tation of the proposed solution.
Location Score
Excellent (city limits) 1 current proprietary format, and administrator distribution
Good (Allegheny County: excluding city limits) 0.75
Average (outside of Allegheny County but still in PA) 0.50
Below average (bordering state to PA) 0.25
Poor (any other state) 0 continuity plan, annual testing of DR plan, defined identifica-
2. End-User Usability/Transparency. The ability of the
Vendor to provide an easy-to-use solution (transparent) for
the city employees will be assessed under this criterion. This
means taking into consideration that the users are already
trained and familiar with the City’s current system. The most
transparent (or easiest to use) solution would be one that
would require either no or minimum retraining of the City
employees.
3. Technical Requirements. This criterion refers to the
degree of fulfillment of the technical specifications requested
by the City of Pittsburgh in the RFP. Although all proposed
solutions have been reviewed to fulfill the minimum (called
non-optional) technical requirements, they will vary in the
degree of suitability and technical excellence. Also, some
solutions may offer additional technical functionalities that,
although not essential, were requested as a convenient bonus.
All requirements will be measured in terms to what extent the
Vendor has met the City’s requirements. This criterion
constitutes the core of the RFP. In any IT selection, the
primary concern is that the new system will technically do
what is expected to do. Two groups of sub-criteria were
proposed: non-optional requirements, that is, those function-
alities that all proposed email services should fulfill, and
additional requirements, that is, convenient functions that,
although not required, facilitate cloud-based email service
deployment and use. Within each group, a detailed list of
technical characteristics was included as follows:
4. Non-Optional Requirements: Refers to the degree of
excellence in the fulfillment of the non-optional technical
requirements. There are eight (8) subcategories to be
evaluated:
4.1. Email: Solution must include basic email capabilities
and functionalities.
4.2. Contact Management: Contact management function-
ality, current contact information transfer and management,
and applications for desktops and mobile device.
4.3. Calendar: Basic calendar functionality and manage-
ment.
4.4. E-Discovery: Ability to search, retrieve, store, identify,
and report information.
E Mu and HA Stern
4.5. Archive and Backup: Ability to store and retrieve live
email data for a minimum of 180 days (90 days for user, and
legal requirements, retrieve and/or E-Discovery.
4.6. Collaboration: Ability to share, store, and access files
throughout the solution while providing a process flow feature
4.7. Solution Administration: Ability to meet all needs of the
system administrator including, but not limited to, full
access and control of administrative console, management
of domain names and aliases, synchronization of email
identities with internal directory, control of industry stan-
dard devices, control over email storage limits perused
based on maximum storage limits, integration with internal
applications, migrate Historical or user Archives from
throughout departments.
4.8. Disaster Recovery: Solution’s ability to restore email and
data within 1 h of interruption, written detailed business
tion of roles and responsibilities for both city and vendor, and
qualifications for initiating and ceasing ‘Disaster’ condition.
5. Additional Requirements. This refers to the degree
of excellence in the fulfillment of the additional technical
requirements.
5.14. Project Plan: A constructed and organized plan
including implementation method, installation plan, mainte-
nance and support features, and necessary resources (City and
Vendor) consumed specific policies, specific plans, specific
procedures, specific techniques, and general management of
project plan.
5.15. Milestones: A schedule of tasks and completions that
will be maintained throughout the process.
5.16. Documentation: Proper documentation has been
provided by the vendor for the Solution’s components used
by the user and administrator.
5.17. License: All license agreement terms, security policies,
and terms of service have been submitted by the vendor.
5.18. Maintenance: All compatible software, required hard-
ware, installation services, all applicable warranties, all main-
tenance, and solution updates have been provided by the
Vendor. The Vendor has agreed to implement and test the
entire system, and any defects or problems found by will be
fixed by the vendor.
5.19. Support: The Vendor has provided technical expertise,
staff, and effective procedures mandated for systematic errors.
Support for the solution is the Vendor’s responsibility includ-
ing but not limited to: monitoring of the solution, immediate
report of any malfunction to the City, term of service for 1
year, restore all City data in the event of a system malfunction,
failure, or compromise.
5.20. Training: Training options specific to the City’s three
different user groups.
5.21. Ownership (Data): The Vendor either declares that it is
the sole owner of the solution, or has provided proper
documentation and authorization from the solution’s owner.
The City remains the sole owner of all City data in the
Solution.
5.22. Security: The Vendor has provided specific details,
policies, procedures, compliances, regulations, and other
resources related to the security plans. The City’s data will be
segregated from other customer’s data, accessed only by
 The City of Pittsburgh goes to the cloud
authorized personnel, and remain in the continental United
States.
5.23. Materials and Equipment: The vendor has provided all
items that are required within the City’s internal network to
support the solution, Service Level Agreements (SLAs) for
escalation of issues/product improvement, and minimum
workstation requirements for the solution.
5.24. SLAs/Sustainability: The vendor has provided details
of how the SLA and sustainability required by the City has
been meant in the Solution.
5.25. Reports: Various samples of reports of the solution
have been provided by the vendor.
6. Financial. When thinking about financial considerations
we tend to think about cloud service pricing (4.5); however,
this is only one of the elements to be considered in financial
evaluation. For example, the form of payment and how
different this was from other vendors (distinguishing compen-
sation – 4.2) was considered to be important, as well as the
scope and specificity of services (4.1 and 4.3, respectively)
provided by the vendor (which would allow savings by not
having to contract them out). Finally, how stable the vendor
would commit the pricing to be (4.4. Ongoing preservation)
was also deemed important as part of the financial sub-
criteria. The financial criterion is important because it refers
to the amount of money needed to cover payment of the
Solution and its associated costs for using it. The lower the
costs of a solution, the more attractive the solution is.
E Mu and HA Stern
85
7. Opportunities. Allows the Solution to address the
Optional Requirements and provide innovative elements that
would benefit the City in the long run. Consistent with the
desire of remain innovative, it was expected that the new
system would open opportunities for innovation in the long
term (e.g. deployment of office productivity tools, video
conferencing, virtual drives, unified communication, instant
messaging).
Therefore, all things equal, the solution that would offer
more potential for these opportunities would lead the vendor
choice. In other words, the more the solution offers possibi-
lities to enhance functionalities/services rather than propos-
ing a static dead-end solution, the better. The Vendor is
given the opportunity to show the Solution’s unique growth
factors while meeting all necessary requirements within this
criterion.
IV. Alternatives
Alternatives are constituted by the different cloud solution
vendors that turned bids in response to the City of Pitts-
burgh’s RFP. To protect the identity of the vendors, they will
be referred only by a number ranging from ‘Vendor 1’ to
‘Vendor 7,’ corresponding to the seven proposals submitted
to the City of Pittsburgh for consideration. These alter-
natives are under consideration based on their official
proposed solutions.