In my first set of posts, I dis­cussed what to con­sider when out­sourc­ing a Web con­tent man­age­ment (WCM) sys­tem. Now I would like to con­cen­trate on elab­o­rat­ing on host­ing and man­aged services.

Most of you are aware of man­aged services—a reli­able, secure, and flex­i­ble host­ing ser­vice that super­vises your network’s infra­struc­ture through the cloud. An out­side source or host cre­ates, oper­ates, and main­tains the infrastructure.

Man­aged ser­vices includes five cores of sup­port: change man­age­ment, backup and recov­ery, roles and respon­si­bil­i­ties, secu­rity, and deploy­ment model. Each of the five cores is essen­tial for the proper oper­a­tion of man­aged ser­vices. I will dis­cuss and define each core in the next five posts. Obvi­ously, there are other things to address and con­sider, but for the pur­poses of this set of posts, I’ll cen­ter my think­ing on these five themes. The first I will tackle is the notion of change management.

 What Is Change Management?

Dur­ing my many years as a group prod­uct mar­ket­ing man­ager and cre­at­ing go-to-market strate­gies for Adobe, I have dis­cov­ered that busi­nesses and man­aged ser­vice providers must, with­out ques­tion, have a full under­stand­ing of any change that is con­tem­plated to a WCM sys­tem. Dur­ing the life­time of your sys­tem, both unplanned and planned changes occur or become nec­es­sary. For exam­ple, unplanned changes may need to occur as a result of a dis­as­ter that affects the oper­a­tion of your sys­tem. Planned changes may become nec­es­sary when you want to cre­ate con­tin­gency or suc­ces­sion strategies.

You and your host must have a thought-out plan when­ever you con­tem­plate any change to your sys­tem. At the end of the day, you are work­ing with an inde­pen­dent team from the host­ing com­pany. You need to be cer­tain that your team and the host’s team are on the same page. You don’t want any sur­prises when a change of some kind becomes nec­es­sary or is requested.

Plan­ning Changes

To ensure that every­one is on the same page, I sug­gest that you cre­ate a for­mal struc­ture, or pro­to­col, prior to con­sid­er­ing any changes. You should sit down with your host and develop a doc­u­ment or run book that includes:

  • details of your sys­tem and the cus­tomiza­tions that have been made;
  • the indi­vid­ual at the host­ing and man­aged ser­vice com­pany respon­si­ble for change issues and how to con­tact him or her;
  • who, how, and when indi­vid­u­als should be con­tacted on your end when a sit­u­a­tion arises;
  • details of the dif­fer­ent use cases cre­ated for the web­site so the proper regres­sion tests can be administered;
  • specifics about all the user accep­tance test­ing you’ve done so you can do those tests after changes have been made;
  • infor­ma­tion about the load and stress test­ing that’s been done;
  • the pro­to­col for rolling back the sys­tem if the changes made aren’t to your level of sat­is­fac­tion; and
  • details about your sys­tem, includ­ing hard­ware requirements.

You and the host also need to know how the archi­tec­ture of the sys­tem is deployed as well as the key cal­en­dar dates for your sys­tem. For instance, when do you want to roll out upgrades, bug fixes, patches, etc. Do you pre­fer to have these done in low traf­fic hours in the Pacific or East­ern time zone?

You and the host must dis­cuss these issues as you cre­ate the run book and for­mu­late a plan to per­form changes prop­erly. When you choose a host, ask if the com­pany has a well-thought-out change man­age­ment con­trol pro­to­col avail­able and then include all of your customizations.

The run book should also be sup­ported by a board of direc­tors at the host com­pany that con­sists of rep­re­sen­ta­tives of depart­ments that are respon­si­ble for changes.

Adobe’s change approval board (CAB), for exam­ple, includes rep­re­sen­ta­tives from engi­neer­ing, IT, con­sult­ing, and cus­tomer sup­port. Also included is the cus­tomer suc­cess engi­neer (CSE), who is solely respon­si­ble for com­mu­ni­cat­ing between the host and the company.

When a change is requested, all mem­bers of CAB are told about the request and eval­u­ate whether it is accept­able. CAB doc­u­ments the change request in the run book and com­pares it to other changes in the book to ensure that it com­plies with pro­to­col. We walk the cus­tomer through each step. Once the change is approved, CAB takes steps to make cer­tain that the change is per­formed appropriately.

You should set up your own CAB and make cer­tain that the host you are work­ing with has a sim­i­lar struc­ture to avoid unnec­es­sary changes.

The bot­tom line is that when change to a WCM sys­tem is requested, trust the experts to deter­mine if it is nec­es­sary and struc­tured appropriately.

This post was pre­vi­ously pub­lished on the Adobe Dig­i­tal Mar­ket­ing blog, June 23, 2014.