PRINCE2 Practitioner – Introduction to Processes Part 4

10. Process No 5 Managing Product Delivery Part 2

Shows how the three activities from this process are connected. Please remember that managing product delivery is from the viewpoint of the team manager. You can see from this diagram. The team manager accepts a work package and receives authority from the project manager to action it. It is important to remember that a work package is not a product. Think of it as a package of doc payments used for creating the product and for tracking the product. Next, the team manager executes the work package according to the instructions contained within it. The team members create the product and lastly, the team manager updates the work package and returns it to the project manager. There may be several work packages issued within a stage and sometimes a lengthy work package can span more than one stage.

Accept a Work Package the work package is how the project manager describes the work required to be delivered onto the work package. But of course, it would be useful for the project manager to discuss the work package with the team manager as well. To ensure the team manager knows exactly what has to be delivered, what the tolerances and reporting requirements are, and who will receive and approve the product, the team manager may negotiate the work package constraints. The work package also represents an agreement between both parties looking at Figure 18. 2. Accept a Work Package activity Summary the work package will usually reference documents in the pit and that’s why it is shown as an input to the activity as well as the work package itself.

The team manager will then create a team plan and you will see this as an output from the activity. If the project is to be completed by the organization staff, then the project manager may review and authorize a team plan. I’ve seen this happen in organizations where the project manager is an expert in the specialist work and can really add value to the team plan. Execute a Work Package Activity the work has to be executed and monitored to the requirements defined in the authorized work package. While developing the products, the team manager should not exceed the work package tolerances agreed with the project manager.

The team manager can only proceed with the work package or take corrective action while the work package is forecast to remain within the tolerances set by the project manager. As soon as the work package tolerances are forecast to be exceeded, the team manager should raise an issue to the project manager who will then decide upon a course of action that’s from Principal Guide page two three nine. Figure 18. 3 shows the inputs to and outputs from this activity. And lastly, we have Deliver a work package activity.

This is simply the completed work package being returned to the project manager. Bridge Two recommends the following actions review the quality register to verify that all the quality activities associated with the work package are complete. Review the approval records to verify that the products to be delivered by the work package are approved. Update the team plan to show that the work package is complete. Check the work package and follow the procedure to deliver the completed products, notify the project manager that the work package is complete.

11. Process No 6 Managing a Stage Boundary Part 1

Is to enable the project manager to provide the project board with sufficient information to be able to review the success of the current management stage, approve the next stage plan, review the updated project plan, confirm continued business justification and acceptability of the risks. This happens around the end of each management stage, and just before this, you often see the project manager, team manager and team members put it in a superhuman effort to ensure that as many loose ends are tied up as possible before the stage end report goes to the project board. Despite all best efforts, especially if a number of issues are encountered or work packages have exceeded tolerance or are forecast to exceed tolerance, the project manager may have to concede that the stage is going to exceed stage tolerances. Then the project manager is going to have to report to the project board by way of an exception report and ask for advice. The advice is usually to replan the stage, but in an extreme situation the project board might ask for the entire project to be replanned.

If this happens, the project manager will deliver a revised plan called the exception plan, and then work with the project board until it is approved. Objective this is directly from the principal guide page three, four, six because it’s quite a detailed list and I don’t want to miss anything out. The objective of the management stage boundary process is to ensure the project board that all products in the stage plan for the current management stage have been completed and approved. Prepare the stage plan for the next management stage review and if necessary, update the Pit, in particular the business case, project plan, project approaches, project managing, team structure and role descriptions. Provide the information needed for the project board to assess the continuing viability of the project. Record any information or lessons that can help leader management stages of this project and other projects. Request authorization to start the next management stage. For exceptions, the objectives of the management stage boundary process are to review and necessary update to Pit, in particular, the customer’s quality expectations, project approaches and controls and role descriptions. Provide the information needed for the project board to assess the continuing viability of the project. Prepare an exception plan as directed by the project board.

Seek approval to replace the project plan or stage plan for the current management stage with the exception plan. The above is often tested in the exam and sometimes they ask a tricky question about the final management stage. Normally, the final management stage doesn’t have managing a stage boundary process because this process is for planning the next stage and there won’t be a next stage. However, there is an exception to this and that is where the project manager has been asked to make an exception plan. Context Pitched two projects are divided into management stages and as you will recall, the minimum number of stages on any project is to an initiation stage and one out there management stage. In general, the final stage will not have a manager stage boundary process.

And so that means the number of managing a stage boundary processes you will have is at least one. Dividing the project into a number of stages makes it easier to control. And the managing a stage of boundary process helps to keep the focus on the progress and the justification to continue. The project manager will employ a range of techniques to keep the stage within tolerances but with best efforts this may not be possible. And in such case the project board has the option of replanning the stage, replanning the entire project. Or if the justification can be found then this can be where the project can be termed it. Bridge two sees termed it in a bad project is beneficial to the organization, prevents further losses.

12. Process No 6 Managing a Stage Boundary Part 2

The project is divided into a number of management stages, which applies the principle managed by stages. The project board delegates the day to day project management within each stage to the project manager, which applies the principal managed by exception. However, the project board says tolerances for the stage, which the project manager must keep the project within a stage of binary is a point where one stage ends and the next one begins. And that is why the final management stage for a project does not have a managing a stage boundary process because it doesn’t have a stage boundary. A managing a stage boundary process is triggered by a stage boundary approach and as you can see in Figure 19. 1 Overview of Managing a stage boundary. The initiating a project stage, which you can see at the bottom left, is not a management stage.

However, it does have a stage boundary and so it requires a managing a stage boundary process to create a stage plan for the next stage. Now let me come to the activities. The managing a stage boundary process is from the viewpoint of the project manager. The activities are plan the next management stage, update the project Plan, Update the business case Report Management Stage and Plan the next management stage. This is done near the end of each stage except the final one because the final stage, as I said before, doesn’t have a stage boundary. Instead, the final stage has a project Closure activity. Although this activity is focused on the project manager, Princeton says that the project manager should actively consult with others when creating the plan, discussing it with the project board, project assurance team managers and other project stakeholders that will make the stage plan more robust. Figure 19. 2 plan and Next Management Stage activity Summary shows the inputs and outputs Princeton says to check with Paid for any changes to the customer’s quality, expectations, exception criteria or project approach.

The relevance and suitability of the approaches and controls the changes to the project management team. Please read page two four nine for details of creating the next stage plan. Update the project plan activity. Please see Figure 19. 3. Update the Project Plan Activity Summary the project plan is the bin tool used by the project board to measure project progress, and so it is essential to have up to date figures and information. And so what a stage boundary? The actuals are updated with information from the current stage. The project manager will also provide forecasts for the next stage which have been included in the stage plan or the exception plan. You can read more about this on page three five, one of the principal guide.

Update the Business Case Activity I can’t stress enough that you need a scientific knowledge of the business case before going into the exam. This is a central document that is required to select and initiate the project. It is updated at each stage boundary and check to see if the project should still continue according to the principal continued business justification, the executive is responsible for the business case, and so the project manager will need to consult with the executive when updating it. Figure 19. 4 update the Business Case Activity Summary as soon as the inputs and outputs, you can read details of this activity on pages two five one and two five two. Report Management Stage and Activity the principal guide says this activity should happen as near as possible to the actual stage end. In this activity, the project manager will report on whether or not the project is likely to meet the requirements of the project plan and the business case and realize the expected benefits.

This report should be available to the whole project team and not just to the project board. You can read the details of performing this activity on pages two, five, three and two, five four, and finally become to produce an exceptional board activity. Page two five four says if a management stage or the project is forecasted eviate beyond its agreed tolerances, it no longer has the approval of the project board. Exception plans are requested by the project board in response to an exception plan. Although an exception plan will be produced prior to the plant management stage boundary, it’s approval by the project board marks and management stage boundary for the revised management stage. Planning is not an activity undertaken in isolation.

The project manager will need to consult with project board members, project assurance, team managers, and possibly other stakeholders in order to create a viable plan. The more people involved in this planning, the more robust the plan will be. Please see chapter nine for more details on planning. Figure 19. 6 shows the inputs to and outputs from this activity.

13. Process No 7 Closing a Project Part 1

You can read more about that on the Pinstooth guide, page two 60. Let’s have a look at the objective. The objective of the closing a project process is to verify user acceptance of the project’s products. You may find that your users will need some help with this. They are often afraid to sign off on a project in case they miss something and take the blame for it. You can help by producing test scripts and checklists from the project scope so they can take these off step by step. And when the lists have been ticked off, then they will feel more confident in sign. And it helps you too, because then you will have confidence that there isn’t a serious problem that the users fail to pick up.

Ensure that the host site is able to support the products when the project is suspended. And make sure that you have produced all the necessary support documentation and provided training where necessary. Or you will find that support requests will come back to you. Review the performance of the project against its baselines. It says any benefits that have already been realized, and update the benefits management approach to include any post project benefit reviews. Ensure that provision has been made to address all open issues and risks with follow on action recommendations. That’s actually a very important point.

Some project managers delay closing the project because they believe that the project should deal with every open issue and they’re completely finished. And so your project never actually closes. Prince Two is very clever. Be like Prince Two. Okay? Our project has a limited lifespan. We’re looking at the context now as it is a temporary organization. Prince Two defines a clean cut off point at which you can announce the project is now closed. And then you can hold your wild celebration party or start looking for a new job, depending on how it went.

And an important point about closing a project is that you can formally hand over support of the projects so the products to the organization support team. Without a divisive closure, the project can become quite messy and never actually ends. And so supporting just keep on knocking back all the support work to the project team. A friend of mine was managing an information technology project in Canada and wanted some advice. She said that she was getting continual support requests from the products that her project had produced.

And she wanted to know how to get the organization support team to look after them because the products had been completed, but they were still keeping the project team busy. And her team had a backlog of enhancement requests, but no time to get around to do them. By the way, backlog is one of those words that’s different in prints too, from the everyday meaning of backlog. Please make a note to check up the meaning of black backlog and the glossary. In fact, make a note to read through the glossary now and then and it will really boost your understanding of Prince Two and boost your chances of passing the principal exam easily.

After talking with her for a while, I realized that the project had been running for almost three years, yet it was supposed to close after seven months. And although all the products had been handed over about eleven months, there had never actually been a formal closure. This meant that the managers viewed it as a wish granting machine and kept submitted enhancement requests. And so it became a never ending story kept alive by scope creep.

And the support department worked quite rightly in my opinion, refusing to accept report requests because with the project still open and products continually being enhanced, the products were technically still under development. I told her to formally close the project and warned her there would be a fight with management, but go back to the original scope and get the users to accept it. With the amendments which have been accepted up to this point, then a new project should be initiated for the backlog. She took my advice. She did it. There was a fight and she won. Make sure there’s a clean closure to your projects.