“It will be deployed overnight tonight so just log in and everything should be good in the morning. You might need to refresh some stations of it doesn’t look like it worked.”
Too often, this is the extent of involvement in the deployment process for the retailer. This level of trust in the software support team is great, but as I’ve harped to so many clients before — software development is a process of working through assumptions and deployments to production are where those assumptions sink or swim. Whether fixing critical bugs quickly as they occur or building up bug fixes and new functionality for batched release, retailers can and should be involved in the deployment process for each update.
Now, this doesn’t mean retailers should be staying up all night to participate in every deployment or have a detailed technical understanding of the solution. However, the retailer representative (usually Owner, General Manager, or a specialized position) is the domain expert on the business. If the team member who is the expert on the business does not have a basic understanding of some core components of the deployment, then the deployment takes on a variety of unnecessary risks.
Here are 4 questions to ask to ensure that the deployment is prepped for success and that the business is ready and willing to accept the deployment.
1. What is being changed?
This might sound obvious. “Of course we already know what’s being changed, that’s the whole point of the deployment – to get the thing we asked for!” However, there are two important considerations:
First – that the piece being deployed meets your expectations. Demonstrations or a walk-through explanation help to ensure that you both the development team and the business users have the same definition of “Ready”.
Second – that nothing else is being changed in order to achieve the request. This helps to identify unexpected behaviour or changes that were not specified in the requirements.
2. What are the risks?
Once you understand what’s being done, you should be able to achieve at least a basic understanding of the areas that may be affected, how they might be affected, and the likelihood of the impact. Between the business representative and the support team, you should be able to identify what risks may present themselves. Will this change affect existing users? Will there be slowdowns? A period of time where the system is down?
An understanding of the risks will help you prioritize them and determine the value of the deployment. Is the functionality being delivered worth the expected risk? Perhaps some additions, changes or a new deployment approach will help lower the risk (ex: switch to an overnight deployment).
3. How was this tested?
The answer to this question will probably also inform the previous identification of risks. If the change and deployment was tested on a local machine running an out-of-box copy of the software then expect a significantly higher level of risk that the functionality will not behave as expected or that there will be complications, when compared to that which was tested on a mirror copy of your production environment and using an established, detailed test plan.
4. What is the rollback plan?
First: if something goes wrong, how do we fix it? Do we have documented, or at least understood, series of steps for resolving issues? Are we able to roll back to a backup version of production if things go wrong, or are we stuck with this version once we deploy it? (Again, update your risk assessment).
Second: How do we define “something going wrong”? What are the critical issues? What are issues that we can live with and should not stop a deployment? If in a deployment we know exactly how to solve a specific problem but the solution will take until 9am and we have identified a hard completion time of 8am (store opening) then we will all understand that we need to find a better solution or roll back. This is also a great example of why a rollback plan should include who to call if a difficult decision needs to be made midway through (who is on call for the retailer?)
Give a few minutes to these considerations before your next deployment and discover the depth of knowledge you can gain from exploring these 4 simple questions with your POS software support. Even better, the discussions you gain from these questions will help you create better standards and shared expectations, leading to more cohesion in future deployments.
Jaeger Consulting Group specializes in end-to-end needs assessments and implementation plans for IT systems – starting with analysis and design through to the deployment and training – in order to meet and exceed client goals.