Server Migrations are complex operations that often encompass interdependencies across systems, applications, data repositories, networks and security. Establishing baseline configuration controls (ideally leveraging a CMDB platform) at the start of a migration project can mitigate risks when changes in design and scope [naturally] occur throughout such projects.
Server Builds – RACI 101
All (responsible, accountable, consulted, informed) stakeholders and contributors must initially define workflow process structures needed to record, monitor and communicate product-build progress. Dependencies associated with server builds are time-sensitive and the ability to effectively communicate across all stakeholders when changes in schedules and scope occur is mission critical to ensuring a successful and on-time event.
Build Tracking & RAID (risks, assumptions, issues and dependencies)
A Build Tracking document is used primarily by the Project Management team to ensure workflow processes, milestones and dependencies are communicated and tracked effectively. This, along with a RAID log, provide the means to record all requests, and identify proactively any risks and impacts to the overall migration plan, SLAs and measurable metrics.
A tracking document is dependent on the quality of its consolidated sources, and an agreed-upon communication plan for receiving any new requests.
It is essential that the Build Tracker and RAID log are established prior to submittal of build requests. When tracking is not initiated at the beginning of the build request process (refer to New Server Request Path flow diagram), a cascading effect on forecasting and establishing a baseline for a T-Minus approach to milestones occurs.
Sources used for initial and ongoing input to the Build Tracker must be defined up front (at the time the Build Tracker is structured) to ensure consistency and the highest quality and accuracy. Without this several issues will occur, such as but not limited to:
- Time wasted interpreting disparate, inconsistent sources needed to populate and maintain tracker.
- Potential gaps in information, which will need follow-up.
- Inaccurate information placed in the tracker.
- Inability to share and communicate information received effectively.
As a project progresses, useful and accurate status throughout the [T-Minus] stages must be communicated to enable all stakeholders, contributors and decision makers to identify potential risks and determine remediation actions and future mitigation proactively.
The fundamental purpose of an effective tracker is to identify potential risks well in advance of a migration event.
Single Source of Truth
Ideally the Server Design Reference (SDR) or Technical Solution Document (TSD) should be held as the single source of truth. Once the contents of the SDR have been agreed-upon by all parties, any change to the SDR would require a formal Change Request (CR) which must pass thru a peer review (by all stakeholders and contributors) before being finalized and agreed-upon, at which time signed or dated confirmations are published and attached to the CR within the CMDB and ServiceNow (SNOW) ticketing system. The workplans associated with scheduling and implementing the change(s) must then be established and followed.
Without a formal CR process for your SDR, related information and interdependencies (CMDB, as-built configuration details, physical and logical diagrams, etc.) may reflect inaccurate information, making it far more difficult to operate, maintain and troubleshoot.
Given the SDR updates may lag behind CR’s, the Build Tracker is relied upon, thus updated in near-real-time daily by the PMO team as each change request, build request and build sheet are communicated across the teams and ticketing systems. The Build Tracker is used to audit the SDR and help identify any discrepancies. NOTE: The SDR is the single source of truth with regard to design and a broad range of design topics whereas the Build Tracker is focused on physical build requests and physical & logical configurations as they progress along the T-Minus schedule.
If a formal CR process is not defined, the Build Tracker, by a daily due diligence process of build and event management and oversight, becomes the default source of truth due to managing the expectations of what has been requested and what is being built. If there is a discrepancy between those two events it will present itself within the tracker.
The difficulty from the project team perspective is without a formal CR process held on the SDR, the original design architects that both contributed to the original SDR and related change requests will be called upon throughout the project life cycle to revisit and explain the discrepancies.
Migration Timeline Management
As noted the key strength of the Build Tracker is to identify issues prior to them affecting the migration schedule. To do this each migration needs to have a formal agreement on expectation of delivery, with lead times for each step in the process clearly defined and agreed-upon by all parties.
Each individual work flow step is measured against the T-Minus prior to the T-Minus event. Any expected delay to any workflow stage is communicated, as a domino effect forcing slippage of milestones is the net result if expanded remediation actions and tasks aren’t established to correct the slippage.
Imagine a 1500M baton race with runners staggered at different intervals due to being in different lanes. Each staggered runner could represent a migration event, the innermost lane is the first scheduled migration with the outer lane runner being the furthest runner, being the last migration. As each runner passes the baton in the race, the partners’ runner needs to be reaching full speed as the handoff of the baton takes place. This is the equivalent of each team and work function operating during the migration. It is the Build Tracker responsibility to communicate the timing of this “baton handoff” so that all parties have all the materials they need and are running at full speed throughout the migration. This is complicated further due to different runners’ teams being needed at different intervals along the race. This results in overlaps requiring additional resources or else the completion time/milestone will indeed slip.
Metrics and Reconciliation
Due to the Build Tracker being an event management readiness tool with regard to systems and devices, it can be used to provide independent metrics which can be used as a means of process improvement. When held against a T-Minus schedule, any loss in “handoff’ will be recorded. The reason for late or early delivery of required materials for each migration shall be noted within the tracker.
Management can use the Metrics produced from the tracker to isolate any trouble areas within the migration process and plan appropriately to resolve.
At the start and end of each migration a reconciliation task should occur across the Build Tracker and SDR/TSD vs. and what has been migrated. This reconciliation task assists in presenting any prior lost build requests for drop-in delivery requests which can then immediately be pursued by all parties.
The Build Tracking tool, if maintained and utilized efficiently, can become far more than a projected timeline management tool. It can remove key stakeholders away from unnecessary time-consuming activities, can become a default source of truth document and has the ability to provide both metrics and reconciliation details to provide a useful story behind any unexpected delays.
The Build Tracking tool is a necessary project management tool to adequately track what is being requested. Developed further with a T-Minus schedule to predict if the necessary resources will arrive on time and raise alarms early if there is a subject delay. In projects where there is no formal CR process defined by the SDR, the Build Tracker is the only opportune point in the process flow to provide a means of truth for the project team. This is invaluable. Alongside its reconciliation abilities, the Build Tracker becomes the single source of truth. (Ref.1 – below)