TOPIC: When is Integrated Change Control required?

I'm kind of struggling with when I should submit a change request for something versus when it is not required.

It seems the primary rule of thumb is based on whether or not the Project Management Plan has been created first or a Project "baseline" is established.

However, it seems like some documents require a change request and others don't? Is there something that outlines this?

I would use a question example, but I can't seem to access any of my completed exams. Is anyone else having issues with the PM exam simulator at the moment?

Also is there a quick process chart that maps all outputs? There seem to be several outputs outside of the 49 PM processes, and it's hard for me to determine which process area it falls into. For example, I'm only now learning that Lessons Learned is part of "manage project knowledge". But originally, I had thought lessons learned was related to closing the phase. So I'm a bit confused how these things all flow together.

Thanks in advance.

You would submit a change request for any controlled document. This is usually any of the Plans / baselines, as well as any documents that are covered under configuration control. See page 89 in PMBOK v.6 for an overview. Remember, if a plan or baseline has not been approved there is no change request required, as it is still being developed.

There are several inputs, outputs, and tools and techniques that are shared between several processes. The best advice I can give is to not try to memorize them, but understand why they fit in that process. For instance you get the Lessons Learned Register as an output from Manage Project Knowledge, and updates to this can occur throughout several processes.

Thanks Kyle.

Do you have any tips for when Issues needs to be logged? I also get a bit confused on when you need to immediately log an issue.

It's really "the first" thing you should do. Note when questions ask you "what should the PM do first". If the question describes an issue and asks what you should do first, it should be logged appropriately.

So what would constitute an issue?

Is it only when identified risks become problematic or is it really any obstacle the project faces?

FAIZY MANSOURY wrote: So what would constitute an issue?

Is it only when identified risks become problematic or is it really any obstacle the project faces?

Issues
An issue is anything that does occur and negatively impacts the project is some way - be it a negative impact to your schedule, your budget, your product scope, or anything that detracts from the goals of your project. You log issues to ensure they are followed up on and resolved. Each issue should have an owner - the main person assigned to drive the resolution of the issue. Logging issues is also important to keep a record of what happened on the project so that you can add them to the Lessons Learned Repository. This information may benefit future similar projects on the potential pitfalls that could occur, and they can use this information to plan their risk management accordingly.

Risks
A negative risk (or threat) is a potential issue that may or may not occur. When a negative risk (a threat) occurs, it then becomes an issue. Risk management is all about mitigating or a avoiding risks so that the issue is avoided entirely, or that the probability and impacts are reduced if it does in fact materialize.