A Fable about Change Management

Once upon a time, there was a system called "Assessment Management System." There were many (many) Change Management activities that governed the packaging and release of this system. For example, there was a weekly meeting where proposed changes to the system - which were entered into a system called Rally - had to be approved by the manager of that development team. Within Rally, there was a field in the "story" details for us (the tech writers) to mark whether the change impacted the user interface, the documentation, or was N/A. We ran queries over the Rally database to get a list of stories we needed to review for doc changes. We used that list of stories to determine our workload. The reviewing of the stories packaged with a release was time-consuming, but it allowed us to “own” whether or not there was a change needed to the doc. We thought of the doc, in this way, as “source code” and as the product owners of the documentation. Some dev teams had bought into our value as TWers and would mark that field in Rally as a way to flag it for us. There was a field for designating what release the change was to be included in. It was a sweet CM process.

However, all good things end.

It was decided to rewrite the system using a new tech platform. The new system was to be called "Assessment Management System Next" and was to be developed by an entirely  different team of developers. These developers were never involved in the original Change Management activities for "Assessment Management System" and, because of that, they only heard about the meetings and the bureaucracy. Thus, this new dev team ditched all of those CM activities. They didn’t replace them with a different approach – they were simply not going to be done.

Thus, there were no longer any meetings to review what changes were going to be made. Only the Dev Team Manager (who hated writing things down lest he be questioned what he meant by his description) knew what changes were going to be made to the system and when they’d be released. At first, some of the Dev team members were using Rally, but there was no requirement – from anyone – to use the "release" field. Looking at a Rally story, there was no way to know if the change was going out tomorrow, next week, or if it had already been released! There was no way to know which changes to the system were being bundled into a release.

In response to all of this, our manager decided that we would no longer "dumpster dive" in Rally and review stories for potential doc changes. The Dev team(s) were told they needed to create Release Notes and to give those Release Notes to us and then we would write the doc changes based upon those Release Notes. If the Dev team(s) didn't include a change to the system - like adding a new menu option - our manager told us we did not need to be worried about it. Explicitly, we were told do not investigate any change in the UI that we might have seen in the Test environment of the system. If it’s not on the list, it’s not relevant.

No, I didn’t like this change. However, my questioning of the “new way” of doing our work was seen as “not adaptable to change.” After a while, I accepted the new way of doing our work. Then a release went out to the customer, with a change in the system, that wasn't in Dev's Release Notes. Customers asked Customer Support about the new functionality, how it impacted the way they did their tasks in the system. Customer Support looked in the online Help and found no information. They went to our manager. She said, "It wasn't in the Release Notes. We don't know what it does." She pushed the issue off on Dev, who had a Dev team member talk to the customer. Essentially, it came back to us as we scrambled to figure out what we needed to know, to meet with the Dev team(s) and to learn how the changes worked, and how it impacted the system. These were all things that had been learned during the "Assessment Management System" CM activities that had been dismissed as "too bureaucratic."

There is no moral or goal of telling this fable - it came to my mind during my ITIL class today.