Hi, it's Gorkem Sevinc and now I will be talking about Change Management in software. Change management is something that is very important in a project or a product to keep track of its organizational change, and Dr. Davidson has already talked to you in an earlier module about organizational readiness for change. Change management includes the changes that you do to a project management plan and actually in software development. So, number two and number three is what I'm going to be focusing on here. Not change management on its own, but more about project management plan changes on software development changes and this is not at the organizational level. So, let's make sure that you understand that distinction. Why is this important? It's the triple constraint is keeping things within scope, budget, and quality. So, change management helps us respect the triple constraints in really any process. Now, change management as it relates to software development, it's it includes tracking and managing changes to requirements and code. This can involve the user interface, user experience changes, functionality changes, and even bug fixes sometimes. There's such a major change that is done to fix that bug that you do the change management process around it. It can occur during development of many and different types of applications. An example from my work in software is on an FDA-regulated medical device. In this regulated software environment, change management is absolutely key and actually FDA requires you to do it. Essentially, you get to define what your software is. First of all, you get approval. Okay, let's say you have the FDA approval now. Then what? Let's say you're changing the user interface and it impacts how the device functions. You have something new that's going to work better. How do you communicate around it? How do you make sure that your users are aware of what's happening? So, you need to keep track of any requirement updates, keep track of any software updates, and version, version, version. You always have to keep track of versions and communicate those versions. Some of this includes also release management planning. If you're doing a release as part of your change management process, you have to plan around it. That includes communication of the change to your stakeholders, your users as well or your even customers. So, in your project management plan, do you have, you know, details related to the timeline of a project, the scope, budget, quality, and some other, right? A solid change management process really ensures that any of those changes to any of the above to the scope, the budget quality, they're documented, they're tracked, they are communicated, and you stick to them as much as possible. So, let's give an example. We provided a link to an example from CMS that you can actually find as a resource underneath this video. You need to have a process for managing these changes as I said. So, let's look at this example. Change management approach can have the change management process, process flow requirements, forms and change management logs. How do you evaluate and authorize these change requests, and do you have actually a board of people that actually approve these changes before they're done, before they're even worked on? What you need to track as part of a change process is describing what this change request is, who requested it, how do you prioritize it, who will be responsible for implementing the change, the date that change was implemented, and any other information that you see as key items to keep track of. As I mentioned, versioning is really, really important. You must keep a log as Version Control really helps you define what's in each version of your software. Your 1.1 version may have XYZ functionalities and 1.2 version may have the W functionality, and this is where you communicate. This is where you keep track of it. This is where you share it with people. Then you need to prioritize these change requests. We generally like to define high, medium, low. As the project progresses, you may have different priority groups, but this is where you define what makes a change request high priority? Is it impacting users? Does it mean that the product or project is not able to be used? Or is it low priority, it's something that we have heard about, but it's okay for it to wait until our next planned release. So, this is where you define the rules, the business logic that really defines your project change management. Of course, you need to track these change requests. It's part of your project plan. So, the statuses that you may use are you're in progress, you're working on it now or you're reviewing it or it's open, you haven't even worked on it yet. You may be testing it, make sure that you're doing all your quality assurance or it may be closed as complete, all the tests have been passed. It has been released. Then you can say this is closed. The key takeaway here is having a solid change management plan. It's really, really crucial for project success. That's it for change management. Thank you for listening.