Project Planning Methodology That Ascertains Orderly Performance & Timely Completion of a Data Center Projects.
Planning of a data center physical infrastructure project need not be a time consuming or frustrating task. Experience shows that if the right issues are resolved in the right order by the right people, vague requirements can be quickly translated into a detailed design.
This article outlines practical steps to be followed that can cut costs by simplifying and shortening the planning process while improving the quality of the plan.
The planning of projects to build or upgrade data centers remains a major challenge for many IT departments. Plans are often poorly communicated among the various business stakeholders within the organization. Decision makers may be presented with proposals that are described in excruciating technical detail, yet still appear to lack the information they need to make good business decisions. Seemingly small upfront changes in plans can have major cost consequences downstream when the data center enters the construction / build stage.
The planning and approval process can consume a significant part of the calendar time of a project, and it is common that unwelcome surprises or changes occur late in the planning process, causing planning rework that result in significant delay in project completion.
Our experience with many data center projects suggests that many of these problems can be avoided if the right decision makers are given the right information in the right sequence.
This structured planning methodology describes a sequence of steps to be taken and the key decisions that come out of each step.
By following this process and making the process visible to all stakeholders, project managers can improve the transparency of the process, make the stakeholders feel their time is more efficiently used, and improve the buy-in on the project.
The “Plan” phase is broken out as the four main tasks of the system planning sequence. The planning sequence described in this article establishes the design requirements for the detailed engineering design of the data center’s physical infrastructure, which powers, cools, houses, and protects the IT systems.
This planning sequence is separate from IT planning and assumes that another IT planning process is going on in parallel or has already taken place.
The system planning sequence.
The system planning sequence is the logical flow of thought, activity, and data that transforms the initial project idea into a compact set of requirements and documents that should control the performance and cost of the built data center.
The process flow contains some key ideas found to be an effective best-practice in data center planning and form the basis for the method described in this article.
These key ideas are:
Separation of system concept from detailed design: We have found that it is very efficient to choose a system concept before generating a detailed technical specification, working on detailed design, or debating long lists of user preferences or requests. Revelations regarding performance or cost that occur after detailed design has begun, may cause a change in the fundamental system concept and create large amounts of rework and schedule slip. The early parts of the design process need to focus exclusively on ensuring a shared understanding of the most important capabilities of the data center and its cost, and avoid investing in work on detailed design and specification. Deciding on a system concept involves high level decision makers determining high level objectives and making early trade-offs between performance, cost, size, location, and schedule for the data center involved in the project. This approach attempts to avoid the problem frequently encountered where key stakeholders are not aware of fundamental design characteristics or costs until detailed designs begin to emerge later in the process.
Separation of key project parameters from user preferences and constraints: There are small set of high-level key project parameters that are necessary and sufficient to support a choice of a system concept. Some of these key parameters include concepts such as density and growth plan that don’t historically have clearly defined and unambiguous methods for quantification. The early planning should focus on establishing a consensus on these parameters and postpone dealing with user preferences and most constraints, in order to efficiently reach an early decision on the system concept. This ensures that high level decision makers focus on the most important decisions early and do not get drawn into discussions of details.
Four Plan Task
1. Establish Project Parameters:
This task starts with the general idea of a business need that requires a change to the organization’s IT capability. From there, Task #1 involves determining the following six project parameters: criticality, capacity, growth plan, efficiency, density, and budget. The key stakeholders that should be involved at this stage include the finance executive, the CEO, a key IT executive, IT operations manager, and other individuals who understand the core business needs and objectives. The six project parameters set the high-level goals of the data center project, which are used later to develop the physical infrastructure system concept for the data center.
These key project parameters are defined as follows:
1. Criticality –Level of system availability to be achieved in terms of standard industry norms.
2. Capacity – Maximum IT load (in kW) that the data center physical infrastructure can support
3. Growth plan – Description of the ramp-up to the maximum power requirement, incorporating uncertainty (see White Paper 143, Data Center Projects: Growth Model)
4. Efficiency – Energy efficiency goal for the data center infrastructure systems.
5. Density – The average and peak power that IT cabinets are expected to consume (kW/rack) and the amount of floor space required (see White Paper 155, Calculating Total Space Requirements and Power Density for Data Centers) along with information regarding density uncertainty
6. Budget – The money planned for the capital costs of the project Many planning failures, throw-away design work, and schedule slips are traceable to:
1. Failure of the stakeholders to have a shared understanding and agreement about these key parameters early in the process
2. Stakeholders were not fully aware of the trade-offs between these parameters
3. Stakeholders were not fully informed about how the design was going to perform against these parameters until after detailed design is underway or even completed, when it may be too costly to make corrections. An important goal of this task is to assure that scarce executive time is applied to the most important decisions
2. Develop System Concept:
This task takes the foundational project parameters from the previous task – criticality, capacity, growth plan, efficiency, density, and budget – and uses them to choose a general concept of the physical infrastructure system. The key stakeholders involved at this stage should include IT operations, the IT executive, facilities executives, facility engineer, and a consultant with experience in system planning for data center projects. The cornerstone of this task is the selection of a reference design, which embodies the desired criticality, capacity, efficiency, density, and budget and has a scalability that will support the growth plan. In addition, it is important by the end of this step to have decided upon the specific site (room, building, or site) for the data center.
3. Incorporate User Preference and Constraint
User preferences and constraints include technical design requirements that are not included in the key project parameters and not explicit in the system concept or location choice. Given the choice of system concept from the earlier task, this task collects and evaluates user preferences and constraints to determine whether they are valid, or should be adjusted in some way to reduce cost or avoid problems. The central idea here is that the user preferences and constraints should be adapted so that they work with the system concept already chosen.
It is our experience that it is much more efficient to validate and adapt the user preferences and constraints after the design concept is chosen, rather than collecting these as requirements up front and attempting to use them to drive the overall design. It is the user preferences and constraints that often unwittingly drive data center designs away from standard designs and drive up cost, drive up deployment time, and reduce quality.
The key contributors involved at this stage should include IT operations, network engineers, facilities engineers, other personnel dealing with the day-to-day data center activities, and a consultant with experience in system planning for data center projects.
User preferences and constraints are defined as follows:
- Preferences are the desires of the users that are subject to change or adjustment after consideration (or reconsideration) of cost and consequences. User preferences sometimes change when the users are presented with new information.
- Constraints are obstacles that cannot be overcome, or can only be changed at great expense or with unacceptable consequences. Constraints are pre-existing conditions that are difficult or impossible to change. Preferences are characteristics that are viewed as desirable by the operators or organizations based on their goals or their experience, but are not constraints. Examples of user preferences include the following:
- We prefer overhead power cabling
- We need visitors to be able to see the data center on site tours
- We want security cameras to see every inch of the data center space
- We don’t ever want to need to do electrical wiring or plumbing in the IT room after it is turned on.
- We prefer wide IT racks to provide more cable space
- We want to physically separate the IT cabinets by IT customer
- We want a display on the wall showing the energy performance summary of the data center
Once these are validated, the user preferences and constraints are reviewed for compatibility with the selected system concept. Where they are found compatible they are passed on to become part of the design requirements. Where a validated preference or constraint is incompatible with the design concept, then reconciliation is attempted by making adjustments to either the preference or constraint, or by appending small change requirements to the system concept.
The goal here is to make concept adaptations to avoid the need to return to reconsideration of the system concept unless absolutely necessary.
4. Determine Implementations Requirement:
Collect standards, codes, deadlines, resource assignments, and process requirements the project must conform to. The implementation requirements serve as a set of rules to be followed when creating a detailed system design, above and beyond the outputs established in the previous 3 tasks.
The implementation requirements consist of the following elements:
· Standard requirements: that does not vary from project to project. Standard requirements generally appear in the form of standard specifications that comprise the major portion of the data center specification. Examples of standard requirements are any special regulatory compliance standards, compatibility of subsystems, safety, or best practices that need to be made explicit to engineers or installers
· Project requirements: that defines the user-specific details regarding execution of the project. These include special deadlines, human or equipment resource assignments or limitations, vendors that must be used, or special procurement or other administrative processes that the project must adhere to.
The implementation requirements, when combined with the outputs established in the prior three tasks, together become the complete design requirements and serve as a “rulebook” for the detailed design engineered in the subsequent design phase. In the later design phase, the design requirements established by the planning process guides the systems and project engineering. It is in this later design step that the engineering specifications are developed and this may include:
1. Detailed component lists
2. Exact floor plan of racks, including power and cooling equipment
3. Detailed installation instructions
4. Detailed project schedule
5. Actual “as built” characteristics of the design (efficiency, density, and expandability)
Conclusion
Despite its crucial importance to the success of the project, system planning has historically been considered difficult, carried out as art rather than science, with opportunities for missteps, wrong assumptions, and miscommunication that can have serious consequences in later phases of the project. This phase often takes much longer than anticipated or required. Much of the difficulty can be removed by viewing system planning as a standardized process, consisting of an orderly sequence of tasks that progressively develop and refine the system concept, to ensure that the final system fulfills the original business need.