Getting SaaS-y on Release Management: HR Heads to the Cloud

RSS
Twitter

LinkedIn

YouTube

Facebook

Email

 Software as a Service (SaaS) as a delivery method is a strategic driver for 41 percent of organizations implementing new HCM software this year[1], according to my research on buying and implementing new human capital management software.  This is significant because we are not just talking about “okay, that software comes in the Cloud,” we are talking about companies looking at their technology strategy and determining that future HCM software choices would indeed be SaaS-delivered.  This is following a market trend that sees the amount spent on cloud technology reaching as much as $14 billion by the end of 2014.)[2]

One of the beauties of SaaS applications is that new upgrades and functionality are often accessible over the web. Unlike their on-premise predecessors, these applications support rapid deployment and redeployment of new functionality—ranging between two and five new releases annually (some providers have continual rolling updates, so new fixes and features can appear almost weekly).

However, this key attribute of the SaaS delivery method—rapid access to continual new developments—can present a conundrum for HR implementing SaaS software in their departments. Let’s look at some points to consider:

  1. Many corporations have stringent rules for stress testing all new code to mitigate the risk of it breaking something in their production systems. These companies previously faced a new release of their on-premise products every 18 months or longer, and then often elected not to move from the installed release to the newer one. The rapid release schedule of SaaS-delivered updates creates a radically different upgrade environment.
  2. Planning for any SaaS implementation requires planning for these repeated SaaS releases. Whether it’s the team that oversaw the initial implementation or another team that draws participants from the HR functional areas when new features affect those areas, there has to be a plan for that reiterative implementation.
  3. Because the SaaS solution provider has multiple releases a year, the contents of each release should be reviewed carefully. There are likely to be features that you will be required to take, fixes to previous bugs in the system you will want to take, features desired for immediate deployment once issues in compatibility are ascertained, and features you may want to deploy later. In addition, it is conceivable that a particular organization may decide not to deploy a specific feature, as its use conflicts with the way in which the company manages some business process.
  4. Testing new releases prior to “turning them on live” is an imperative in any software deployment. Scenarios and test scripts are used to simulate the real production environment. Generally, a mirror of the production system with the new changes is run in a “sandbox” to determine that integrations still work, components of the applications remain compatible, performance is as expected, and the entire system works as expected.
  5. Recordkeeping is required to track all changes made—what was added or changed, when, where (across the enterprise or in one division, for example), why, and by whom. This has to be documented; institutional memory is inadequate.
  6. As with an initial implementation, there may be changes in the look and feel, navigation, or functionality that pervade in a new release. Users of that particular functionality or who may be affected by the changes need both forewarning that a change is about to occur and training, if required, on the use of the new features.

HR, likely with the assistance of IT, will benefit by identifying a consistent process by which to manage the frequent releases of SaaS upgrades to aid in quality control and to help in deploying applications consistently across the enterprise. Such a process can also alleviate the errors and integration missteps that can occur with software upgrades. The rationale for this planning and documentation is not only the ongoing maintenance and management of the system, but it can also serve as a focal point for continuous improvement—capitalizing on the investment in the new software for the organization.

 

For more information and checklists on this subject, please see “Managing SaaS Applications Long Term: Release Management in the Cloud,” which published in June of this year.[3]


[1] Managing SaaS Applications Long Term: Release Management in the Cloud,” Katherine Jones. Bersin by Deloitte. June, 2014.

[2]  “US Business Spending by Size of Business and Vertical, 2009-2014: Cloud Computing and Managed Hosting Services,” In-Stat, 2010.

[3]Managing SaaS Applications Long Term: Release Management in the Cloud,” Katherine Jones. Bersin by Deloitte. June, 2014.

Christa Degnan Manning

Vice President, Solution Provider Research Leader / Bersin, Deloitte Consulting LLP

Christa leads technology and service provider research for Bersin, Deloitte Consulting LLP. In this role, she helps businesses align their workforce support strategies with appropriate third-party software developers, service partners, and governance models. A 25-year technology industry veteran, Christa’s expertise assists organizations in creating functional capabilities and employee experiences that increase productivity, engagement, and workforce efficiency. Frequently cited by business and trade media, she has presented market research on business to business trends, leading practices, and expected challenges and benefits at industry and user conferences globally throughout her career. Christa has a bachelor of arts in English from Barnard College, Columbia University, incorporating studies at University College, University of London. She also holds a master of arts degree in English from the University of Massachusetts and has completed executive coursework on business metrics at the Wharton School, University of Pennsylvania.

3 thoughts on “Getting SaaS-y on Release Management: HR Heads to the Cloud

  1. I love seeing this issue addressed! We went into our move to Success Factor’s hosted LMS to Success Factor’s SaaS LMS offering in 2013 with our eyes wide open on the topic above. We’ve successfully navigated from a static LMS that was six years old, to receiving six upgrades in the past 18 months. Here’s how we shifted our focus when we moved to SaaS:
    -SF offers an option to have Staging and Production upgrade at the same time, or to have Production upgrade a month after. We went with a month after so we have one month to test, open tickets, and start any issue mitigation. It’s been our saving grace on a few occasions in the past year.
    -We have a set of about 75 test scripts we maintain in our Enterprise application management tool. For any new functionality we adopt, we add a script at the pertinent release date. We selected these 75 out of 200 from the original implementation based on these hitting all of our functionality and letting us ensure our system runs as normal.
    -Our staging testing happens for a full week after that upgrade. We have plenty of time during working hours and we have three resources who take care of this. Those resources come from our technology team – we were able to allocate these folks to this because we were able to consolidate two other platforms into the LMS and we’re spending much less time fire fighting now that we’re on the SaaS version of the LMS. They run the 75 test scripts, following up the next day on anything that runs on auto processes. We open up tickets for anything that fails and plan mitigation for any other issues that might come up – notifying our Admin Community of Practice.
    -Our Production upgrades wrap up around 9am on Saturday and we assemble a team of 5-10 cross-functional testers to run all of the tests run in Staging over a week to be run in production in 3 hours, paying special attention to anything that we saw that was wonky in the Staging upgrade. A summary email is sent to learning leaders with all test results and any bugs we’ll watch on Saturday by 1pm.
    -We have timed all of our reporting and runs so that what is cancelled during the night of the upgrade just picks up the following day without any manual intervention.
    -We send a final note about the status of the upgrade on Sunday after all automatic processes have fun. Our IT partners are looped in for any feed issues (which we do have on occasion) and those issues are monitored until resolution.

    We pride ourselves on quiet upgrades. If our leaders in HR don’t know about the upgrade, it’s been successful. We take the mandatory functionality upgrades and plan for them, but we typically manage out of/into anything necessary far in advance. For new functionality, we have an Advisory Committee that meets monthly and reviews a one-page impact sheet for each new functionality release. They work with their Lines of Business to make a recommendation about adoption and we make the final call about how/when to roll out new functionality – but it never happens with a release. In general, we like to give new functionality 1-2 releases to "settle" with bugs/enhancements before adopting.

    It’s been a significant change in operation, but with no additional headcount (just rearranging folks) and with more time spent on planning for good things in the future rather than cleaning up the bugs from previous releases. I highly recommend a SaaS-based model.

Leave a Reply