Every development implements a transformation, whether a small change in functionality or a major business change. Usually, it is about replacing something we currently have or use by something better or getting something, we have not had before. A very human and understandable attitude is to resist change or to have too high expectations for change.
Deployment and training is essential in all transformations as it plays a key role in the adoption of the new capability, product or service being deployed. It is critical that people adapt and change in line with the deployment, and that acceptance of change does not become a bottleneck for the deployment.
Business impact
The business impactof any transformation must be identified and understood as early as possible in the request stage. In identifying the impacts, the following aspects must be considered:
- Scope of the transformation (geography, departments, users, etc.)
- Capability creation or updates, including ecosystem, people, processes, solutions, assets and data
- Processes, services and assets that need to be retired
- Integrations that need to be created and managed
- Skills and roles that are needed for the deployment period
- Assets that needs to be set up (data, licences, hardware, utilities, etc.)
- Regulations and legal aspects that needs to be respected
- Risks that must be mitigated and managed
- Costs and financial impact to the business.
As the business impact is often considerable and deployment usually takes a lot of time, money and effort, it is preferable to run the deployment phase as a project of its own with project plan, business case and gate approval practices.
Deployment and training components
The deployment and training phase activities vary depending on the selected development methodology:
- Incremental development is continuously delivering new releases and therefore the deployment and training is a continual activity. The training efforts should be in line with the business impact of the change. However, incremental development may also deploy major releases with a much larger business impact and deployment effort requiring deployment to be organised as a sequential initiative
- Sequential development, the training and deployment starts when the solution is tested and approved for deployment in User Acceptance Test (UAT) phase. The product, solution or service should not be released without suitable UAT and signoff. The deployment itself can be done as big-bang, phased or modular roll-outs.
The deployment and training phaseconsists of the following sequence of activities:
Figure 5.4.1 Deployment and training phase components
- Training: Users need to be trained to use the new product, solution or service and all the available features that help realise the anticipated business benefits. Training and support documentation must be made available and easily accessible to everyone. Support teams may need additional technical training to handle the related incidents in addition to learning the new processes introduced by the system or service
- Go-live: The moment when product, solution or service is released, and users are asked to use it instead of the retiring solution. Go-live requires careful planning especially when the new solution is replacing extensively used existing solutions. Therefore, the go-live planning is in many cases a major activity by itself with extensive minute-by-minute action plan with rollback and recovery options
- Intensive care: Intensive care period starts just before the go-live and lasts few weeks after to tackle peeks in support requests and enable fast handling of issues. Intensive care is provided by the development and operations teams
- Pilot: The solution can be tried out with a set of defined users before the actual deployment in order to prove the value, function and feasibility of the new solution. The deployment is done within a limited scope and tested by real users, often in real use in their day-to-day work. A pilot will lower the risks for the final deployment as it often highlights the test cases that have not been considered during UAT
- Feedback and updates: End-user feedback is consolidated and reported back to the deployment, development and service teams for consideration, response and potential updates
- Roll-out: The new product, solution or service is made available to the targeted audience. Different roll-out strategies can be applied depending on the situation. The selection of the right approach should be done based on the target organisation’s ability to adopt change and the impact of change on the organisation:
- Phased roll-out: the solution is progressively made available to the users, starting with a specific user category, and then moving on to subsequent categories according to an agreed schedule
- Module-based roll-out: a module of the solution containing a subset of features is deployed to all users. Once achieved, another module is deployed, until all modules have been deployed
- Big-bang: the solution is fully deployed to all users.
Figure 5.4.2 Roll-out strategies
Project handover and completion
For sequential development, the project is closed after successful rollout and handover. Handover means transition of operational and development responsibilities from the project organisation to the business technology line organisations. The project owner and project manager hand over the responsibility to the service owner, including an extensive knowledge transfer. Development responsibility is handed over to the development team led by a DEV lead or solution lead. The operational responsibility is equally handed over to the OPS lead.
In some cases, instead of persons-to-persons handovers, it would be better if handovers occurred between roles. For example, if a line organisation person also has a role in the project organisation, the handover would happen in between the two roles of the same person and not in between different persons. However, the approach of “having two hats” is seldom optimal in the implementation phase of the project as both roles require more than 50% allocation of the person’s resources.
The project completion includes an evaluation and project closedown report (sometimes called the transition-into-service report) detailing how well the targets were met, approval of agreed deliverables, and documentation of any further development ideas and unresolved issues. Deliverables and post-project service responsibilities and warranty periods are recorded in the service handover documentation.
In incremental development, the process is continuous until there is a need for selecting a sequential approach for implementing a large or major change.
In addition to preparing the programme closedown report, it is important to conduct a feedback survey across stakeholder groups as well as document the lessons learned and experiences gained during the project.
Service Release Automation
A key factor of successful deployment is the organisation’s ability to automate the service release of new products, solutions and services. Automated service release can make deployment more efficient and reduce the risks associated with manual service releases, while enabling roll-back to a last-known good state in case there are problems with the release.
Automated service release fit particularly well with incremental development, where there are new releases daily or weekly. The automated service release has for example the following benefits:
- Release configurations are made once
- Release can be done when needed
- Chances of manual errors are reduced
- Feedback is collected immediately.
Governance
The governance in a deployment phase is linked to the business impact size: the larger the impact, the stronger governance is needed. All service releases, excluding standard changes, go through a Change Advisory Board(CAB). In addition, larger service releases require approval from a service or product owner or from the steering group. Automated service release procedure, once reviewed and approved, does not require CAB review for each release.
The governance structure is also reliant on the type of selected development approach:
- A sequential development with large business impact will require strong steering at the end of the project to take decision on the deployment. From a risk perspective, a lot of risks are pushed to the end of the project and therefore the project steering group and portfolio steering group decisions are required
- An incremental development approach will break down a large business impact into smaller risks, requiring continuous deployment and training stream during the entire length of the project. However, a major release with large business impact require value stream steering group’s approval.
Figure 5.4.3 User involvement during development and deployment
