Joint Blog Post – Scott Thomas/Hector Perez Jr
Sales and Marketing as a function is charged with maintaining and growing a company’s brand and ultimately, its revenue. Due to the unpredictable nature of consumer and business behavior, these functions have typically required more flexibility than historically more structured IT functions. However, now that sales and marketing rely ever increasingly on software and technology to get their job done (Salesforce.com, Eloqua, Analytics, etc), they need to increasingly come to terms with incorporating more structure in to some of their operations and processes. Namely, instead of barking one-off requests to IT (or waiting a full year for IT funding to get a feature request incorporated in to the IT roadmap), sales and marketing increasingly need to incorporate ‘some’ of the IT methodologies from the past. Namely, something that is called release management.
When implementing technologies, such as marketing automation systems like Eloqua or Marketo, we have worked with marketing groups and departments to introduce release management methodologies for customizing and implementing software. The typically creative marketing teams are usually not devoid of ideas, which while good for generating marketing campaigns, that culture can wreak havoc on building out a stable software ‘stack’. Despite reports to the contrary, software customization and development still does not operate at the speed of thought.
To get to a place that satisfies sales and marketing but does not create software and IT chaos, release management is introduced to allow for ideas and requests to come rapid fire from sales and marketing but enables the IT/agency/software side of the house build out a stable, scalable and extensible software stack that can grow as your business grows. We have found implementing a monthly release schedule as it relates to marketing automation and other marketing automation allows marketing and sales to remain relatively agile while at the same time enabling IT/software/agency partners some time to plan out the build/customization of software platforms such as Eloqua. One client is on release 3.1 of their marketing technology stack and has actually ‘slowed’ their rapid release cycles to accommodate the now numerous pieces of their technology stack (and allowed them to plan on their end how their sales and marketing processes might impact their technology stack). As marketing and sales further leverage software for business, they will begin to take ownership for the technology stack themselves from IT. So much so, that in fact, Gartner analyst Laura McLellan recently predicted that by 2017, CMOs will spend more on IT than their counterpart CIOs.
Scott Thomas – President at Intelechy Group
When discussing marketing automation release management from an IT perspective, the conversation has evolved from years past. Many companies legacy IT systems typically introduce change (updates, bug fixes ect) once, twice or maybe three times a year. However with the advent of cloud applications the paradigm shifted both on the business and technology side to introduce change at a faster pace to help drive innovation. How does Salesforce or other cloud based tools allow for the business to innovate and IT still have control over key features such as security, integration and ensuring the stability of the application? The answer is easy, but this needs to be clearly thought out and agreed to on all sides (business and IT). In the end it does not matter who has ‘ownership’ of the tool (although business does move quicker with change when they own it), what matter is a solid governance process in place which allows for collaboration and clear communication for change in your cloud tools.
So how is this actually done? Its a matter of getting your teams (IT, the business ect) on board and educating them with the “Hybrid” release management methodology. Think of it as a mix between Agile and Waterfall methodologies, with an additional method added which allow your business to move much quicker in adopting change. Here is the breakdown of how it works for what I call the “Hybrid Release Management for Cloud Applications” and can be applied to marketing automation release management for your company.
Major Releases
There are three parallel release paths to this Hybrid method and the first path I call “Major Releases”. The key components of a ‘Major Release’ are strategic/transformational programs, which typically have a lot of custom code, integration with other legacy systems and need complete end to end testing. This release path is what most large enterprise companies do now and are typically are done through a Waterfall project methodology. Release frequency can be 1-4 times a year depending on your release calendar and is always owned by IT as indicated below.
Minor Releases
The second release path for this hybrid model is called a ‘Minor Release’. As the name would indicate this release type focuses on small changes, which can have big impacts to your business. These are always done with an Agile project methodology and you can have up to 8 releases a year (as you can see below). Major complex changes should NOT be a part of this release path and testing is still required for the changes to the system. Ownership of these changes can be either IT or the business, however if the business does take ownership of this release path, ensure you have certified, knowledgeable operations personal doing the changes. If you don’t have the right resources staffed on this release path executing the change and the time is not taken to train and certify your team, the risks for this process to fail are high.
Quick Hits
The last release path is something I used at my previous employer and we called it ‘Quick Hits’. As the name indicates these changes are quick, no testing required and can be turned around in 2-5 days. You can make these changes as quickly as five minutes, but you want to have some service level agreement (SLA) with your end users as to ensure you get are making the changes in the time agreed to by everyone. No testing is required for this release path and there is a clearly defined list of changes that can be accommodated. One of the more critical aspects of this release path (and I alluded to earlier) is to ensure all users understand what falls under a “Quick Hit” and what does not and has to be accommodated in a minor or major release. A few examples from the Salesforce side are below.
Hector Perez Jr.
