How FORCSS Works: Case Study 1

This paper launches the Uptime Institute FORCSS Case Study Series and introduces the FORCSS Index

Uptime Institute FORCSS is a means to capture, compare, prioritize, and communicate the benefits, costs, and impacts of multiple IT deployment alternatives. Deployment alternatives may include owned/existing data centers, commercial data centers (wholesale, retail, colocation, managed service), or IaaS (including cloud) that is procured on a scale or limited basis.

FORCSS provides organizations with the flexibility of developing specific responses to varying organizational needs. This case study series will present the process of applying the FORCSS Factors to specific deployment options, and present the outcome of the FORCSS Index—a concise structure that can be understood by ‘non-IT’ executive management.

Each case study will characterize the business needs and requirements; identify the alternatives in consideration; and outline the team, tools, and stakeholders. The case studies will apply the six FORCSS Factors to each alternative. This process will consider the supporting data inputs and various organizational, policy, technology, or other characteristics. Characteristics may influence multiple factors.

This paper elaborates upon Introducing Uptime Institute FORCSS © 2013. In order to empower FORCSS users, Uptime Institute will continue to analyze and publish case studies, in addition to unique tools, guidelines, and research.

forcss #1

arrowsThe FORCSS Index is the executive summary presentation tool of a FORCSS process. The Index provides a graphical means to compare the deployment alternatives and the relative impacts of each alternative on each factor. In conversations with senior management, the Index will also facilitate discussions of the weighting of each FORCSS Factor in the ultimate decision.

The indicators may be placed in relative positions (high, medium, low) to reflect the advantages or the exposures within any given factor.

The FORCSS Index effectively compares multiple alternatives at the application or physical layer(s). Organizations executing a FORCSS analysis can populate multiple indexes to compare a range of deployment alternatives.

Certain data inputs may be weighted more heavily than others (positively or negatively) in determining the indicator position for a factor. These special considerations are defined as Key Determinants and are specifically labeled in the FORCSS Index output.

Several data inputs may be used to determine the indicator position for one factor, and one data input may affect the placement of indicators in several factors.

The FORCSS Index is designed as a means of relative comparison of any number of alternatives. Although it would seem that the logical extension of this approach would be to assign numerical scores to each data input for each factor, during FORCSS development numerical scoring was found to add unnecessary complexity which can obscure the key determinants. Scoring can also mislead as the score assigned to one factor can numerically erase the score assigned to another (prohibitive) factor, thereby defeating one of the major benefits of the FORCSS process—identifying the blind spots in the decision-making process.

This case study was developed in close collaboration with a participant in the FORCSS Charrettes and early adopter of the methodology. Confidential and sensitive information has been withheld.

The case study participant (Enterprise) is a global financial organization offering retail, personal, commercial, and wealth management services to over 12 million customers. The Enterprise is aggressively expanding in terms of both geography and revenue.

Statement of requirements: The business need driving the FORCSS process was a requirement for approximately 10,000 square feet (ft2)of computer room to replace an existing data center. The existing data center shall be vacated due to leasehold terms or the lease extended. The deployment shall be within a specific major metropolitan area of the U.S. (Region). Additionally, the solution shall be operational no later than 14 months from the time the business need was defined (Time Frame). The deployment shall offer high-availability support to a heterogeneous IT environment, with a variety of legacy equipment, from both data center infrastructure and network perspectives (Performance Requirement). There are substantial financial consequences as a result of downtime.

Deployment alternatives: The Enterprise considered a broad range of existing/corporate assets and outsourcing options in terms of the parameters and Region, Time Frame, and Performance Requirement. In this case study, the Enterprise had narrowed its deployment options to three vetted alternatives and focused on the physical/data center layer.

Alternative #1 – Refurbishment: The existing data center was housed in a building constructed in the 1970s. Previously, the Enterprise entered into a sale-leaseback arrangement for the building with an initial lease term expiring in December 2013. The building owner required a minimum 10-year lease extension. The facility is inherently constrained in terms of both computer room footprint (no future expansion opportunities) and density (80 W/ft2). In order to meet the Enterprise’s business need, significant refurbishments would need to be undertaken on the electrical and mechanical infrastructure.

The Enterprise also anticipated that downtime would be incurred during the refurbishment, as well as an extended construction interval in close proximity to operational IT equipment.

Alternative #2 – Build: The enterprise owned a building within the Region that housed a back-office function critical to the business. There was sufficient space in the building to install a robust data center topology. Additionally, there was existing critical equipment (such as backup power) that could be integrated into the new infrastructure. There was no immediate constraint to expansion of the computer room footprint and an anticipated maximum density of 150 W/ft2.

Alternative #3 – Colocation: An outsourcing option within Region had space available and infrastructure installed that met the Performance Requirements. The Colocation was willing to provision available space to suit the Enterprise’s operating characteristics within the Time Frame. The Enterprise further vetted the Colocation as “eager for its business,” which increased confidence in an expedited contracting process, as well as amicable arbitration of any change to configuration. The Colocation offered enhanced physical security characteristics that exceeded Enterprise corporate standards. In the event of expansion, the Colocation could provide proximate space, but not guarantee contiguous space unless the Enterprise leased the undeveloped space (i.e., ‘shell’) immediately at a reduced rate.

Preparing for FORCSS
The Enterprise identified a core team, augmented by additional stakeholders and disciplines, to provide feedback and concurrence before presenting to senior management/decision makers. The Enterprise had many of the internal resources required to fulfill the functions necessary for this FORCSS Case Study. In the event an organization does not have internal resources, a third-party consultant would be contracted to fulfill those functions.

Assemble the Core Team and Tools


  • This individual was responsible for identifying the core team, coordinating with additional stakeholders, aggregating the data and feedback, populating the FORCSS Index, and presenting to senior management/decision makers.
  • Given the Time Frame, the FORCSS Leader utilized an on-staff Project Management resource to ensure timely responses from core team, vendors,
    and additional stakeholders.


  • This Enterprise function was responsible for building the business case but not responsible for the detailed accounting analysis necessary to procure services. Knowledge of the impacts of capital investment, leaseholds, and depreciation rates was key to this role to effectively identify and communicate the financial consequences of each alternative. For the Enterprise, this role existed and was known to the FORCSS team. However, this function could be ‘borrowed’ from another group. Many enterprises have an established tool to compare other (non-IT) deployment alternatives.
  • For example, this tool will evaluate potential locations for retail presences, transportation or distribution hubs, call centers, and office space. This formula will have been proven to be necessary and sufficient by the finance stakeholders. Thus, it will serve as an effective guide for the FORCSS team to determine the right level of financial detail for business case. It is important to note that the business case, and its formulas, will differ in detail and approach by organization and industry.

Computer Room Master Plan (CRMP) Team

  • The CRMP team documented Performance Requirement (resiliency, redundancy, functionality, Tier), density (watts/ft2), computer room footprint, layout of cabinets, and legacy IT equipment. In terms of legacy IT equipment, the CRMP team inventoried the type and technology; unique space, power, or cooling provisioning needs; as well as preferred placement within the computer room. The CRMP was the result of the close collaboration of the IT and Facilities/Engineering disciplines.
  • The IT group produced a Capacity Plan that included beginning-mid-end scenarios. For the Enterprise, the scenarios were established as Now, 5 years, and 10 years.
  • The Facilities group converted the IT Capacity Plan into Technical Facilities Requirements. The Technical Facilities Requirements established space, power, and cooling scenarios that responded to the IT Capacity Plan’s beginning-mid-end forecasts. The Enterprise had sufficient on-staff engineering competence and bandwidth to complete the IT-to-Facilities conversion.
  • The Facilities group was also responsible for multiple meetings with Engineering counterparts at the Colocation, as well as high-level feasibility analyses of the Refurbishment and Build locations.

This function reviewed the ongoing operations strategy for potential efficiencies of internal and outsourced staff, as well as assurance of staffing and expertise in accordance with the Performance Requirements.

Involve Additional Stakeholders
Additional Stakeholders may identify a key differentiator with significant influence on one or more of the FORCSS Factors. The Enterprise identified the following.

Other Corporate Requirements & Projects

  • Business synergies and additional return on investment may be located by conferring with the Property, Corporate Real Estate, or IT groups in regards to ongoing plans or projects underway at the buildings under consideration.
  • The FORCSS Core Team in this case study identified a project under careful consideration by the Corporate Real Estate teams in regards to the Build (Alternative #2). The project involved a ‘hardening’ of the infrastructure for the existing back-office function. The FORCSS and Corporate Real Estate teams
    determined that, if the two projects were joined together, the hardening would be achieved in a more efficient and less costly manner than if undertaken on its own. Result: Notable influence on the Build alternative.


  • The Enterprise had an established policy to purchase Carbon Credits to offset environmental impact. Environmental was informed of the nature of the project and any opportunities to impact its Sustainability. Result: No corporate-level influence.


  • FORCSS Core Team proactively identified sourcing options so that Procurement could complete background and validity checks. Result: No influence as all sourcing options met basic criteria.
  • Procurement provided insight into long-standing and/or large-scale business relationship(s) that could influence the sourcing of equipment or services. Result: No influence.


  • Insurance may be assessed at the site or corporate level. Result: No influence as Enterprise insurance was assessed at the corporate/portfolio level.


  • Typically, the Enterprise involved Risk/Compliance at the bid or contract phase. In order to assure a smooth FORCSS process, Risk/Compliance was notified proactively of the alternatives to identify any prohibitive issues at the corporate level. Result: An established Property Risk function within the FORCSS team provided ongoing assurance for this Enterprise.

Early Engagement of Decision Maker

  • The Enterprise featured a distributed IT organization with multiple CIOs. The FORCSS Leader briefed the CIO with purview over the Region, introducing the alternatives and evaluation model before fully populating. Result: No Influence.

Populating the FORCSS Index
The following section will elaborate on how the Enterprise considered each factor across the deployment alternatives.



Key Determinant: Comparative Cost of Ownership

Financial (Net Revenue Impact, Comparative Cost of Ownership, Cash and Funding Commitment)

As a large financial institution, capital was readily available to support the Refurbishment and Build alternatives. Also, business need did not necessitate a Net Revenue Impact analysis as the IT function was previously established as critical. These characteristic of the Enterprise increased focus on life-cycle costs and asset value. These illustrations show the financial analysis conducted by the Enterprise.

Alternative #1 – Refurbishment: Existing facilities infrastructure (power distribution, UPS, and mechanical systems) are substantially beyond the manufacturers’ recommended usable life and require significant investment to sustain operations in this location. This alternative has significant near-term (capital) and ongoing (10-year minimum lease) commitments and shortened depreciation term. (Indexed lowest)

Alternative #2 – Build: Constructing a purpose-built computer room in existing facility required capital investment but no lease obligation. Also, ownership allowed full depreciation cycle over the full life cycle of the project. (Indexed highest)

Alternative #3 – Colocation: This alternative offered the least near-term financial commitment but an ongoing and increasing expense over the life cycle of the data center. The Enterprise also considered, but did not quantify, a potential significant exit cost from the Colocation. (Indexed middle)



Key Determinant: Business Leverage and Synergy

Opportunity (Time to Value, Scalable Capacity, Business Leverage and Synergy)

During the FORCSS process, the Enterprise vetted all alternatives against binary criteria (e.g., 14-month Time Frame, location within Region). Alternatives that did not meet these criteria were eliminated.

Alternative #1 – Refurbishment: This alternative is constrained in both area and maximum density of 50 W/ft2 due to building characteristics. Also, cabling infrastructure is unable to adhere to the Enterprise’s deployment standards. (Indexed lowest)

Alternative #2 – Build: This alternative has a density limit of 200 W/ft2, with 8,000 ft2  it satisfies both area and density requirements. This alternative provides a business synergy—building out the backup power systems addresses a business continuity need for the back-office function. (Indexed highest)

Alternative #3 – Colocation: This alternative is fastest to Value (6 months versus 12 months for Alternative #2). It also provides the most scalability—with the option to lease contiguous space at a reduced rate from the provider, and proximate space available without the additional lease option. (Indexed middle)



Key Determinant: Cost of Downtime vs. Availability

Risk (Cost of Downtime vs. Availability, Acceptable Security Assessment, Supplier Flexibility)

Alternative #1 – Refurbishment: This alternative has a high risk of service disruption during the construction phase. Also, the location of this facility is near a potential terrorist target and is in a flood plain. (Indexed lowest)

Alternative #2 – Build: This alternative has no risk associated with construction and will be under corporate control of the Enterprise. (Indexed highest)

Alternative #3 – Colocation: The Colocation provider has proven competence in the industry, and higher physical security than the Enterprise’s requirements. The Colocation also demonstrated a desire to work with the Enterprise. Nonetheless, an outsourced provider introduces some management risk. (Indexed middle)


Key Determinant: None, due to thorough due diligence

Key Determinant: None, due to thorough due diligence

Compliance (Government Mandates, Corporate Policies, Compliance & Certifications to Industry Standards)

Due to a Property Risk competency readily available to the FORCSS Team Leader, compliance issues for each alternative were vetted prior to FORCSS exercise.

Alternative #1 – Refurbishment: Meets all requirements. (Indexed high)

Alternative #2 – Build: Meets all requirements. (Indexed high)

Alternative #3 – Colocation: Meets all requirements. (Indexed high)




Key Determinant: None

Key Determinant: None

Sustainability (Carbon and Water Impact, Green Compliance & Certifications, PUE Reporting)

The business need was composed of a mix of legacy hardware, with diverse infrastructure requirements. While adhering to industry best practices for efficiency, the Enterprise requires an energy-intensive operation regardless of the deployment alternative, (i.e., equipment had to be manufactured, construction undertaken). Also, the alternatives shared the same power provider, with no differentiation for source. The Enterprise purchases carbon offsets to meet corporate sustainability goals, and the LEED facility was noted in the exercise, but sustainability was not a major factor in this decision.

Alternative #1 – Refurbishment: Meets requirements. (Indexed middle)

Alternative #2 – Build: The site is a LEED Certified Facility. (Indexed highest)

Alternative #3 – Colocation: Meets requirements. (Indexed middle)


Key Determinant: None, due to thorough due diligence

Key Determinant: None, due to thorough due diligence

Service Quality (Application Availability, Application Performance, End-User Satisfaction)

Prior to the FORCSS process, the Enterprise vetted the network capabilities. All alternatives were in a close geographic area, without latency issues. And, deployment of an established suite of applications minimized concerns about End-User Satisfaction.

Alternative #1 – Refurbishment: Meets all requirements. (Indexed high)

Alternative #2 – Build: Meets all requirements. (Indexed high)

Alternative #3 – Colocation: Meets all requirements. (Indexed high)


Consolidated FORCSS Index

This display provides a view of the three deployment alternatives side-by-side. Notes within each indicator were withheld to offer a holistic, comparative view of the values.


Outcome: Based on this FORCSS exercise, the Build (Alternative #2) best met the business requirements.

Insight from FORCSS Leader
Our organization has historically tried to self-provision first. But, the doors have opened up. The IT departments aren’t holding onto hardware anymore, and the shorter time lines are having a huge impact on how we respond. You have to pick projects that you can do better, and you have to be ready to let go of things you can’t do fast enough. Most builds will take longer than buying the service.

 An IT organization isn’t linear anymore. There are multiple stakeholders who have different influences and different impacts on decisions. If you’re not thinking 3 to 5 years out, an enterprise organization won’t be to be able to respond to the business demand.

Quantifying the opportunity is a difficult, but important, aspect of the FORCSS process. One of the biggest considerations in this decision was the business synergy [providing business continuity infrastructure for an adjacent back-office function], documented in the Opportunity section. You have to be well connected across your organization or you will miss Opportunity. The IT department did not know or care about the back office getting power—they wanted a new computer room. But, the business side determined the continuity benefit was compelling.

financial2 #10

Figure 1. Generated by Enterprise and adjusted to remove sensitive information.

Vetting a multi-tenant data center provider required due diligence. We attended site tours to review infrastructure they had provisioned before. We had them provide single-lines of how the infrastructure would look. We got as close to apples-to-apples as we could get, down to cabinet layout of the room. We had three detailed meetings where my engineering and operations teams sat down with the colocation fulfillment team.

One of the biggest risks of an outsourcer is not about the immediate contract, but about how you deal with change going forward. How do you handle change, like a new business opportunity, that isn’t in the contracts? How do you deal with non-linear growth? We never got to the point of pulling the trigger, but had a frank discussion with our board about risk associated with outsourcing and they were comfortable with the alternative.

The Board ultimately funded the Build option. I believe that our FORCSS process was successful with decision makers due to the thoroughness of our preparation. Upper management questions were limited to site characteristics (such as industry best practices for physical security), but nothing that challenged any of our fundamentals.

For today’s enterprise, speed is key: speed of decision making; speed of deployment. In this environment, the decision-making methodology must be credible and consistent and timely. We adopted FORCSS because it was thorough, independent, and industry accepted.


Julian Kudrizki

Julian Kudrizki

Julian Kudritzki and Matt Stansberry wrote this article, which originally appeared in Volume 3 of The Uptime Institute Journal, May 2014.  Julian Kudritzki joined the Uptime Institute in 2004 and currently serves as Chief Operating Officer. He is responsible for the global proliferation of Uptime Institute Standards. He has supported the founding of Uptime Institute offices in numerous regions, including Brasil, Russia, and North Asia. He has collaborated on the development of numerous Uptime Institute publications, education programs, and unique initiatives such as Server Roundup and FORCSS. He is based in Seattle, WA.


Matt Stansbery

Matt Stansberry

Matt Stansberry is director of Content and Publications for the Uptime Institute and also serves as program director for the Uptime Institute Symposium, an annual spring event that brings together 1,500 stakeholders in enterprise IT, data center facilities, and corporate real estate to deal with the critical issues surrounding enterprise computing. He was formerly Editorial Director for Tech Target’s Data Center and Virtualization media group, and was managing editor of Today’s Facility Manager magazine. He has reported on the convergence of IT and Facilities for more than a decade.

Share this