1. Home
  2. Training Library
  3. 11. Theme: Change

Change - Part 2

Developed with
QA

Contents

keyboard_tab
PRINCE2 Foundation
1
Change - Part 1
PREVIEW8m 5s
2
Change - Part 2
PREVIEW7m 4s

The course is part of this learning path

PRINCE2 Foundation
course-steps
21
certification
3
description
2
play-arrow
Change - Part 2
Overview
DifficultyBeginner
Duration32m
Students213
Ratings
5/5
starstarstarstarstar

Description

The course focuses on the components of the method and how they help to structure project delivery. Delegates should note that evening work will be assigned which is not expected to exceed two hours per night.

Specific course content will include:

PRINCE2 Overview

  • The structure of the method and the guide will be introduced before we discuss the context within which a PRINCE2 project operates.
  • Principles
  • The seven PRINCE2 principles provide the framework for managing the project and are built on good practice developed from successful and failed projects.
  • Themes and Processes

Themes

The seven PRINCE2 themes are aspects of the project that must be continually addressed and integrated as the project journeys through its life cycle.

  1. Business Case
  2. Organization
  3. Quality
  4. Plans
  5. Risk
  6. Change
  7. Progress

Processes

The seven PRINCE2 processes encompass the chronological activities that are required to direct, manage and deliver the project successfully. The activities include pre-project, initiation and delivery, and end with project closure.

  1. Starting up a Project
  2. Directing a Project
  3. Initiating a Project
  4. Controlling a Stage
  5. Managing Product Delivery
  6. Managing a Stage Boundary
  7. Closing a Project

 

PRINCE2® is a [registered] trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved

Transcript

- Welcome to module 11, part two where we continue our discussions of the change theme. Here we're going to be talking about the requirements within Prince2 to deal with change and the management products as well. There are a number of requirements and the first is that we have a defined approach. We must discuss in our define approach step here how issues are going to be identified and managed. And we're going to record all of that in the change control approach management products, and you can see one of these if you want to look at it more carefully in appendix a of third entry. And the change control approach tells us how and by whom the projects products will be controlled and protected. So we're going to say who is going to be allowed to approve changes talk about any techniques and reports, and tools that we're going to use there. And we may have already got a corporate strategy for such things that we can reuse. So, it depends on the complexity of the project, as to how much depth you're going to go into here. But we definitely need one that's a requirement. We also have a requirement to create, to maintain, and control the baseline. So we need to define in our approach how baselines are created, how they're maintained and controlled. We also will have an issue register we need to keep that updated. So all those requests for change and all specifications and problem concerns will go into an issue register and so that's another official management product for us. Entry A. 12 in appendix a, and here we capture and maintain information on issues that are going to be formally managed. Now the project manager, if your experience is anything like mine you'll know this, there's an awful lot of issues that get raised here that you actually can deal with very quickly and informally. Now those will stay in the daily log. A document there, actually I've got notebooks, that act as my daily log. In fact my inbox acts as a daily log, and so does my sent out, sent mail folder as well. Because I will use those things to refer to when I'm writing reports but if I need to deal with an issue formally it will have to go into the issue register, and be tracked accordingly. We also need to think about a change all the way through the life cycle so we're not just going to set it up for stage two, and three. We need to have it right from the start, and think about how we're going to do this consistently throughout the project and that will be defined in our change control approach also. And another requirement is that we think about our principle of learning from experience. We're gonna use the lessons we've learned early on in the project to inform and improve how we do things in the future. So it might mean that at a stage bound you re-pause and reflect and we think hmm, we better change our change control approach to deal with things in a better way. So those are requirements and our official management products. Another thing to tell you about while I'm here is that we do have the facility to have a change budget here in Prince2. And a change budget is a sum of money that the customer and supplier agree will be used to fund the cost of requests for change, and possibly their analysis costs as well, so kind of paraphrase that quote there. But you can find that in the manual. And this is actually a very useful thing to think about. We will write down in our approach that we're going to have a change budget, if we decided to have one. And we'll write down how much it's going to be in our project plan. And having one and thinking about what we're going to do if we have a change. Having a change budget means that people when they have to make decisions already have a sum of money set aside to deal with the change. And this reduces a number of exceptions that we might have in the future. We might for example have a situation where there's a major change requested, the project manager thinks that major change is a good idea, but we don't have any money to make that change so we have to escalate it. Now whilst if there was a change budget set aside, and it's all ready to be used for changes like this, well then the project manager can just say well, we've decided to make that change or change authorities decided to make that change. No problem, we'll just implement that change, using the change budget to pay for it. So having a change budget will reduce the number of exceptions and we like that because whenever there's an exception at stage or project level we have to wait for the decision from the appropriate level to filter down to us. And so this causes delays. And having a change budget means that we have a much more realistic expectation of what it's going to cost overall. So the more experienced you are in project management the more you're likely to agree with me on this but we never get the cost right. There's always unexpected change requests and got overrun in terms of cost. If we don't think about this in advance well it might set that change budget to be, as realistic as we can and that will give everyone a better idea about what the final cost is like to be. One thing also to note here is that we need to think about what the delegated change authority limits are and I mentioned there in pausing the project manager might approve a change and that is allowed if the board allow it anyway. The board might decide that the project manager can authorise change up to 1000 pounds it doesn't delay the project by more than a day and so those small change requests they will delegate change authority down to project management to decide. It might be that the board won't change any above 1000 pounds or delays the project by more than a day goes up to a separate change authority. And anything above I don't know 10,000 pounds, delays the project by more than a week, that goes up to the board. So the board decide where those levels and limits are going to be. We record them in the approach. So everybody understands who has authority to do what regarding change. And that includes how much money they can spend so the cost of a single change, and the amount that they can spend in any one stage. So that actually is the end of part two.

About the Author
Students1502
Courses21
Learning paths1

A hard working, self-motivated and dedicated IT Consultant with extensive experience and a proven track record in the areas of Management, Networking, Communications and Security. A capable organiser, quick to grasp and make good use of new ideas and concepts. Reliable and conscientious in all work aspects. Possesses exceptional interpersonal skills and utilises communicative abilities to build, develop and maintain effective relationships. A motivational and inspirational manager, who enjoys being part of a successful and productive team, and thrives in highly pressurised and challenging working environments.