PRINCE2 Practitioner – Introduction to Processes Part 2

4. Process No 2 Directing a project Part 2

Authorized initiation. The purpose of this activity is to make sure that only worthwhile projects get initiated. The Project Board receives a request to initiate the project from the Project Manager. The Project Board will check the project brief and the stage plan, and in fact, they may ask Project Assurance to help out with this. If they believe the outline business case demonstrates a viable project, then they will review and approved the project brief and the stage plan. And in case you’re wondering why the outline business case doesn’t show up as an input into this process, it is because it is incorporated in the Project brief. As you will see in page 175 of the Prince Two Guide, we have authorized a project which is self explanatory. Authorize a stage or exception plan.

Authorizing a stage is a safeguard against runway projects. Amongst non principal projects, continuous continuance is automatic, even if the reason to continue no longer exists. One organization I worked for very briefly boasted they applied the full prints too. This is an odd expression because there’s no such thing as applying an 80% Princeti or a 90% Prince. To be considered a Prince Two Project, you have to use all of it. Prince Day needs to be tailored to city’s Project, but you must never remove parts of it at this organization. I was brought in to manage a project because the Project Manager had left. We were approaching the end of a stage, and so I produced the end stage report and the stage plan for the next stage and called for a meeting of the Project Board. At the start of the meeting, I was asked what’s the purpose of the meeting? I had already explained this in the meeting agenda, and the meeting was called Authorized Next Stage. But apparently Project Board members this kept me were too busy to read emails. So I explained I was tabling the reports and requesting authorization to continue to the next stage. The Executive said, of course we’re continuing to the next stage, but we not want to explain to

authorize a stage or exception plan activity. But the Executive said we didn’t have time to worry about all this nonsense. That’s what we pay you to do to manage the project. So just assume everything’s authorized right to the end of the project. That was when I began to suspect that I’ve actually used in the full Princetow. Okay? Princeto has built all safeguards into the method for the protection of the organization and the stakeholders. So no matter how tempting, especially when you’re busy, you need to follow the method. And if properly tailored, it should not be a burden. The next activity is give ad hoc direction. The Pinnacle Guide says on page 187 giving ad hoc advice can include responding to requests, for example, when options need Care finder, when areas of conflict need resolving. Responded to reports eg. Pilot report, exception report, issue report.

Responded to external influences eg changes in corporate priorities. Project Board members individual concerns responded to changes in project board composition which may also require corporate program management or customer approval. Authorized Project Closure the controlled close of a project is as important as the control start.

There must be a point when the objectives in the original and current versions of the PID and Project plan are assessed in order to understand whether the objectives have been achieved, how the project has deviated from its initial basis. What that the project has nothing more to contribute. Without this approach, the project would never end. A project can become business as usual and the original focus and benefits will be lost. Authorizing closure of the project is the last activity undertaken by the Project Board prior to its own disbandment and may require endorsement from corporate programs management or the customer. The Project Board may appoint Project Assurance to undertake summer of the reviewing and assessmentions. For example, inspecting the end project report to confirm it is accurate.

5. Process No 3 Initiating a project part 1

Enabling the organisation to understand the work that needs to be done to deliver the project’s products before committing to a significant spend. That is from the Prince Street Guide, page one nine six I was mentoring a project manager a number of years ago and he told me he was concerned about his project. He said he had been told not to prepare a project product description because, as the management said, the product will change, so we don’t want to waste time writing everything down just to change it. He was also told not to bother with risk management because it makes everyone think negatively and they worry too much. He asked me what I would recommend to improve the situation and I said find another job. The initiation stage is your one chance to make sure that you’re doing the right project at the right time and in the right way with the right people.

Then give your project the best chance of survival. Every hour that you spend at an initiation stage will probably save you a day to a week later in the project by avoiding confusion and rework mainly and it will help save the project. Now in these early stages is a time when the organization has the greatest control over the project and for the least cost because nothing is committed yet. A large change at the early stage will be much easier and cheaper than a very small change nearing the end of the project. The objective of the initiative in a project process is to ensure that there is a common understanding of the reasons within the project, the benefits expected and the associated risks.

Please remember that as well as benefits, risks and cost, you also have to consider the disbenefits and the cost of changes to the organization to support the products once they become operational. The scope of what is to be done and the products to be delivered look at the benefits can be intangible as well as tangible. How and when projects products will be delivered and at what cost? Who is to be involved in the project decision making? How the quality required will be achieved? This will be dealt with by your quality management approach.

Our baselines will be established and controlled. How risks, issues and changes will be identified, assessed and controlled. This will be dealt with by your risk management approach of course how progress will be monitored and controlled who needs information, in what format and at what time. This of course will be dealt with by your communication management approach. How the corporate program management or customer method will be tailored to such a project?

Now the context initiating a project is laying down the foundations. In order to achieve a successful project, specifically all parties must be clear of what the project is intended to achieve, why it is needed, how the outcome is to be achieved and what the responsibilities are so that there can be genuine commitment to it. The initiating a project process enables the project board, via the delegate in a project process, to decide whether or not the project is sufficiently aligned with corporate program management or customer objectives to authorize its continuance. Figure 16. 1 shows us the overall initiative and a project process.

A request to initiate a project will be received during the direct and a project process. The request will normally come from the project manager, who will also submit the project brief, which incorporates project definition, which explains what the project needs to achieve and should include the background project objectives, covering time, cost, quality, scope benefits and risk, performance desired outcomes, project scope and exclusions, constraints and assumptions, project tolerances, the user or users, and any other known interested parties. The interfaces outline business case project description project approach project management Team Structure Rule descriptions references these include references to any associated documents or products. You can find out more about the project brief in Appendix A, point 19 because Appendix A is where you will find all outline product descriptions, the project brief will later be replaced by the project initiation documentation.

The project board will consider the tillering recommended by the project manager, which they will find in the project approach section of the project brief. The project manager creates the suite of management products which are risk management approach, quality management approach, change management Approach and communication management approach.

The communication management approach is normally created after the other three management approaches, as you can see in the diagram, because creating the first three management approaches often uncovers other communication requirements. But as we’ll see later, once you create your communication management approach, that sometimes uncovers risks which were previously missed, and so you have to revisit that as well. The final activity in the initiative project process is to assemble the project initiation documentation, the Pit. This is a combination of all the documentation developed during initiation that will be used to gain project board approval to proceed.

6. Process No 3 Initiating a project part 2

The project manager does the first cut of planning the Tailoring approach for the project. The aim is to minimize the bureaucracy and the burden on the project management team, but not lose the benefits of the principal system. The project manager needs to take care to document any changes to the organization’s standard project management method. If one exists. The project brief may already have an outline Tailoring approach, and you can see that as an input. And you can see the lessons log as an input too, because the project manager and the executive will have previously captured Tailoring lessons learned from previous projects and included them here. Figure 16. 3 prepare the Risk Management Approach activity Summary the Risk Management Approach, which was called the Risk Management Strategy in the previous version of Prince Two.

The Prince Two Two Nine needs to show what you’re trying to accomplish with risk management. It will define the risk management roles and responsibilities, how you’re going to manage risks in terms of tools and techniques. For example, risk Management impact matrix, risk Management plan, paredo diagram, that sort of thing. It will also record the intended timing of risk management activities. Risk management is covered in chapter ten, and as always, I would remind you the principal is not prescriptive, so you’ll find it will fit in with your current methods. Principal recommends the following actions review the tiering approach and its implications for risk management.

And when you are managing this project, it is important to record the lessons learned from the Risk Management and Risk Management Tailoring what worked well, what didn’t, what could be done better, and so on. Review the project brief to understand whether any corporate program management or customer strategy standards or practices related to risk management need to be applied to the project. Your project is a small temporary organization within the median organization, and as such it often has to adopt the overarching strategies of the commissioning organization or at least those held by program management. If your organization doesn’t have a strategy for risk management, Principal recommends following these steps seek lessons from previous projects corporate program management, or the customer and external organizations relating to risk management. Some of these may already been captured in the lessons log. Especially in a larger organization. It is rare to discover risks that have truly never been encountered before, but it’s very common to find risks which have been encountered many times but never written down. But check the lessons learned from previous projects. Look for risks that you may have overlooked so far in this project. Look at the treatments used and how effective they were so that you can benefit from hindsight. Make a big note from yourself all the way to this project. Any lessons learned, make sure you record them so that people don’t have to reinvent the delivery time. Review the lessons log for any issues and risks related to risk management. This step and the previous one seemed to be the wrong way. Wrong, but that is how they’re listed in the Prince Street Guide. Define the Risk Management Approach consult with Project Assurance to check that the proposed risk management approach meets the needs of the project board under corporate program management or the customer. Remember that the project manager role can be combined with team manager and project support even, but the project manager role can never be combined with Project Assurance, as that must be independent from the project manager role. Project Assurance is a board responsibility, but they often delegate it to others.

Create the risk register in accordance with the risk management approach and populate it with any risks from the daily log. Seek project board approval for the approach, although the project board may prefer to review it later as part of the PID, please tell me. Table 16 two for the duties related to preparing the risk management approach. Figure 16. 4 Prepare the Change Control Approach Activity Summary The purpose of change control is not to prevent changes, but rather to enable them after first check, and they need to be made and fully investigate the impact of the changes in the whole system and ensuring that they’re correctly authorized. They can then be made. Change management covers both the management products which are used to manage the project and the specialist products which are output from the system.

But please note that management products are not considered outputs of the project. The Prepared the Change Control Approach activity is very similar to the Prepare the Risk Management Approach activity, so I will cover it here again separately, but please study it for yourself on page 201 of the prints to guide and the same with the Prepare the Change Control Approach. It’s very similar to and that’s on page 301. Please also revise the Quality Management approach on pages 202 and 203. Figure 16. 6 prepare the Communication Management Approach activity Summary You will again find this activity similar to the others. The reason why it’s left to last is because when you create the risk change control and Quality Management approaches, they often uncover more communication dates.

However, please note that because of the interdependencies of activities, developing the Communication Management approach will probably in turn uncover more risks. And so when the Communication Management Plan approach is completed, you’ll need to revisit to Prepare the Risk Management Approach activity. I wish Prince Two use shorter names. Principal Guide tells us the Communication Management Approach addresses both internal and external communications. It should contain details of how the project management team will send information to and receive information from the wider organization or organizations involved with or affected by the project. In particular, if the project is part of a program, details should be given on how information is to be fed to the program, because often things that happen in one project inside a program can actually impact on others. Figure 60. 7 set up the project Controls activity Summary as you will see in page 305, the level of control required by the project board after initiation needs to be agreed and the mechanism for such controls need to be established, as does the level of control required by the project manager of the work to be undertaken by team managers. Project controls enable the project to be managed in an effective and efficient manner that is consistent with the scale, risks, complexity and importance of the project. Effective project controls are a prerequisite for managing by exception.

Project controls can include the frequency and format of the communication between the project management levels. C, chapter seven, for more information, the number of management stages and hence end stage assessments. C, chapter Nine the number and timing of the management stages is initially planned by the project manager and then finalized and authorized in conjunction with the project board. These need to be tailored to set the level of control required, the complexity and level of the risk of the project, and the availability of the project board. The goal is for the minimum pressure to be put on the project board whilst ensuring that the project is managed effectively according to the principle managed by exception.

Then we come to mechanisms for capture, analysis, issue and changes. C, chapter 911 for more details, mechanisms to monitor tolerances and escalate exceptions. C, chapter Twelve the point of the three levels of tolerance, project stage and work package is to apply the principle managed by exception. However, this can work only if the responsible parties have an effective mechanism for detecting when a tolerance has been or will be exceeded. Tolerances for delegate authority are explained more in chapter twelve. How delegated authority from one level of management to another will be monitored, and we can see more of that in chapter twelve. Please remember a project schedule is not a project plan. Always check out the glossary for words and phrases which you don’t know or ones which you think you do know. It’s always good to know what Prince Two actually says they are, in this case, project plan. The glossary is a high level plan showing the major products of the project, when they will be delivered, and at what cost. An initial project plan is presented as part of the Pit.

 This is revised as information on actual progress appears. It is a major control document for the project board to measure actual progress against expectations. You will need to study PIDS 208 for the recommended steps. You will notice from these steps as well as from Figure 16. 8, but this activity does much more than just create the project plan. Now. Figure 16. 9 refine the Business Chaos Activity Summary I know you’re probably getting an appreciation for just how busy the initiative project process is considering. It is preceded by the starting up a project process and compare that with a typical nonprint state project where much of this planning never occurs or is done on the fly as the project continues. Please note I said as the project continues and not as the project progresses, because work on a project with that assigned method, however busy, is not always progress in the starting up. A project process at bare bones high level business case called the Outline business case was created with just enough detail to enable the organization to investigate if a project is worthwhile. So now that that has been decided that it is worth going ahead, an option has been chosen that represents the best value for money from the available options.

Now we have to prepare for principle number one continued business justification, which insists that a project must be justified to begin and must be checked at the end of each stage to make sure it is worth continuing. Principle number one is tested against the business case when the project board is considering authorizing each next stage, and so that is why we take the time to build it out now and revise it throughout the project. Then, looking at figure 16 point ten assemble the Project Initiation Documentation Activity Summary this is the final activity for the initializer project process. The principal guide says there needs to be a focal point at which all information relating to the what, why, how, where, when and how much of the project is gathered for agreement by the key stakeholders available for guidance and information.

For those involved in the project. This information is created into the PID. The PID is an aggregation of many of the management products created during initiation and used to gain authorization for the project to proceed. It is not necessarily and rarely a single document, but a collection of documents or other forms of information such as flip charts, data and software tools, etcd. The version of the PID created during the initiating project process and used to gain authorization for the project to proceed should be placed under change control. It will be used later as a means to compare the project’s actual performance against the original forecasts that performed the basis of approval. And of course, it would be a disaster to say the least, if you were not looking at the correct version of the Pit.