[SOUND] >> Once you complete all of your plans, all you have to do is bring them to life, right? Wrong. Things will change. The purpose of all of your plans is not to insure that everything remains completely static. That does not mean that you should disregard the plans. It does mean that you should want to move forward based on your plans and understand that you will experience some changes. A certain amount of change on your project is to be expected. Change is not bad. Successful projects experience change. It is about how those changes are handled. If you have ever worked on a project where you began to wonder if it would ever end, and it seemed like that project objectives kept changing, then you have experienced scope creep. Scope creep occurs when the project objectives are not clearly defined or they're not agreed upon. It can also occur when there has been little or no planning, and so there's no real understanding of what needs to occur. And scope creep can occur when there is no official process to request changes. When there's no official process to request changes, it becomes too easy for people to ask changes. And it's not that we should make people feel badly for requesting changes, we simply want to encourage planning and thinking about project scope and objectives earlier, rather than later. Unregulated changes lead to confusion. And there they take inaccurate information as to what was really accomplished and how much time and money it really took. There are very good reasons to request changes to a project. It's possible that during the project a team member might discover a new way to handle a problem. And it makes sense to incorporate that approach into the project right now. Or a team member could discover something that needs correcting, and as a project team, you are working in the same area where the correction needs to take place. And it could be more efficient to incorporate the fix into your project. You might also discover that another project team is doing similar work, in which case, perhaps you remove some scope from your project. The more you move forward with your project the more you will know. And sometimes that knowledge leads to recommendations for changes. That leads us back to the point, that change to your project is not bad. It is about how to handle it. You want a change control process, you want that process to be easy to understand, easy to follow and well communicated. If the process is over complicated, people will stop using it. Doesn't mean they're gonna stop asking for changes. It means they're going to find another way to get their changes and this could lead you back to scope creep. A process might be as simple as a standardized form used to submit a request for the change. The team receives it, estimates it. The change goes to the review board. The change is either accepted, rejected, or returned with questions, and the results are communicated. Who can ask for a change? Well, this is gonna vary by organization. I"m in favor of allowing most people to ask for changes. After all, a good review and a good change board will only approve the changes that really bring value to the project. Who is on the change board? The change board typically has key project stakeholders who represent different areas of the organization and can make decisions which reflect what is best for the project and what is best for the organization. A good change process will have change thresholds. Changes the team can approve, changes the change board must approve and changes that require executive approval. In this way the project does not go on hold waiting for the board to meet for every change yet still has a good level of oversight so that scope creep is avoided. The benefits of change control are many. Inconsequential changes are discouraged by the formal process. Costs of changes are maintained in a log. Integrity of the work break down structure and performance measures are maintained. And allocation and uses of budget and management reserve funds are tracked. Responsibility for the implementation changes is clarified. And the effect of the changes are visible to all parties involved. We know who's implementing in the change and it's monitored. Scope changes will be accurately reflected in baseline and performance measures. I learned about change control the hard way. This is one of my significant lessons learned, because I started with no change control process. Well as a project manager, you have a responsibility to help your team capture lessons learned throughout the project. The best practice is to gather these lessons as the project progresses. Too often we wait til the end, and then we only remember the big things. There are plenty of smaller lessons we learn along the way which can really help us do an even better job next time. It's embarrassing if you and your team make the same mistakes multiple times. Or become surprised by the same issues you faced on previous projects without having a solution for those issues. If you capture and publish lessons learned and you remember to refer to them you can prevent this from happening. If your colleagues do the same, well that's a wealth of knowledge that can be shared. The purpose of lessons learned is not for finger pointing. It's to really capture work and approaches to that work that went well, so that you can recreate the good and to capture what could've been better, so that next time it will go better. You can hold formal lessons learned review sessions. You know, specific times where everyone is invited to come and share what went well, and what could have gone better. You can also just keep a running list of these lessons as things come up in your regular status meetings. You might even occasionally publish some of these lessons with your status report. This helps to keep the idea of capturing lessons learned in front of everyone. Hopefully you are walking away from this module and from this course with plenty of your own lessons learned about project management. Now it's up to you to take these lessons and make them work for you. Wishing you every success and bye for now. [SOUND]
