50 change management and git

white-paper/Challenges.qmd

@@ -1,5 +1,79 @@
 # Change Management and Git
 
-This chapter will discuss challenges in adoption of Git as well as how these might be addressed.
+## Introduction
 
+Statistical programmers in the pharmaceutical industry operate in a highly regulated environment where validated, reproducible analysis is paramount. For several years, the standard workflow has revolved around statistical computing environments managed through shared network drives, strict naming conventions, and manual version control practices (saving files with incremental version numbers or descriptive suffixes before archiving) or with regular server backups. These habits, while informal, have been deeply embedded in day-to-day practice and have served as the de facto audit trail in many organizations.
 
+Introducing Git into this context presents a unique set of challenges that go beyond mere tool adoption. It relies on notions such as sub-branches linked to a main branch, commits, remote repositories and merges, that can be difficult to adopt for teams used to work in other environments. The learning curve can be difficult and requires to embrace a more collaborative and transparent workflow.
+
+Furthermore, the regulatory framework of the pharmaceutical industry is strict. Any change management system touching analysis code or submission-relevant outputs must be set in a GxP environment. Git must be used in a way that ensures theses compliances (traceability, audit, etc).
+
+Organizational culture also plays a significant role. Statistical programmers often work independently or in small teams with well-established personal workflows. Moving to a Git focused workflow requires not only technical training, but to being open to new mindsets and ways of working.
+
+## The Change Curve
+
+The Change Curve is a well known model for understanding how employees resond to change @HOLDSWORTH2024254. While there are many different implementations of it, generally speaking it is understood to be split into two main phases, first of resistance and then of acceptance. An important attitude in any company trying to make any sort of change, be it organisational or technological, is to have empathy for those individuals who are experiencing it, and give them the support they need.
+
+We must understand that any change will take time to embed into an organisation, and the main thing we can influence is how fast that change goes, and how well we can adopt the technology.
+
+In this chapter we will mostly ignore the how of using Git within your company (for more, please see the [recommendations](recommendations.qmd) chapter), and look instead about the things you can do to support your team as they learn to adopt Git in practice. 
+
+## Benefits of Git for statistical programmers
+
+One important lesson from companies that have already experienced the transition to using Git is that, because Git can be a challenging technology to adopt at first, it can be easy to lose sight as to why this change is being made.
+
+To combat this difficulty, we recommend highlighting early and often the benefits of adopting Git in practice. These are covered in more detail in the chapter on [benefits](benefits.qmd), but things you can easily show to someone who is learning Git:
+
+1) The easy audit trail on a Github repository, and the ability to view code at different points in time trivially
+2) Pull Requests, and the ability to review code line by line and provide easy feedback
+3) AI Integrations which can improve code review in practice
+4) Findability and searchability of code
+
+All of these are very easy to show quite quickly, and should not be forgotten when trying to bring someone into a new technology
+
+## Introducing tools
+
+Depending on your company's size and how they want to use Git, there a number of tools to interact with Git and Github. These are covered more in the [appendix](tools.qmd), but your decision is likely to be motivated based on how close you want users to interact with Git.
+
+You may decide that you wish to abstract users access to Git or you might decide that you wish to get users comfortable with direct Git terminal access. Different tools will enable different approaches.
+
+Note that of course you are not limited to using any one tool, and can make multiple available to support different workflows and different levels of ability in your user base. The important thing when it comes to managing change is to make it clear to individuals what tools are for, and when they are using them. For consistency, it may be wise to limit teams that work together to at most two common tools. 
+
+## Preparing Documentation
+
+There are a number of excellent resources for learning Git online. This means that when creating internal documentation on Git it is important to focus on how your organisation will be using Git in practice.
+
+Your documentation should focus first on the ways someone will work in their day to day, covering the typical flow and where possible integrating it into the tools they are likely to use. Documentation should be easy to access and use, and easy to search. We recommend where possible to not include this level of documentation in GxP training, as the latter is likely to be in systems that can be harder to update quickly based on user feedback.
+
+GxP training is of course important to meet our compliance requirements, but we can normally build training on top of it which enables more dyanmic updates as you get feedback from users on what works and what does not. 
+
+### Failure cases
+
+An important resource to build over time is how to resolve issues that might occur when using Git. The exact nature of the issues are likely to run into will be specific to your organisations workflow but some likely common issues are
+
+- Merge conflicts and how to resolve them smoothly
+- Undoing things (git reset and revert)
+- Not being able to switch brances (git stash)
+
+Having simple, easy to understand guides to help in these cases can be very useful. These are things that can be taught, but don't come up frequently enough for the knowledge to necessarily be embedded, so having clear instructions on these can greatly improve Git adoption.
+
+
+## Practical examples as training
+
+When teaching users to use Git, we should always focus on practical examples which relate as closely to how the user will be applying Git in practice. While for fundamentals it can be helpful to be artificial, as soon as your users have grasped the basic, we strongly encourage examples that involve practicing the workflow they do in person.
+
+Where possible trainings should be live, and in person if it is possible to arrange, to allow maximum engagement.
+
+One vital aspect is that training should be targetted only at individuals who are going to be adopting the Git workflow very soon, or who are already adopting it. This means that what they have learnt can be applied straight away, removing the danger of knowledge atrophying during use. Related to this, if you can train cohorts of users who will be working together, this can be very useful as they will be able to learn and practice together. 
+
+## Feedback and checking in
+
+One important way to manage change in an organisation is to demonstrate that you are open to feedback, and responding to it. This means you must be actively seeking out feedback, not just passively waiting for it. Consider small focus groups, arranging meetings with key thought leaders, alongside regular surveys of sentiment. 
+
+When taking feedback, it is important to understand the context in which it is delivered. Try to not be too reactive: making changes immediately may not be the best course of action, but try to fully understand what the individual is saying and how you can best address it. In some cases, it may truly be that the Git workflow your organisation has chosen to adopt is not fit for purpose, but in others it may be that you need better training and support to help users address scenarios they do not currently understand.
+
+When you do make changes based on feedback, make sure you communicate them clearly, and make clear the reason you chose to adopt them.
+
+## Conclusion
+
+Any kind of change can have large impacts on an organisation, and Git as a technology can definitely cause some friction. Just like with all changes, provided it is handed well and responsively, then within a few years the use of Git will simply be the new normal. 

white-paper/_quarto.yml

@@ -8,6 +8,7 @@ book:
   chapters:
     - index.qmd
     - state.qmd
+    - benefits.qmd
     - Challenges.qmd
     - part: "Recommendations"
       chapters:

white-paper/benefits.qmd

@@ -0,0 +1,5 @@
+# Benefits
+
+## Introduction
+
+This chapter aims to include at a high level some benefits for using Git in clinical development.

white-paper/references.bib

@@ -15,5 +15,27 @@ @article{knuth84
   pages = {97–111},
   numpages = {15}
 }
-
+@article{HOLDSWORTH2024254,
+title = {From coping with dying to coping with organizational change: the bricolage of the change curve’s evolution},
+journal = {Journal of Organizational Change Management},
+volume = {38},
+number = {8},
+pages = {254-269},
+year = {2024},
+issn = {0953-4814},
+doi = {https://doi.org/10.1108/JOCM-05-2025-0479},
+url = {https://www.sciencedirect.com/science/article/pii/S0953481425000594},
+author = {Logan Holdsworth and Todd Bridgman},
+keywords = {Elisabeth Kübler-Ross, Five stages of dying, Change curve, Organizational change, Coping with change, Resistance to change},
+abstract = {Purpose
+We construct an intellectual history of the change curve, a well-known model for understanding how employees respond to change, from the accepted origin point of Elisabeth Kübler-Ross’ five stages of dying model. We analyse how her model evolved from providing insight into how people cope with dying to how people cope with organizational change.
+Design/methodology/approach
+We mapped the evolution of Kübler-Ross’ model from its original context of psychiatry to organizational change management. We identified and analysed adaptations of the model in scholarly and practitioner literature, and assessed the implications of this evolution.
+Findings
+We identify three phases of the evolution of Kübler-Ross’ model – originators, transitioners and translators. These adaptations exemplify bricolage, where disparate theoretical elements are assembled based on their ability to serve the needs and interests of those developing the model.
+Practical implications
+We encourage practitioners to reflect critically on the strengths and limitations of the change curve. The model is relatable and offers a useful lens for exploring people’s emotional responses to change. However, it presents a universal and linear view of emotional responses, and a narrow interpretation of resistance to change. We suggest how managers might assist employees to cope with organizational change in a way more in keeping with Kübler-Ross’ original insights.
+Originality/value
+This is the first analysis of the evolution of Kübler-Ross’ model of dying into a well-established change management tool using the lens of bricolage. It contributes to growing interest in exploring the origins and evolution of influential management ideas.}
+}