PRINCE2 Practitioner – Introduction to Processes Part 5

14. Process No 7 Closing a Project Part 2

We have read lessons learned from previous projects that were relevant to closing the project. We also need to record lessons learned throughout the project, and then when we are closing it, you need to check that these have all been filed way securely and they can be easily formed again. It’s important to note that even if a project is closed prematurely, you must still record lessons learned. And lessons from a field project might prevent future projects from failing. Some people might feel that recording lessons learned from a project is a lot of work and they don’t see any immediate benefits from it. But sometime in the future, you may face serious and difficult problems in your project, and you may be saved by lessons learned from previous projects. Or the lessons might prevent you from making serious mistakes when planning your project. But those lessons will exist only because someone did the right thing and recorded them, not to benefit themselves, but to benefit future project managers just like you that they may never even get to meet.

There’s an old saying a society grows great when old men plant trees whose shade they know they will never sit in. So the next time you’re managing a project, tell your team to plant trees. Looking at figure 21 overview of closing a project reminds us that all projects, no matter how large, are temporary organizations. Their end is planned from the time they begin. In this process, we are either bringing the project to a graceful end and handing over the remaining products, or we may be terminating it because it no longer satisfies the principal continued business justification, in which case we will be salvaged in what we can to cut organizational loss. Look at even though the project is closing, a closure recommendation must be issued and that will bring closure to the project management team as well as to the project. Please read pages 260 to 261.

Activities the activities within the closing the project process are project manager oriented and are to prepare planned closure. Prepare premature closure handover products evaluate the project recommend project closure first of all, we can to prepare plan closure activity. This is a normal graceful end to a project. Before closure of the project can be recommended, the project manager must ensure that the expected results have all been achieved and delivered. But note this does not mean that all of the expected benefits have been realized, because often they won’t be realized until sometime after the project has been closed.

This just means that the project plan has been successfully applied. Principal recommends the following actions update the project plan with the crawls from the final management stage. Request a product status account from project support from the project status account. Ensure that the project’s products have been approved by the authorities, identified in their product descriptions. Meet all the quality criteria or covered by approved concessions. Confirm that the project has delivered what is defined in the project product description and that the acceptance criteria has been met. Seek approval to give notice to corporate program management or the customer that resources can be or are about to be released.

Table 20, part one, shows the responsibilities for the activity. Next activity is prepare premature closure. This is a similar activity to the planned closure activity, but there is a body of work around salvaging products and in some cases products may be left in a dangerous state. For example, walls could have scaffolding, containers of dangerous chemicals could be sitting around, they could be incomplete electrics and so on, and these will have to be made safe. Some products may be used in other projects or with some extra work that could be sold or auctioned. Some products will probably be complete or at least usable, but they can’t just be handed over. The project board should seek its approval from corporate program manager or the customer for the early release of materials and products and with equipment which has been leased for the project.

Attempts should be made to reuse the equipment on other projects elsewhere or perhaps to obtain a partial refund of the lease cost. Handover Products Activity the project’s products must be passed to an operational and maintenance environment prior to the project being closed. This may happen as a single release at the end of the project, or the project approach may include fierce delivery where products are handed over in a number of releases. In the case of premature closure, there may be some products that have been approved but have not yet handed over and dependent on the project board guidance. The ownership of some or all of the products may need to be transferred to the customer. That’s from the principal guide, page two six four. Evaluate the project Activity successful organizations learn from the experiences with projects.

When evaluating the project, the objective is to assess how successful or unsuccessful the project has been. It may also be possible to improve the estimation for future projects by analyzing the estimates and actual progress metrics from this project. That’s from the Prints Two guide page two six six. Prints Two recommends the following actions review the project’s original intent as agreed in the initiation stage and defined in the Pit be assigned at that time. Review the approved changes as defined in the current version of the components of the Pit in consultation with the project management team, prepare an end project report.

Please read pages two, six six and two six seven for information and finally, recommend project Closure activity. After the project manager has confirmed that the project can be closed, a closure recommendation should be reissued to the project board. Figure 2. 6 shows the inputs to and outputs from this activity. Prince Two recommends the following actions use a communication management approach to identify any organizational or interested party who needs to know that the project is closing. Consider also communication activities for public relations and marketing opportunities at this point.

Close the project’s Issue Register Risk Register Quality Register Daily Log and Lessons Log make sure that all project information is secured and archived in accordance with the change control approach in order to permit any future audit of the project management team’s decisions, actions and performance. Finally, prepare and send a draft project closure notification for a review by the project board stating that the project has closed.

15. Introduction to Tailoring the processes

Firstly, Princeton tells us that tailwind may range from being rigid and prescriptive through to allowing the project management team a large degree of freedom as to how they implement each thing. But obviously there are constraints to be observed. For example, if you have a large, high risk and high impact project, it would not be sensible to give the team a large degree of freedom. And on the other extreme team, if you have a simple low risk project lasting three days, said you’re unlikely to be rigid and prescriptive because the overhead of all this control would probably cause you to miss your deadline and cost more to implement than the benefits from the project. It’s all about striking the right balance, applying just enough control to ensure the success of the project, but without burdening the team more than absolutely necessary.

There are times when we are required to be rigid and prescriptive, even when the project itself does not seem to warrant it. And this is usually in the case where our project has an interface with another organization that is normally rigid and prescriptive. Quite often it’s government military, but other organizations as well. For example, a number of years ago I was developing a stock trading system, first of all, financial management company in Australia. This system was not very complicated, especially as I had managed similar projects before and my specialist developers were very experienced in this area too. So if I were given the free choice, I would have given them quite a high degree of freedom and kept reporting to a minimum.

And on a project that size I would not have needed, for example, project support. However, the financial management company had very strict internal procedures and tight governance, and the customer’s executive was very strict and insisted on frequent and detailed reporting and seemed to think of tailoring as taking shortcuts, which it definitely is not. But you might recall that the top level of the project management structure is corporate program management or the customer. So if you’re delivering to a customer, they’re at the top level and they can pressure you to change the tailoring. Please remember for the exam corporate program management or the customer make up the top level of the project management structure. But they are not part of the project management team. They are outside it and above it.

And it is important to note that the tailoring applied to a Prince Two project is not ringed either. You will need to adjust the tailoring as the project proceeds to ensure the best balance. Next point is where do we record the tailoring so the team can forward? And for this answer to the question, we check the Prince Two guide again. On page 43 we find a tailored prince to a theme should reflect any tailoring of the processes and terminology. Tailoring a theme does not necessarily mean rewriting the printstry theme itself. In most cases the themes are implemented through the project’s risk, quality, change, control and communication management approaches. They should contain procedures regarding how the themes are implemented in practice for that particular project.

The level of control required will influence the degree of formality and frequency of monitoring, reviewing and reporting. So that’s their answer. They’re stored in the approaches and approaches how you go about doing something. And in the previous version of Princeto, approaches were referred to as strategies. But these approaches are the practical details of how we’re going to go about managing the project in the areas of risk, quality, change, control and communication. And as the project progresses, rather than the team members needing to read the prints to guide check up in the tailoring for their direction, they will just look in the project approaches, because that’s where the tailored information has now been stored. And that is why it says you don’t have to rewrite the thing. The terminology can be tailored to suit the customer’s organization as well. This often helps buy in because the organization staff don’t have to learn strange new words. You have to learn their strange new words instead. And so you might have to say asset management instead of change control or work breakdown structure instead of product breakdown structure. In fact, the names of the processes can be changed too. The last point I’d like to make is also a very important one, and that is tailoring can be up or down.

Most people think that tailoring always means reducing, but it can mean increasing too. Tailoring up or down means that we increase or reduce the formality, the complexity, the frequency or the lift of detail and bonnet management products and associated procedures. The other area commonly tailored is in the roles. We can split them or join them in a number of cases and increase or decrease the level of rigor and the number of duties and the reporting structures and the levels of authority. When you are tailing the roles upwards, you can split the project management role into project manager and project support, for example. And when tailoring done, you can combine the project management role, the project support role, the team manager role, and in extreme cases, you can even combine the specialist team member roles with project manager as well. But as I’ve mentioned a number of times before, when tailor enrolls, you must be very careful to maintain the integrity of the roles.

For example, you can’t allow the project manager to make decisions that an executive should make. You must have exactly one executive and one project manager on any project. And you must avoid conflicts of interest by the roles as well. For example, the project manager can’t be involved in project assurance, nor in releasing funding or change in the state’s tolerances or authorizing the next stage. And as well as only one project manager, there must be only one executive on the project too. These core duties of these roles can’t be split. Only non core duties can be split each year.

The executive is a final decision maker on the project board. And so this is a core function of the executive and can’t be split to another role. But I will add a twist to the statement there can only be one project manager on any project. A few years ago, I was training engineers in project management at an iron ore mine in the northern part of Western Australia. And when I said to the trainee project managers, there can only be one project manager on any project, I saw a lot of pistol faces, and one of them put up her hand and she said, what about changeover? I had no idea what changeover meant. And I asked her to explain. And I discovered that mining workers in Australia and Canada, and I’m sure other countries too, are referred to as FIFO workers. Fi f o. If you work in it, you might immediately think FIFO means first in, first out. Not quite. In mining, it means fly in, fly out. So a project manager would manage a project for typically two weeks, fly home for a week, then fly back to the mine and return to the project.

They can’t afford to let the project stop every time a project manager flies home. And so, while five full project managers are managing a project, they work a lot, maintaining a very comprehensive set of project documents. And then when they’re flying out, their placement manager, who’s just flown in will be able to see exactly where the project is at and what they have to do. Therefore, I changed my statement to there can be only one project manager manager on any project at any one time. Because in the FIFO model, there is never a time when the fly out and the flyin project managers are managing the same project at the same time. They may be exchanging information, et cetera, but not making project management decisions. Now let’s have a look at the tailoring guidelines for each printer process.

16. Tailoring the Starting up a Project, Process

First of all, we will have a look at the management products which are in table 14. 7, the guidelines for tailored products in starting up a project on page 177. And for each one of these processes we will examine the management products first and then the roles of the team members. The first product to be tailored is the lessons log, with the lessons of value to the project to record it. The principal guide says it may vary in respect of the formality used. Formality relates to the strictness of procedures. This means that if the formality is low, the project manager will record the lessons and somebody else may check them and they may be recorded in a document or in a spreadsheet or even handwritten. So that is low formality. Everything is basic and simple.

But if the formality is high, then there may be a rigid procedure in place with specific roles who will be responsible for validating in the lessons and they might require an official meeting. And signatures may be required to authorize the lessons to be accepted. This time, instead of a simple document, the information may be stored on a software application specifically for authorized and storing, retrieving and archiving the lessons learned. The second management product to be considered for tailoring is the project brief, which includes the outline business case and project product description. Again, we are considering tailoring down first of all, which means low formality. At a minimum, the project brief may be just one page of information.

It could be a document on a computer or printed sheet held in a ring binder. The details of the team may be quite vague and the role descriptions may also be vague. For example, the senior user role description may simply state someone who can represent the business users. At a minimum, the outline business case and product descriptions may take up only one quarter of a page. The product description may simply state what is required. For example, install lights and cameras in the car park. And the outlined business case could be a simple statement of why we want to do this. For example, to increase security and safety for the staff and customers and to reduce theft from cars. So that is a project brief tailored downwards in a simple project. Now let’s think about tailoring the project brief upwards, as you would do in a complex project. This time, instead of being a single page, we would have a number of detailed pages and we would expect to see references or links to other documents such as feasibility studies, market research, case studies and so on. The team structure should be in an advanced state. A range of possible solutions may already have been listed.

If not, it will include a reference to the project approach which will explain how the solutions will be obtained. The outline business case, instead of any few lines on a simple project brief would not be quite a large, complex and detailed document covering a number of pages and the project product description should also be very comprehensive. The last management product to be considered for tailoring in the starting map of project process is the stage plan. At a minimum, this could be a simple list of what needs to be produced in the next stage, who will do it, when is expected to be done. On a large project server, we can tailor the stage plan upwards to include computerized schedules with activities and responsibilities, charts and diagrams.

The role to be tailored in the starting of a project process is that of the executive. On a simple project we can tailor this down so that the executive creates the project brief and the stage plan. And remember, it’s not a big task because everything would fit into one or two pages. But if we want to tailor up the executive role for a complex project, the executive could enroll the project manager to create most of the management products. However, it is likely that in a tailored up project, the executive would still produce the outline business case with the help of the senior user. And that is all there is to tailor in the starting up a project process. In a simple project, the project brief and stage plan could be very simple. Documents created by executive, it could all be one document. And in a complex project, the project brief and stage plan could be large, complicated and cross referenced. Corporate portfolio, program or customer documents or reports created mainly by the project manager. The project manager role is not mentioned explicitly in the tailoring guidelines of the starting up a project process. However, they are mentioned in the text. Basically, minimum tailoring for this role is there’s no project manager assigned until the initiation stage. And if we tailor up, we do have a project manager in the starting of a project process to produce management products. For more guidance and roles, please see chapter seven and for the outlined product descriptions you’ll find all of the in appendix to which I’d strongly recommend you to become very familiar with before the examination.