Mindy RinghofferDirector of Project ManagementPhoenix, Az, United States
I wanted to get some feedback on how your company handles changes vs projects and your organization structure in who manages both. Do you complete a change request for system changes occuring in your projects or does a MIQ or Technical reference suffice? OR Is a change request submitted for system changes that are not part of a project? Do you have a separate Change Managment department from your Project Management Department/PMO? Or are they combined.
Currently, we have two separate areas, which doesn't make much sense to me. Project Management is located within IT and our Change Management is located within our Business Operations department. As a project manager, I must submit change requests to the Change Management department on any system changes that need to occur as part of a project so they can review any impacts to other departments. But, the project team already has a team member from the other departments participating and reviewing these changes.
Any thoughts or feedback on how Change Managment and Project Managment work together would be greatly appreciated. Thanks. Saving Changes...
Sort By:
Huw EvansSenior Manager, Projects and Partnerships| Vicinity CentresMount Waverley, Vic, Australia
One company I've worked with determined a criteria to asses a request as either a "change" or a "project". There were a few determining factors, but the main one was duration. If the request could be handled within three business days it was a "change", otherwise it was a project.
Once a project was determined it followed it's own approval process.
However, you are always going to have a final approval/signoff for a system change. Perhaps you just need someone with change approval to be in a core project team, so these can be approved without additional steps?
Saving Changes...
Elyse NielsenSenior Project Manager| Ascension Health Information ServicesHaines City, Fl, United States
Hi Mindy,
I think it really comes down to how and when your organization assesses a change to its applications and technology structure.
I have seen two scenarios, although I am certain there are others. One of which is when change management is a mechanism to control changes being released into production. In this instance, the change is being reviewed after all the configuration and testing have been completed. In this scenario as a project is preparing for the "go-live", it would be reviewed in change management. The second scenario aligns a bit more with ITIL, the change is managed upon request. Major changes are handled and reviewed as project in the beginning of the lifecycle with initiation and planning.
In answering your question, i think it depends on where the change management maturity is at your organization, compared with where it should be.
Mindy RinghofferDirector of Project ManagementPhoenix, Az, United States
Thanks for the feedback. The department which manages changes isn't the department which manages projects. So, it can create some confusion at times. We usually have an Operations employee attend all project meetings, so they would be able to review the changes going into affect with each project. The Change Management process is new to us, so we still need to work out the bugs and determine who should really own the process and when a change should be completed. We don't only submit change requests for system changes, but operational ones as well. That is why it doesn't currently live in the IT department. Saving Changes...
The changes may occur due to business need, upgration of technologies or combined factors. Appropriate party issues a change request. The changes are first suggested and evaluated for approval. Once, it is approved, it is recorded in change management documents as defined by organization. If the time required to implement the changes is more than x hours, the organization may treat this as seperate project. Else it may be categorized as small change. Hence, The organization defines how any change to either product or process should be handled. The organization may define certain change be implemented as a project and how those projects can be part of change management process. Saving Changes...
I'm a little puzzled why project changes, changes that are not yet in production, are being managed through the Business Area Production Change Management process. In most companies that rigorously manage ALL changes it comes down to their having been burned by some change in the past that cost some $$$ or impacted customer satisfaction, or production, etc.
If your development infrastructure is resident with production, then that level of care makes sense, but if your environment is totally separate - then obviously - it makes less sense.
I would suggest you approach the senior manager associated with the Change process and seek their guidance and advice. It may be as simple as asking. Worst case - your process remains the same. Saving Changes...
Mindy:
You might want to think of your situation from this perspective.
It sounds like your question might be related to a matrix organization vs a projectized organization.
I'll address the matrix organization however, my response reflects the structure that would exist in a projectized structure also.
Project Management:
PM should track, manage and control the changes introduced by the team for the entire project. PM should follow processes in the organization to submit change control for their project until it is put into production in the enterprise. Changes in the enterprise/organization should be reviewed by key change control team, PM and stakeholders affected by the change. PMs are ultimately responsible for managing the changes for the project.
Information Technology: Systems Operations
Every organization/business should have a separate department with a system operations department that is responsible for tracking and managing the changes required for systems that support the business. The resources in this department support the organizational change control to manage the processes and procedures to maintain the security, service levels and daily operations.
Project Teams:
PM will have project team members that are cross divisional and will have a specific role on the team. A team member responsible for implementing the change for the project would not normally be a representative from the System Operations division; it would normally be your technical leads. So, it does not really matter if your team members review the changes already per se; its not their role on your project to approve these changes. YRole idenification on your project is key to avoid conflict with your team member regular organizational job. PMs and technical /business leads should be responsible for your project changes to document, support and submit them. These individual will attend change project and operations change control meetings.
IT System Operations:
This division can live in IT or the business. The division that owns this process needs to have dialog with the internal customers in the organization so it works for everyone. The resources in this division manage all systems changes that would be introduced into the enterprise infrastructure. This includes all existing systems, integration of new system changes for new projects and replacement or upgraded systems. All projects will have changes to introduce into the enterprise that should be well documented, and reviewed by key staff who can assess, approve and discuss impacts and risks to the enterprise systems that would impact customer's ability to access any business systems.
Mindy - Project changes are better managed by the project manager. There is a fundamental need to understand the impact and risk to the project schedule which has to be evaluated prior to acceptance of the change.
Once the Project change is approved - I would then evaluate whether the change has implications or potential impact to the production environment. If it does - then it makes sense to add it to the Business Change Management process - but if it does not - I would think your boss would support not bringing it forward to them.
Too often - processes reach maturity and have not kept up with the evolving business processes. Certainly - utilization of project management principles and activities is not well understood by the Business Community. Lastly - you don't mention how the business people are informed of project progress, issues identified/opened/closed/etc., risks, schedule changes, costs, etc. I would further suggest that if that is not being done in a more formal way - the Change process is being used by the business folks to manage that information. Saving Changes...
