- Welcome to Module 15. We're going to be taking a look at the Directing a Project process. We'll be looking at the purpose, the objectives, and the context of the process. And we'll jump straight into the purpose of directing a project process which is quite lengthy, but I've just taken the full quote from the manual there in Section 15.1. The purpose of the directing a project process is to enable the project board to be accountable. It's that accountability that I want you think of there. If you see that word accountable for project success, think the board and directing a project process. They're accountable for the project success by making key decisions. That's what they make. They're not really making management products. All they make are decisions. And by doing so, they exercise overall control. While of course delegating all the hard work, the day to day management, to the project manager. So it's all about accountability, key decision making, overall control, so there's some keywords there. I've given you the objectives in full and bolded some of the keywords in there. Our objectives there are to make sure there's authority to initiate the project, and to deliver then, the project's product. So it's all about authority and having authority. We need to make sure there's management direction and control provided throughout the project. And that the project remains viable. They are going to make decisions on project viability, so they are going to be very interested in reading any end stage reports, end project reports, so that they can make that decision, "is the project still viable?" And if it's not, then you've got to seriously consider closing the project down. They also are the interface with corporate programme management, or the customer. We never skip a level in the hierarchy. The project manager might need some major decision made that will have to go up to corporate. But they never go direct. They always go through the project board and the board then liases with the corporate programme management, or customer levels. They are also going to be there all the way through. They are constantly available and they will definitely be there at the end, because they need to, as the board, close the project formally and so they need to have authority to do that. And they also, as the project board, are going to be thinking about beyond the project. Because this project is being started in order to deliver some kind of change or new capability for the organisation to get some benefits. But the project will not be around usually to see those benefits, that's that post project period there. Where hopefully there's going to be some positive measurable change. Now the project team may have gone home, or at least to another project, but they may not be in the organisation anymore even. They might have moved on outside. So who's left? Well, probably some of the members of the project board will be around. But they need to also look at plans to make sure that other people, in business as usual, are measuring for benefits. So they're definitely going to be focused on that. Quite a few objectives here. If we look at the context, and we're in Section 15.3 here if you've got the manual handy, you'll see this diagram. And again they do like these diagrams, they're fairly complex. We're going to break it down and focus on the activities within directing a project process but we also, you can see there's an awful lot outside it, because most of the other processes link into directing a project process. So let's step away from this diagram, feel free to annotate your version of this diagram with the notes that I've added to the following slides. So the directing a project process is triggered once the starting upper project process is complete. So the project manager is being busy, writing the project brief and the initiation stage plan, and now they need to make a decision, or the project needs to make a decision. Do we authorise initiation or not? And it's the board that make that decision. So the very first activity is for them to gather together to authorise initiation. And in fact actually they don't even physically need to be in the same room. If they have all read the project brief, and all read the initiation stage plan then they, maybe via email, have decided that everything is fine, then as long as there's consensus they might even authorise initiation via email. Really, I'm not keen on meetings around here in the Princeton environment. So however they've done it, the project board have read everything they're given, as they always do, and they've made a decision to authorise initiation. That means they have now allowed the project manager to start their next process: the initiating a project process. Of course the project manager is very busy here in the initiating a project process because this is where they write the PID, the Project Initiation Documentation, a filing cabinet if you like, of lots of different documents. They are then going to give to the project board to read. Everybody reads everything they're given because of course that is best practise. So that means that the project board members are going to read every single document in that PID. And they're going to do that, before they authorise the project. If they're not happy with what they see then we might have to go back to initiating and the project manager is gonna work back down there improving things. And we'll try again to authorise the project. And the arrow hasn't been shown here, but there would also be a link up to corporate, the programme, the customer, to tell them what our decision has been. There's always the ability for the board to communicate with corporate, but for simplicity's sake we've left those arrows out. So hopefully, the PID is acceptable to the board, they've approved it, and they allow us to start the project. Except, we've got a slight problem here, they've authorised the project, but they haven't authorised the stage plan. Because we haven't made one yet, as project manager. So the project manager has got busy in managing a stage boundary process. They have been working there to create a stage plan and an end stage report. Summarising how the initiation stage has gone, and how we think the rest of the project is going to go. So they will send up their stage plan, and their reports to the board and guess what, the board reads everything they're given. And so they will take a look at that and decide whether or not they authorise that stage plan. Now there may be in the future exception plans but they also carry out this activity, reading stage plans and exception plans so the activity is slightly longer. But for this first time they're gonna authorise a stage plan for the first delivery stage. So once they've authorised the project, and the stage plan, now the project manager can start working on authorising work packages, and they do that in controlling a stage process. So the project manager is negotiating with the team managers there but the board is always around if the project manager needs advice, or decisions need to be made. And that we call that activity, "giving ad hoc direction." So these two activities, give ad hoc direction and authorise stage or exception plan, we'll go through a number of times, depending no how many stages we have. But the board are always there to give advice when required. So eventually the project manager has handed out the work package, most of them have come back, and they're doing all that and controlling the stage. But they're starting to think about the next stage. So from controlling a stage, they move into managing a stage boundary, and then, they're going to make a new stage plan and that's going to go up to the board. They've got to authorise it. That then allows the project manager to start the next management stage which they will try to control, using controlling a stage, and in the end of that they'll go into managing, managing a process, so basically there's a bit of a, I used to think of it as a washing machine cycle, where we go round in cycles. And it depends on how many management stages you've got. But eventually, we're going to get to the final delivery stage, and the project manager is going to be controlling that stage. And they're going to be starting to think about closing. So they will close the project. And they will carryout the handover, and make an end project report and generally gather lots of information. So this is the final activity for the board. They will have to read all of that documentation regarding closure and if they're happy with what they see, then they will authorise closure formally. So those are the five activities that the board carry out. They authorise initiation. If it gets initiated, then they hopefully authorise the project. And then once the delivery management stages are underway, because they've authorised the stage or exception plan, then they are there to give ad hoc direction. So it's those two that they're constantly going in and out of as we go through the next management stages. But at the end they're authorising project closure. So actually from that very complex diagram, it's very very simple for the board. They read everything they're given, and they make decisions. Now we give those decisions, and those activities for those decisions, different names. But that's really what they're doing. And if they can't deal with it themselves they will then escalate it up to corporate level. The only process that hasn't been involved here is managing product delivery, because the board, in directing a project process, will never directly interact with the team managers down there. The project manager is always going to be buffering them. So, that's it. That's the Directing a Project process. On to the next one!