How do you manage change requests for multiple systems?

Hi Aaron, thanks for the input. I agree that ideally we should go back to normal processes after transition. Do you mind sharing how your normal processes for change request are like?

Hi Keith - yes, it's a good practice and we segregate the internal and customer-driven changes. To clarify, my question is more about how to manage these customer-driven change requests for different systems.

Appreciate if you can share your experience on this

When I wrote about a defined change management process I was refering to the process to be used at whole company. From it, things like project management process is created. In our case, portfolio management is the owner of the company change management process mainly to shape demmand.

At one of the larger companies I've worked for, business units would submit proposals for changes - usually after talking to the development manager. If it was a small request he would assign it to one of his team without a proposal. If it was large enough to be considered a project he would have them submit a proposal.

At my current company, I'm the first and only PM. Previously, people would just walk up to developers. Now, I have them fill out a change request form that I review with the team to determine if it's a simple request that we assign to one of them or a project that I work on requirements with the requestor before creating any tasks for the team.

Managing customer changes across a product line can be an entire career. In general though, there should be a formal process to manage the change requests.

Often I see a 2 phase process. A high level screening review is performed in Phase 1 where feasibility is determined and a high level impact assessment developed. This will identify the scope of change and may determine whether the request is even offerable. A more detailed evaluation and SOW would follow in Phase 2 if there is authorization to proceed further. That's where specific resources and high fidelity estimates are identified based on the WBS.

Managing the changes across the product line varies by product, business strategy, etc. Some changes may be isolated to a single customer. Others might make sense to add to what is sometimes called a "provisioned baseline configuration". When you buy a car, you may have multiple choices for the stereo and the car is designed for installation of all options. If a customer wants a new option, the choices could be 1) NO; 2) We will install it custom on your vehicle only; or 3) We will revise the baseline model so that any new customer can get one as well.

Entire business systems may be set up to manage product structure changes at multiple levels such as the main product line (Windows 10), sub-models (Home, Professional, etc.), and customer unique changes to leverage re-use (company unique setting defaults at each update). In other cases, virtually nothing is reusable so there is no business case for designing in reusable product structure and customer configurations may be "point designed" with no effort spent on commonality across the product line.