When I'm asked a question, my reply often is "Well, there are two answers to that question: a short one and a long one (or a simple and complex)..." And that is because there are indeed two types of answers to many questions. I would call them definitive and process oriented. For example, "how long will it take to complete this project?". The simple answer might be "we do not know", the complex answer will be "we do not know, but here is how we can control and manage schedule for our project and make it possible to make certain commitments on dates depending on your goals".

Another perspective on these answers is that one of them is like "here it is" and another one is "oh, here is how you get it".Remember that saying that professionals do not always know all the answers, but they always know how to find what they need.

The matter of fact is that process oriented answers are just as important as definitive replies. Of course, we should always starve to simplicity, but if there is no simple solution, we should not abandon looking for complex ones.

Many junior PMs think that Change Requests (in our company we call them Change Orders) always come to project team from the outer space, whenever the client or other stakeholders want to change something, like increase the scope or tighten the schedule. They think that CRs are there to protect the project team from changes coming outside of the project.

The thing is that CRs are not only about the scope. There are many more controlled project parameters, although the scope is probably the most notorious when it comes to changes. And whenever you need to change any of these parameters you need a Change Request:

• Scope
• Budget
• Schedule
• Specifications
• Quality (if you run projects better than others and really control quality)

When the customer wants to add something to the scope of the project, you need to issue a Change Request to adjust other parameters accordingly. When you need to change schedule, you issue a Change Request to communicate  the change and get approval for it. So Change Requests are not only and not always incoming, they can and should be outgoing to communicate important things, which happen to the project.

Change Requests are meant to protect project stakeholders from silent changes in the project. As much as you want to be informed and be able to react appropriately to the additional work coming your way, the same way project customer wants to be informed and be able to do something on his end, if you decide that final delivery date needs to be moved.

Change Requests are means of communication and no wonder that not doing this part of communication properly can put your project at significant risk. Next time not only wait for CRs to come, but be sure to communicate the changes you initiate to other project stakeholders.

Also check out The Top 9 Reasons Why Projects Fail at The PM Podcast. Communication done right is 80% of successful project.