Friday Food for Thought - How does your organization handle Change Management?

[Beth]

So you’ve made changes to the development version of an app that’s in production… what do you do now?

The question of change management comes up fairly often, and I wanted to crowd source some discussion from the Tulip Community on this!

How do you and your organizations do change management with Tulip?

Some questions to think about:

• How to evaluate the change and determine what steps to follow next
  • What changed and how significant is the change? (ex. changing a button color, maybe not a big deal, but changing trigger logic could be)
• How to communicate app changes to internal teams?
  • What methods or tools do you use for communication and organization?
  • How often are you communicating changes? Is there a cadence?
• How do you manage approval process for changes?
  • What “gates” exist and who needs to be an approver?
  • Is training required for app end-users and how is that managed?

I’m probably missing some other questions here, but just a start to get the ideas flowing

Tagging some folks who may be interested in this topic and have some good ideas from what they have done in the past!
@rinfantozzi @MikeRousch @Dave.ESSInc @alec.giljohann @steve.midcalf @jjj @jmlowden @thorsten.langner @aalai @nicolettenaya @Gary

[jjj]

Answers in bold. Interested to hear everyone else’s thoughts.

@Beth

How to evaluate the change and determine what steps to follow next

• What changed and how significant is the change? (ex. changing a button color, maybe not a big deal, but changing trigger logic could be)
  We are still deciding on this, so I’m interested to hear what other people do.

• What methods or tools do you use for communication and organization?
  Email summary of changes is what’s used now. But going forward we will use validation reports to capture changes.

• How often are you communicating changes? Is there a cadence?
  Small changes are communicated via stand up meeting in the affected department, followed up with an email. Changes are done as-needed.

• How do you manage approval process for changes?
  We are working to formalize this now. Currently app changes aren’t included in our formal change management procedure. In the future, apps that gather or push data to other production systems will be release with a formal change management process.

• Is training required for app end-users and how is that managed?
  Since our apps typically augment processes the operators already do, we don’t formally train them to use the apps, though some app steps are reference in the process SOPs.

[jmlowden]

LTS 8.2, Life Science / GxP, Private Hosted, with DEV, QA, and PROD instances

• How to evaluate the change and determine what steps to follow next
  • What changed and how significant is the change? (ex. changing a button color, maybe not a big deal, but changing trigger logic could be)
    • At present, we are only testing changes to functional elements, and currently don’t have any user stories with specific color, size, format requirements for widgets
    • We do have some user stories wherein display text is specified for widgets and/or single-/multi-select options
    • So far, if we are not making the former type of changes without the latter, so we don’t have a process for just making changes to content that is outside of user stories
    • When we do make the latter changes, we are updating user stories in Jira, associating them with a UAT, promoting the revised app from our DEV instance to our QA instance (basically export/import), executing UAT, approving UAT, and then promoting the app from DEV to our PROD instance
• How to communicate app changes to internal teams?
  • What methods or tools do you use for communication and organization?
    • Typically email at minimum
    • If changes to Tulip applications would impact SOPs or WIs in a non-administrative fashion, then there would be Read & Undertand training pushed though our LMS (triggered by our DMS)
    • We have also offered Instructor Led Training to users when deploying new apps, and plan to do so when making functional changes to existing apps
  • How often are you communicating changes? Is there a cadence?
    • We do not currently have a standard release cadence, but I like that idea.
    • For document revisions, we have had better on-time training completions when we’ve stuck to a standard release schedule (i.e. documents go effective / training due on the 14th and 28th of each month), at least for the documents we own
• How do you manage approval process for changes?
  • What “gates” exist and who needs to be an approver?
    • Approvals for UAT and SDLC/CSV release documentation are all in Jira and Asset Management (not sure if this is a company thing or a widely used IT documentation tool)
    • Approvers include the Business Application Owner, Technical Application Owner, and Technical Quality, at minimum
  • Is training required for app end-users and how is that managed?
    • If changes to Tulip applications would impact SOPs or WIs in a non-administrative fashion, then there would be Read & Undertand training pushed though our LMS (triggered by our DMS)
    • We have also offered Instructor Led Training to users when deploying new apps, and plan to do so when making functional changes to existing apps
    • For document revisions, we have had better on-time training completions when we’ve stuck to a standard release schedule (i.e. documents go effective / training due on the 14th and 28th of each month), at least for the documents we own