On the Managed Services team here at Simplus, we often say that deployments are the currency we use to measure success. You might be asking yourself though, what does “deployments” really mean? And how can they measure success? To answer that, you’ll need some context.

In somewhat simple English: deployments are ongoing developments to an enterprise application that is pushed live to a production environment. This might be a break and fix instance, changes to the application, or updates and enhancements. Deployments can also be understood as what they are not: the big go-lives that typically punctuate the end of a big implementation.

In even simpler English: deployments are the consistent, ongoing changes that we push to end users to help them do their job better.

Either way, stated somewhat simply or very simply, deployments are of utmost importance—they help your organization grow. So when it comes to deployment success, we don’t kid around. There are two concepts we use to define that success: consistency and quality. You have to have both in your deployments to truly succeed, so in this blog post, we’re diving into it all.

Capitalizing on consistency

Imagine a company with 15 sales reps. Each rep, over a period of three months, has requested two changes they would like to see in Salesforce to make their job easier. So, do some math, and in one quarter we have 30 different items to work on. There are now two choices for the deployment team:

OPTION A: Work on all of them at once, over a long period of time (let’s estimate two quarters). After building it all, testing it all, and making adjustments based on end user feedback, then the team deploys them all at once. That’s six months that your end users are not having their productivity increased through the technology they use. Also, in the meantime, they have put another 30 more requests in the queue to be built. This scenario reeks and oozes of frustration.

OPTION B: The 30 requests are prioritized and grouped together based on functional similarities. A release schedule is created to plan for several deployments over the course of six months.  Based on the ease of build and priority, we’ve concluded we can deploy a new functionality every two weeks. This is a much more desirable situation.

Option B is clearly the right choice. And it’s the right choice for many reasons, not the least of which are two very important impressions it creates: first, it shows that the deployment team has contributed to the bottom line of the company at a quicker pace. End users who do their job better or faster are either saving the company money or bringing in more revenue. Second, it demonstrates to end users that you get things done, and you get them done quickly. This leads to better relationships with your end users over time as they realize they can trust you with their needs.

You can download a Simplus release schedule template here.

If you can get a consistent release cadence going, you’re well on your way. The next step is to make sure each release is a top-notch, quality release.

Cultivating continuous quality

Deployment quality is all about minimizing disruption to your end users’ day-to-day processes.  This means combatting two forms of disruption: introduced changes and introduced defects.

Introduced changes: Deployments have the risk of introducing changes to your production environment at the same time someone is using Salesforce. To address this, we often advocate after hours or weekend deployments, especially for major deployments.  

Introduced defects: These are the much more critical disruption risk deployments carry. This is where changing one thing in the system unexpectedly leads to breaking something else in the system. In a future post, we’ll cover deployment automation and testing best practices in more detail, but for now, the best thing you can do to minimize introduced defects is to stick to your newly acquired deployment schedule. It’s always best to follow a “better to push than rush” mindset.  

It can be hard to accept deployment delays, especially after all the work put into it and with the pressure mounting from end users. But if the end user hasn’t had a chance to truly see if a deployment meets their needs then that change needs to be pushed to the next deployment on your calendar. It’s a simple concept, but one that’s difficult to adhere to because of the pressure coming from your end users. They might not know it, but a delay in a deployment is better than breaking the system your end users rely on.  

Sure, it’s one thing to merely have deployments for your enterprise application. But making sure those deployments are consistent and high-quality is what puts you above the rest. Realizing an effective release cadence and addressing disruptions to the end users are the principles quietly pushing a deployment to its ultimate success for your organization.