System Development Lifecycles (SDLCs) have been used as roadmaps for successful IT implementations since the start of the computer age. Given the computer age started around the same time dinosaurs stopped roaming the earth, it’s still surprising to find gaps that create significant headaches when transitioning a system from build to run. Project Teams have learned the hard way that communications, training, and reporting are critical. That way, end users know how to use the system. Success! Right?
Unfortunately, no. The success is incomplete because the transition from build to run is often glossed over, creating longer term support issues that can impact the business. Systems will inevitably crash during critical business cycles or will run so slowly that employees cannot perform day-to-day activities.
Three simple items need to be addressed as part of the SDLC to ensure a seamless transition from build to run (or at least as seamless as any IT handoff can be). The Project Team needs to work with support during the build phase to address:
Nothing is more frustrating than implementing a new system, handing it to support, and finding out no staff are available to take on the required run activities. We suggest after the design phase and during the develop phase, the Project Team should start working with support to ensure the system will be properly maintained. The Support Team needs to clearly understand the impact on the organization, processes, and budget when the new system is transitioned to run.
An easy way to do this is to perform a series of workshops to communicate the future state vision (why the system is being implemented), develop or refine support processes, and create a RACI. These can be used to determine required organizational impacts and drive the support budget.
The Asset Management Team is in a constant battle to maintain the Configuration Management Database (CMDB) used to track what is owned by the company. This information is critical to managing software licenses, entitlements, and hardware. In many organizations, teams are surprised when their discovery process reveals new assets on the network that shouldn’t be there. The team scrambles to determine if these assets are valid, who owns them, what software has been added, what the lifespan is, etc. This takes significant time that should be more focused on supporting critical run activities including cybersecurity and portfolio management.
The Project Team needs to work with the Asset Management Team in conjunction with the Support Team to ensure system owners understand their responsibilities for keeping the CMBD up to date and complete. The new system should be discoverable, service maps need to be created, and entitlement information should be clearly captured. This is the only way the Asset Management Team can properly manage and secure the portfolio. Improperly managed entitlements alone can cost millions of dollars per year and keeping systems running when they are no longer needed costs even more. Worse? Responding to cyber events will be severely impacted if IT does not know the systems owned by the company.
Sharing monitoring requirements is the most often overlooked step in any SDLC. Most project teams believe the existing monitoring systems will easily adapt the new system and let support know when the system is up or down. Monitoring is much more than that.
During the develop phase, the Project Team must work with the Monitoring Team to determine what should be monitored and what should be done if key parameters are not met. This is important for critical, customer-facing systems. If these systems are not performing well or are down completely, customers are negatively impacted, and the company can lose money. The Project and Monitoring Teams can work together to identify parameters (CPU use, memory use, disk speed, network latency, etc.) that give advance warning for a possible problem. These can be assigned priorities which drive support SLAs. This enables the Support Team to proactively address issues before they become problems.
