Browsing through some PM topics, I have realized that most sources use the Changelogs and Change Request logs interchangeably. But is that correct? I am not a PM, but aren't there often changes that we cannot influence, which make no sense to be recorded in the same place as CRs?


A change log is the place where you record changes to the project. This regards changes that weren't initially planned or included by the project's constraints of (mainly) cost, scope and time.

The change log is something from traditional project management, which works by defining a project as a sequence of activities (stages or phases) that you can plan and execute. In such an environment you plan everything from the beginning and then you execute on that plan.

Obviously, no project is immune to changes so at some point you encounter one. But you can't just willy-nilly make those changes because you have a plan, remember? If you don't stick to the plan you can affect the project constraints. Scope will change, which might impact cost and timeline.

So any change (be it demanded by stakeholders after you started to work, or discovered during development) needs to be approved. This is done by a change control board (CCB) that looks at the change and decides what to do with it. Approve it or reject it. All these changes, together with their status, are recorded in the change log.

A change request log is synonym with change log, although the most used term is change log. A change request is a form or document that you fill in to detail the changes that need to be made. You send this form to the CCB for approval.

Finally, as you mentioned yourself, there are changes that you can't control or influence. Do these go into the change log? The answer is, it depends.

If the Project Manager can adjust the plan in such a way that it doesn't impact the project constraints of scope, cost and money, and is not something that goes against what was initially agreed and planed, then they can make the change without having to go to the CCB for approval. If it impacts the project constraints and is beyond what the Project Manager can decide or control, then they will go to the CCB for approval, and the change will now be recorded in the change log.

  • Thank you, so any change is treated as a CR? I mean, what if the customer wants to do something about the constraints, is that still a CR? I am used to understand CRs to always involve the project scope, but I guess that is not the case. – John V Jan 20 at 14:03
  • When you agree on what to build and make a plan to build it, what you basically do is to set some expectations: we will build X, Y, Z, it will cost this much, and it will take that long. Then you go to work. As you work, you will encounter changes that need to be made. If the change also changes the expectations it should go to the CCB for approval. If the change keeps the same expectations you don't go to CCB because that would be a waste. Scope is usually the main source of change requests, but can be cost, schedule, or anything that affects expectations. – Bogdan Jan 20 at 14:28

I agree with most of what @Bogdan wrote but want to address those changes that do impact project constraints but are caused by both random or non random drivers that are out of control for everyone. In my opinion, the change process, which would be documented in the change log, should be reserved for formal changes to scope, budget, and schedule. The opportunity to "deny" the change is the test. If you cannot deny or reject the change, i.e., tasks taking longer than expected and breaking the schedule constraint, then it does not require a formal change because it is going to happen no matter what. This is a variance and is what it is. There could be downstream impacts that may require a formal change due to this schedule lapse, but the lapse itself would not require a formal change.

I also disagree with the comment where, if a change does not change expectations, then it would not require the change process. The "puts and takes" have to be documented formally and agreed upon. So if a change took place, which might be adding scope but removing other scope causing a net zero impact to budget and schedule, I would argue such a change has to go through formally in order to document the scope difference and to change the contract with signatures, even though budget and schedule was not impacted.

Mea Culpa: I misread @Bogdan's comment.

  • 2
    Adding some scope but removing other scope is a change in expectations from what I'm concerned, even if the impact on budget and schedule is nil. In my comment above, if my expectation was X, Y, Z, I don't expect to end up with X, Y, W, unless I was notified about it and decided that it's OK to swipe Z with W. So I'm in agreement with you that this kind of change should go through a change request. – Bogdan Jan 20 at 15:28
  • Excellent! I misread. – David Espina Jan 20 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.