Lesson 14: Issues and changes
- 00:05 - Issues and Change Requests. Let me start off with an example of an issue
- 00:11 - So, let’s say you are the Project Manager on a project and you assign work to a supplier
- 00:17 - The supplier has delivered, but you can see that there is an issue
- 00:22 - They were in fact using an old specification document, so an old description of what should have been delivered
- 00:30 - And you now must spend some time investigating how to deal with this issue
- 00:37 - So, this is a good example of an issue and you may say it’s a big problem, but you’ve got to find a way forward
- 00:43 - Of course, having a supplier to blame can come in handy, but it’s not good, you know
- 00:48 - We have to take some responsibility. There was some mix up and we’ve got to work and find the best solution to move forward
- 00:55 - Now that’s an example of an issue. What about an example for a change request?
- 01:01 - Well, request for changes can appear at any time in a project, okay?
- 01:07 - Sometimes the change requests look easy, for example, I think we had before in a lesson
- 01:12 - Adding a new payment gateway, that sounds easy, and we may think on a first glance
- 01:17 - Oh, that could take two or three days to do that, okay, but then later you find out
- 01:23 - Hey, this has an influence on lots of other areas of the application such as the invoice system
- 01:29 - And now it may take four weeks of extra time to fix
- 01:33 - So, the tip here is basically each request should be really carefully examined
- 01:39 - Think about the long-term maintenance and think about what changes this will have on the rest of the project
- 01:49 - Okay. So, that’s an example of both. Now let’s look at how customers can view change and suppliers can view change requests
- 01:58 - Okay, so from a customers’ point of view, well, customers are interested, should be interested in value for money
- 02:05 - Because they are paying for something and they want something to be delivered which will give them value
- 02:11 - So, they will want to approve changes that will bring a long-term value and ignore the changes that do not
- 02:19 - So, they will probably ignore lower value changes and wish to allow higher value changes to come in
- 02:26 - Of course, you’ll have some people on the customers’ side requesting changes that bring no value
- 02:33 - So, we should have a way of spotting this and lowering the priority of those requests
- 02:40 - But usually they work well and they’re really focused on the higher level value change requests
- 02:46 - Now from a supplier point of view because they are getting paid to do the work
- 02:51 - So, how do the suppliers view change requests?
- 02:55 - Well, again they should work to make sure that they evaluate the consequences
- 03:01 - They help the customer see the consequences of each change request they are doing
- 03:07 - They should come up with a number of suggestions on how to deal with this
- 03:12 - And then agree with the customer to determine the best way forward
- 03:16 - Now some suppliers of course will wish the customer to spend as much time as possible because for every piece of work
- 03:23 - They got to have a good margin, but that’s not always good and long term that doesn’t work
- 03:28 - And we should call these evil suppliers. Okay? We should always work in the best interest of the customer
- 03:35 - Now, what is the definition of a change request?
- 03:40 - Well, it’s basically a request for change to an approved management product, that’s what it is
- 03:48 - So, we have a document, let’s say, we have a project description
- 03:52 - It’s agreed, it’s signed off, it’s dated and before it has to be worked on, a change to a specification comes in
- 04:03 - So, that’s why we say it’s a request for change to an approved management document
- 04:09 - So, it’s an agreed document that we have actually worked on. So, we’ve got to then analyze that change properly
- 04:17 - Now this could be adding a new feature or it could be changing an existing feature that’s there
- 04:25 - We may even get a big request like the following
- 04:29 - You have a request to deliver the complete project 20% sooner
- 04:34 - So, you can imagine the impact that will have on the whole project
- 04:39 - So, really for a big change like this, request like this
- 04:43 - You really have to take time to analyze the change and see if it’s even possible to do something about that
- 04:50 - Now let’s look at how changes are escalated and even why we want to escalate change requests which are actually issues
- 05:00 - We call everything issues in PRINCE2 almost, so a change request is a type of an issue
- 05:06 - So, we wish to give the Project Manager some authority to deal with certain issues, so they can go ahead and do their normal work
- 05:14 - But PRINCE2 uses a certain technique as well called Manage by Exception, it’s a very good technique
- 05:23 - And what it says is that the Project Manager can work if the tolerance level is below a certain point
- 05:31 - So, if it goes above a certain threshold, then that decision is too big for the Project Manager
- 05:37 - So, that should be escalated to the level above, which is the Project Board
- 05:42 - And we call that escalating a big issue, let’s say, to the Project Board and then they make their decision
- 05:49 - Now when dealing with issues, PRINCE2 has a number of steps and it puts these steps into a technique
- 05:59 - They call it the Issue Management Technique or Technique for Issue Management and it’s quite actually clear
- 06:06 - So, it starts off with, I’ll read them out to you and then I’ll go through them one by one
- 06:11 - So, the first step is capture, assess, recommend, decide, and implement
- 06:15 - So, capture is about pulling in those issues and adding them someplace. We add them into a register file
- 06:22 - Then the next step is to assess those issues, so evaluate them with some other people
- 06:29 - Like in workshops or something or meetings and then we see, okay, what impact it has on the project and try to come up with some suggestions
- 06:39 - Or we look at the impact, we have a lot more detail about the impact of that issue on the project
- 06:45 - Then we recommend a solution. So, we recommend some responses on how to deal with that issue
- 06:53 - Now we just don’t recommend one because that’s not a good idea. There are always more than one ways to fix something
- 06:59 - So we should look at the fixing from one or more or three points of view and then put those on paper as well
- 07:08 - Then it’s up to someone to decide, okay, which is the best recommendation to fix this issue?
- 07:14 - So, they will decide and if it’s decided by somebody, then we can implement it. Okay?
- 07:20 - So, we can allow that change or we can fix that issue
- 07:25 - Good. We go over this practice much more in detail in …
- 07:31 - Sorry, we go over this technique much more in detail in the Issue Practice which we do later as well
- 07:38 - So, some other comments regarding evaluating issues and change requests
- 07:43 - The Project Manager should really have good facilitation skills here because that’s what they’re doing
- 07:49 - They will invite the necessary people to a meeting and discuss the issue
- 07:55 - Or the problem or the change request that they are getting and then collect the recommended options
- 08:01 - And then the output of that meeting can go into a report document and we can call this the Issue Report
- 08:08 - Now, sometimes some project managers think they have to present a solution, which is not good
- 08:15 - This is a really common mistake, especially for more technical orientated project managers
- 08:20 - They think they have to be the smartest person in the room. That’s not a good idea
- 08:24 - We should use the knowledge in the room and facilitate it
- 08:27 - So, the Project Manager here should just facilitate, ask the right questions and then get input from everybody
- 08:33 - We can come up with lot better ways of finding a way forward if we do that
- 08:39 - Great. Now let’s look at the timeline of how actually things are done during the project
- 08:45 - So, in the initiation stage where we do most of our planning
- 08:50 - We will agree on how issue management should be done during the project, so issue and change management should be done
- 08:58 - So, we have an approach document for this and there are nine approach documents in total
- 09:04 - One for how to do risk management, one for quality, one for benefits and we’ve got one for issue management as well
- 09:11 - Okay, that’s agreed. Then we also create the place to store all the issues and we call that the Issue Register
- 09:19 - So, this is where we want to store issues that need to be followed up formally, okay, with other people and we got to keep an eye on
- 09:28 - A spreadsheet is a good thing to visualise when you are thinking of that
- 09:33 - And each row in that spreadsheet can be an issue on its own, okay?
- 09:37 - And the Project Manager will actually review this issue sheet very often
- 09:43 - And then during the project when we do investigations
- 09:46 - We will then or the Project Manager will then create issue reports which adds a lot more information about that issue
- 09:54 - So, we can give it to someone and they can make, they can assess it and then decide what to do with that issue
- 10:02 - So, that’s a good overview actually on what happens on issue management within a project
- 10:09 - Now, what happens if we have open issues at the end of the project, so we haven’t fixed everything
- 10:16 - Well, let’s say we have a project to deliver an apartment block with 12 apartments
- 10:23 - And we ordered a big special lighting piece equipment for the lobby
- 10:29 - But this won’t arrive until about three months after the project is finished
- 10:35 - So, in the meantime we install temporary lighting and then when it comes to hand over the project
- 10:41 - To the people who will maintain the building, we discuss this with them
- 10:46 - We tell them, “Okay, this is an open issue. The big lighting we ordered will arrive”
- 10:52 - And then they will note this down and they will install it when it arrives later
- 10:57 - So, we can stop the project if there are open issues provided we make sure
- 11:03 - That these issues were handed over to the people who will take care of what we’re working on in the project
- 11:09 - Good. So, I think I’ve covered lots of different things
- 11:12 - The important thing, this is about issue management, which includes change requests as well
Quiz
- What is a request to change an approved “management product’?
- Can a change request also be for a new product and not just a change to an approved product description?
- The first step for a project manager when they discover a new issue is to capture it in the issue register. What is the 2nd step?
- Can the project board allow the project manager to make small decisions regarding issues, or is it better that the project board make all decisions regarding extra costs for the project?
- Who should facilitate the issue management steps (capture, assess, recommend, etc.)?
- What typically happens to open issues at the end of the project?
- In which document are issues that need to be assessed and added?
- We consider this a ‘request for change’ or ‘change request.’
- Yes. At the end of the initiation stage, the project plan will be approved, and the users can request new products during the project, and unique product descriptions will be created.
- The steps are capture, assess, recommend, decide, and implement. Assessing the issue is about evaluating the impact of the issue on the project.
- The project board can give some authority to the project manager: e.g., They can make decisions if the cost is less than € 10,000. If the impact of the issues is higher, then the project manager must escalate to the project board.
- Project manager
- The project manager will generally go over the open issues with the people who will take ownership of the project output at the end of the project.
- Issues register
Here you can submit your questions related to the content of the course. (For other questions, use the support system). The trainer's reply will be email to you in 48 hours.
The first lessons of the course, including this one, are available for free, even without registration.
You can purchase the course to access all lessons, additional material, and coaching:
More info and purchase options