The Deployment Journey: Learning from the Past to Shape the Future

We learned about project management and change management at enterprise scale. We learned about conversion for very large systems. And we learned that customizing systems to meet our needs led to disastrous long-term costs, locked us into decades-old decisions, and prevented business innovation.

The experiences from those years inform the work we do today in this area and the kinds of systems we are choosing to implement. Institutional adaptation has taken the place of system customization. Continued vendor innovation has taken the place of bolt-on development. And with all this change, our deployment techniques must adapt. They are not completely different than the implementation and upgrade skills we honed for the last two decades, but these platforms do require significant rethinking of the deployment process.

Most importantly, fit-gap, design, and development are now replaced by iterative configuration and process design, using delivered process models as a starting place. The assumption that we would mold the software to our processes has been replaced by the assumptions that the business process delivered by the software is the right place to start and that our processes will continue to change over time as we and the software vendor innovate. We also recognize the incredible value of the shift from major upgrade projects in order to innovate to regular, incremental updates from the software provider that require little or no effort on our part.

In recognizing (and having lived through) these new methods and assumptions, Tambellini is helping institutions think about deployment with a series of guides and vendor research to assist in the journey to the cloud.

After software selection and before your implementation partner lands in your institution, there are many preparatory steps to complete. Setting up your governance, beginning your change management journey (which began when you had your first cloud demonstrations), and ensuring your business and technical house are in order are critical to a successful deployment. The following items are part of a critical checklist that should be completed.

• Change management team leadership and methodology
• Institutional project governance, supportive and actively engaged
• Business priorities (e.g., service design, business imperatives, policies to be reviewed)
• Application inventory with initial targets for systems to be decommissioned
• Integration inventory, strategy, and team leadership
• Report inventory, indicating critical reports

This is just a sampling of the types of preparation required for a great project start.

The deployment itself will look different as well. It begins with a planning phase in which all the detailed plans are created with your implementation partner, moves to a design and configuration phase, then closes out with more traditional testing, go-live, and stabilization phases.

One of the overriding differences is the level of business involvement in each phase of the process. Without a technical design and development process for core business process implementation, tech-savvy business analysts can perform most of the configuration work on cloud systems. This allows for a much tighter link to the business areas that are responsible for the processes and business functions. And beginning with an existing, production-ready platform makes for a quick start and drives the length of the feedback loop of idea to configured system from weeks to hours.

These differences lead to the need for new skills and competencies in your project team. There will still be significant work for technical staff in integration, conversion, and typically in their strength of project management and facilitation. All these changes can lead to a much tighter partnership between business and technical staff if planned correctly.

The post-production world should also be considered and addressed early in the project. There will be significant changes in skills required and roles to be played by IT and business staff after the systems are successfully implemented. Modeling the post-production budget is also important, as cloud cost structures are very different.

As a deployment is planned out, it is critical to consider the differences from previous types of deployments, but to also incorporate all the learnings from previous experiences.