Please login or join to subscribe to this thread
Can you explain what you mean by the term change calendar? It is not familiar PM terminology.
the term did not come across for me.
As you describe it, in a project I installed a schedule for change control meetings, at times a full Friday each week. Each individual change had its own timing after approval.
In product maintenance, to avoid daily changes, we established so-called release schedules to bundle changes, have an integration test and rollout activities aligned. Much like Apple and Microsoft handle their SW updates today. Others like Amazon do permanent, several changes a day. But if you need to involve customers e.g. by asking them to approve updates on their systems, you do not want to bother them too much, maybe monthly or quarterly releases. Nonwithstanding emergency fixes.
The main benefits I have seen with such artifacts (if they are kept current and accurate) are:
1. Better identification of potential "perfect storms" when too many changes are introduced at the same time for one or more stakeholders. This can help PMs, change champions and sponsors be more thoughtful in the timing of their changes.
2. Transparency for interested parties on what's coming up
I agree with Kiron. However, I am not a fan of a lot of changes during a project. It may be indicative of poor planning.
We often use a change advisory board calendar. For example, every week project managers would pop in to a CAB meeting to announce upcoming changes to functional representatives. Once given the go ahead, the change is assigned an upcoming change deployment slot..
The calendar as you call it can go by different names and formats. There are a variety of benefits however.
For the teams making changes, they can see the possible implementation points for planning their work and coordinating with suppliers.
For the change management team bundling changes as Thomas described, there is an economy of scale. It might take 10 hours for the paperwork on one change, but each additional change on the bundle or blockpoint would only add 2 extra hours for example.
Product testing sometimes occurs on multiple levels because as individual parts of the product change, they must still work with the other parts. If Groups A and B have parts that must work together, they must be tested together. If both implement at the same time, that's one set of testing. If each implements a month apart, both may have to test their parts twice. Regular blockpoints with visibility of what goes in them is a big help to the technical integration of the product.
My experience is that it can be a helpful operations tool, depending upon how your organization and environment are set up. At one company, we used it to track network, database, code (web, SAP, and other systems), and other changes for all systems/platforms, as well as planned outages and periods where we couldn't make changes due to business events. When one of my projects had a change that affected one of the systems, I'd view the calendar to identify potential conflicts, present the change, and answer questions about the impact of the change. There would be other project managers, technical managers, and engineers in the same meeting, presenting their changes. It would allow us to identify and coordinate potentially conflicting changes, as well as making sure that the change was communicated out to the appropriate audiences.
The benefit was that I could see most other changes while planning mine and schedule them in advance.
My last two positions have been with e-commerce companies that only had one small development team and they didn't have many integrated systems, so a change calendar didn't serve a purpose. There are blackout dates where we can't roll code, and we avoid making certain changes during peak business hours, but don't need a change calendar, at this point.
Please login or join to reply