4  Change Management and Git

4.1 Introduction

Statistical programmers in the pharmaceutical industry operate in a highly regulated environment where validated, reproducible analysis is paramount. Historically, the standard workflow 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 introduces concepts such as branches, commits, remote repositories, pull requests, and merges that may be unfamiliar to teams accustomed to other environments. The learning curve can be difficult and requires embracing a more collaborative and transparent workflow.

Furthermore, the regulatory framework of the pharmaceutical industry is strict. When Git is used as part of a process that creates or manages regulated records, its intended use and applicable GxP requirements should be defined through the organization’s quality system and a documented, risk-based assessment. Appropriate controls may include access management, traceability, review and approval, record retention, backup, and protection against unauthorized changes.

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.

4.2 The Change Curve

The Change Curve is a well known model for understanding how employees respond to change Holdsworth and Bridgman (2024). While it has many different forms, it generally begins with initial shock, followed by resistance, low morale, gradual experimentation, and then acceptance and integration. An important consideration for any company trying to make any significant 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 integrate the technology into how we work.

In this chapter, we will largely set aside the specifics of how Git is used within your organization (for more, please see the recommendations chapter). Instead, we will focus on the ways you can support your team as they learn to adopt Git in their day-to-day work.

4.3 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, 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

4.4 Introducing tools

Depending on your company’s size and how they want to use Git, there are a number of tools to interact with Git and GitHub. These are covered more in the appendix, but your decision is likely to be motivated based on how close you want users to interact with Git.

You may choose to hide Git’s complexity from users by giving them easy-to-use tools, or you may choose to teach users to work directly with Git commands in the terminal. The tools you select will influence which approach is possible.

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.

4.5 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 dynamic updates as you get feedback from users on what works and what does not.

4.5.1 Troubleshooting common scenarios

An important resource to build over time is how to resolve issues that might occur when using Git. The exact nature of the issues users are likely to run into will be specific to your organisation’s workflow but some likely common issues are

  • Merge conflicts and how to resolve them safely
  • Reverting a change in shared history using git revert
  • Rewriting unshared local history using git reset, with appropriate caution
  • Handling uncommitted changes before switching branches using git stash or a work-in-progress commit
  • Resolving authentication and repository-permission issues

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.

4.6 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 targeted 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.

4.7 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.

4.8 Conclusion

Any kind of change can have large impacts on an organisation, and Git as a technology can definitely cause some friction. When the transition is handled well and supported in a responsive way, Git can become a routine and sustainable part of the statistical programming workflow.