Please login or join to subscribe to this thread
Change management process is the life jacket for the project manager. Is not about the tool you use, is about the commitment you get about a change that will impact the whole project. So, separation between process, tools and techniques must be done for each thing you run in your project. In my opinion this document has no sense except the case the project manager like to have a separate document to record things you can record in other documents like action items log or something similar.
I agree with Sergio
Remember that principles are different than practices. We want to maintain control over project baselines once those have been established, but "how" we do that can vary project-to-project based on context and scale.
I'd rather see disciplined usage of a decision log for all types of key decisions rather than have discrete artifacts for decisions & changes and them not being updated.
It is certainly feasible, but whether or not it is appropriate or acceptable may depend on factors other than the project size.
Many tools that we use to generate lists or documents are really just interface tools to large structured lists of data stored in a database. We create separate lists using purpose built filters and visualization tools to segregate and organize the data. Tools like Excel also allow you to create different lists using filters (e.g. Change? Y/N drop-down filters)
Change management often has a structured governance process because even on a small project, the affect of the change may impact many downstream stakeholders not directly on your project team such as finance and purchasing. That may require significantly more process formality and structured data than routine decisions.
In order to fill all the needs of the change process, it may require many additional data fields not applicable to decisions. Trying to combine the two, the decision log part may be overly complicated by fields only applicable to changes, or it won't fit the needs of some impacted stakeholders when the entry is a change. That can be managed using macros, but now you just added more tool complexity.
Perhaps your project and process requirements are relatively simple and your lists are just lists impacting a small core team who can work with the data in any number of formats. One trap I have discovered when architecting systems and processes for managing configuration and change data however is that the simplest way to store and manage the data from a tool designer perspective (in this case you, the person making one or more lists) may be extremely inconvenient for the end user trying to make sense out of the information.
To decide whether or not they can be combined, you need to weigh whether the savings from managing one list, outweighs the inconvenience of trying to use one list to do many different things. If not, segregating the data may still be the easiest approach overall.
The article you reference arguments that with more virtual teaming, key information must be clear and more formal.
The decision log is a good example, I used one when running a PMI Chapter to make sure a annually changing team understands what decisions have been made over time by the Board. Otherwise, decisions are not followed thru or questioned.
Should it be combined, as you ask? Depends on the length of the project and composition of the team. If short and small/stable maybe. Even then though, separate entities for separate processes makes communication and agenda setting clearer.
You also should have a separate risk register, though RAID is used by some combining some typical lists.
Consider that the change logs deals with the WHAT of the project and the decision log with the HOW.
Please login or join to reply