How to Become a PRINCE2 Certified Trainer

Becoming an Approved PRINCE2 Trainer and being sponsored by an Accredited Training Organization means that you can provide accredited PRINCE2 training. The market for PRINCE2 training courses is large and has also seen some impressive international growth. Tens of thousands of candidates around the world take the PRINCE2 Foundation and Practitioner exams each year, and large numbers of them prepare for those exams by completing PRINCE2 courses. The PRINCE2 project management method is suitable for running any project in any industry, thereby, making it a popular choice for a very wide range of organizations.

PRINCE2 Trainer Requirements

If you are aiming to qualify as an Approved PRINCE2 Trainer, you must meet the following requirements:

– A score of at least 66% in the PRINCE2 Practitioner exam
– At least 2 years’ experience of delivering training courses
– At least 2 years’ experience of project management (or having delivered at least 2 full PRINCE2 Foundation & Practitioner courses under the guidance of an existing Approved PRINCE2 Trainer)
– You also need to find an Accredited Training Organization (ATO) willing to sponsor you becoming an Approved PRINCE2 Trainer.

Before agreeing to sponsorship, the ATO will likely want to prove that you meet the above requirements. It is, therefore, a good idea to have your PRINCE2 Practitioner candidate number on hand, and mention your certification plans to current or former colleagues who could provide references, if required.

Training the PRINCE2 Trainer

After an ATO has agreed to sponsor you, you will complete a trainer sponsorship program (often called ‘PRINCE2 Train the Trainer’), which aims to help you develop and refine your PRINCE2 training skills. The program will likely include: giving presentations to existing trainers; conducting training sessions for delegates; familiarizing yourself with course materials and any relevant computer software required to deliver a PRINCE2 course; discussions with existing trainers concerning how to improve your training style, and so on. Such activities are designed to prepare you for a formal assessment, during which you will be required to demonstrate that you possess the ability to conduct successful PRINCE2 courses. As part of the formal assessment, you will be observed training delegates and will also be interviewed about your knowledge of the PRINCE2 methodology. The assessor will present his/her findings to you, and then produce a written report. Based upon your performance, the assessor will decide whether or not to recommend you being awarded Approved PRINCE2 Trainer certification.

Should you pass the assessment, you will be certified as an Approved PRINCE2 Trainer for 3 years, subject to yearly monitoring. Before the end of the certification period, you will be re-assessed in order to check whether or not you continue to conform to the standards expected of an Approved PRINCE2 Trainer. In addition, 3-5 years after you have passed the PRINCE2 Practitioner exam (and every 3-5 years subsequently), you will need to prove that your PRINCE2 knowledge is up-to-date by passing the PRINCE2 Re-registration exam with a score of at least 66%.

Enjoy Your PRINCE2 Training Career

While the role of an Approved PRINCE2 Trainer can be challenging, it also has the potential to be highly enjoyable and diverse. For example, you may have the opportunity to train in numerous locations, perhaps delivering PRINCE2 courses in Europe, Asia, Africa, or other regions. You will also have the satisfaction of knowing that your training equips people with a leading method of managing projects, which is designed to help organisations improve their ability to deliver successful projects on time, on budget, and on schedule in today’s competitive business world.
PRINCE2® is a registered trade mark of the Cabinet Office

Get More PRINCE2 Information by Clicking HERE

Organizational Project Management

The term Organizational Project Management (OPM) was coined by John Schlichter in May 1998 in a meeting of the Standards Committee of the Project Management Institute. OPM was defined as the execution of an organization’s strategies through projects by combining the systems of portfolio management, program management, and project management. This definition was approved by a team of hundreds of professionals from 35 countries and was published as part of PMI’s Organizational Project Management Maturity Model standard in 2003 and updated later to a second edition in 2008 when it also became an ANSI standard. The standard was updated to a third edition in 2013. The term “Organizational Project Management” should be capitalized because the term is a conventional designation for exactly the systems of processes elaborated in ANSI/PMI 08-004-2008, because it is a proper name for that system and that system is definitive and regimented in its application, and because it does not denote generically any project management that is done in organizations.

According to PMI (2003, 2008, 2013)

Organizational Project Management is the systematic management of projects, programs, and portfolios in alignment with the achievement of strategic goals. The concept of organizational project management is based on the idea that there is a correlation between an organization’s capabilities in project management, program management, and portfolio management and the organization’s effectiveness in implementing strategy.

Get More PRINCE2 Information by Clicking HERE

Project Sponsorship

Project sponsorship is the ownership of projects on behalf of the client organization.

There are two main differences between project sponsorship and project management. Firstly project sponsorship includes the identification and definition of the project whereas project management is concerned with delivering a project that is already defined, if only quite loosely.
Secondly the project sponsor is responsible for the project’s business case and should not hesitate to recommend cancellation of the project if the business case no longer justifies the project.

Project sponsors can encourage separation of decision making responsibilities between project manager and project sponsor, accountability for the realisation of project benefits, oversight of the project management function and can carry out senior stakeholder management.

The project sponsor or executive sponsor needs a range of skill sets, or at least access to skill sets which include appreciation of corporate strategy; ability to prepare a business case and profound knowledge of the organization’s operations. The project sponsor also needs to know his or her way around the organization and command respect within it. The project sponsor and project manager should form an effective partnership with the project manager orchestrating all players involved in delivering the project e.g. designers, manufacturers and contractors, whilst the project sponsor coordinates all departments of the client organization and associated stakeholders so as to integrate the delivered project into the client organization and take full benefits from it such that the business case is fulfilled.

Because the project sponsor is the ‘owner’ of the project from conception to commissioning and operation it is particularly important to achieve continuity of sponsor throughout the project yet correspondingly difficult to achieve because of the extended duration of sponsorship compared to project management.

Get More PRINCE2 Information by Clicking HERE

Project Plan Document

The Project Management Plan Document also known as Project Plan Document or simply Project Plan is a document that contains the strategy for managing the project and the processes related to all areas of the project (scope, cost, schedule, quality, etc.) which are known as Knowledge Areas according to PMI. There are lots of project management processes mentioned in PMBOK® Guide, but determining what processes need to be used based on the needs of the project which is called Tailoring is part of developing the project management plan

The project plan document may include the following sections:

A High level overview of the project

The roles and authority of team members. It represents the executive summary of the Project Management Plan

The scope statement from the Project charter should be used as a starting point with more details about what the project includes and what it does not include (In-Scope and Out-Of-Scope)

A list of the project Milestones (the stop points that helps evaluating the progress of the project). This list includes the milestone name, a description about the milestone, and the date expected.

WBS which consists of Work Packages and WBS Dictionary, which defines these work packages, as well as Schedule Baseline, which is the reference point for managing project progress, are included here.

This section contains all management plans of all project aspects

Identify key resources needed for the project and their times and durations of need.

This section includes the budgeted total of each phase of the project and comments about the cost.

Acceptable levels of quality.

Some space for the project sponsor to sign off the document

Get More PRINCE2 Information by Clicking HERE

Project Stakeholder

According to the Project Management Institute (PMI), the term project stakeholder refers to, “an individual, group, or organization, who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project” (Project Management Institute, 2013). ISO 21500 uses a similar definition.

Project stakeholders are entities that have an interest in a given project. These stakeholders may be inside or outside an organization which:

The following are examples of project stakeholders:

Rather than focusing on one subset of stakeholders, Lynda Bourne advocates prioritizing all stakeholders and focusing your attention on the “most important” at this point in time. Her view of importance encompasses an assessment of the power, proximity and urgency associated with each stakeholder. She calls her methodology a “Stakeholder Circle”.

The rationale for this emphasis on decision makers is part of project stakeholder management and a key component in affecting change in an organization. John Kotter describes stakeholder analysis and stakeholder management as essential components of change management.

Get More PRINCE2 Information by Clicking HERE

Project Management 2.0

Project Management 2.0 (sometimes mistakenly called Social Project Management) is one branch of evolution of project management practices, which was enabled by the emergence of Web 2.0 technologies. Such applications include: blogs, wikis, collaborative software, etc. Because of Web 2.0 technologies, small distributed & virtual teams can work together much more efficiently by utilizing the new-generation, usually low or no-cost Web-based project management tools. These tools challenge the traditional view of the project manager, as Project Management 2.0 represents a dramatic increase in the ability for distributed teams’ collaboration.

While traditional project management structures focused on the paradigm of the project manager as controller, Project management 2.0 stresses the concept of distributed collaboration, and the project manager as a leader. Project management 2.0 advocates open communication. While traditional project management often was driven by formal reporting and hierarchical structures, project management 2.0 stresses the need for access to information for the whole team. This has led to one of the many criticisms of Project Management 2.0 – that it cannot scale to large projects. However, for distributed teams performing agile development, which are often emergent structures, the use of rich collaborative software may enable the development of collective intelligence

Common comparisons of traditional project management vs. project management 2.0 are listed in the table below.

Project Portfolio Management (PPM)

Prince2 Certification
Image by/from Kokcharov

Project Portfolio Management (PPM) is the centralized management of the processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage current or proposed projects based on numerous key characteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organization’s operational and financial goals, while honouring constraints imposed by customers, strategic objectives, or external real-world factors. The International standard defines the framework of the Project Portfolio Management

PPM provides program and project managers in large, program/project-driven organizations with the capabilities needed to manage the time, resources, skills, and budgets necessary to accomplish all interrelated tasks. It provides a framework for issue resolution and risk mitigation, as well as the centralized visibility to help planning and scheduling teams to identify the fastest, cheapest, or most suitable approach to deliver projects and programs. Portfolio Managers define Key Performance Indicators and the strategy for their portfolio .

Pipeline management involves steps to ensure that an adequate number of project proposals are generated and evaluated to determine whether (and how) a set of projects in the portfolio can be executed with finite development resources in a specified time. There are three major sub-components to pipeline management: ideation, work intake processes, and Phase-Gate reviews. Fundamental to pipeline management is the ability to align the decision-making process for estimating and selecting new capital investment projects with the strategic plan.

The focus on the efficient and effective deployment of an organization’s resources where and when they are needed. These can include financial resources, inventory, human resources, technical skills, production, and design. In addition to project-level resource allocation, users can also model ‘what-if’ resource scenarios, and extend this view across the portfolio.

The capture and prioritization of change requests that can include new requirements, features, functions, operational constraints, regulatory demands, and technical enhancements. PPM provides a central repository for these change requests and the ability to match available resources to evolving demand within the financial and operational constraints of individual projects.

With PPM, the Office of Finance can improve their accuracy for estimating and managing the financial resources of a project or group of projects. In addition, the value of projects can be demonstrated in relation to the strategic objectives and priorities of the organization through financial controls and to assess progress through earned value and other project financial techniques.

An analysis of the risk sensitivities residing within each project, as the basis for determining confidence levels across the portfolio. The integration of cost and schedule risk management with techniques for determining contingency and risk response plans, enable organizations to gain an objective view of project uncertainties.

In the early 2000s, many PPM vendors realized that project portfolio reporting services only addressed part of a wider need for PPM in the marketplace. Another more senior audience had emerged, sitting at management and executive levels above detailed work execution and schedule management, who required a greater focus on process improvement and ensuring the viability of the portfolio in line with overall strategic objectives. In addition, as the size, scope, complexity, and geographical spread of organizations’ project portfolios continued to grow, greater visibility was needed of project work across the enterprise, allied to improved resource utilization and capacity planning.

Enterprise Project Portfolio Management (EPPM) is a top-down approach to managing all project-intensive work and resources across the enterprise. This contrasts with the traditional approach of combining manual processes, desktop project tools, and PPM applications for each project portfolio environment.

The PPM landscape is evolving rapidly as a result of the growing preference for managing multiple capital investment initiatives from a single, enterprise-wide system. This more centralized approach, and resulting ‘single version of the truth’ for project and project portfolio information, provides the transparency of performance needed by management to monitor progress versus the strategic plan.

The key aims of EPPM can be summarized as follows:

A key result of PPM is to decide which projects to fund in an optimal manner. Project Portfolio Optimization (PPO) is the effort to make the best decisions possible under these conditions.

Management System

A management system is a set of policies, processes and procedures used by an organization to ensure that it can fulfill the tasks required to achieve its objectives. These objectives cover many aspects of the organization’s operations (including financial success, safe operation, product quality, client relationships, legislative and regulatory conformance and worker management). For instance, an environmental management system enables organizations to improve their environmental performance and an occupational health and safety management system (OHSMS) enables an organization to control its occupational health and safety risks, etc.

Many parts of the management system are common to a range of objectives, but others may be more specific.

A simplification of the main aspects of a management system is the 4-element “Plan, Do, Check, Act” approach. A complete management system covers every aspect of management and focuses on supporting the performance management to achieve the objectives. The management system should be subject to continuous improvement as the organization learns.

Elements may include:

Examples of management system standards include:

Management Process

Management process is a process of setting goals, planning and/or controlling the organizing and leading the execution of any type of activity, such as:

An organization’s senior management is responsible for carrying out its management process. However, this is not always the case for all management processes, for example, it is the responsibility of the project manager to carry out a project management process.

Planning, it determines the objectives, evaluate the different alternatives and choose the best

Organizing, define group’s functions, establish relationships and defining authority and responsibility

Staffing, recruitment or placement and selection or training takes place for the development of members in the firm

directing, is to give the Direction to the employees.

Acquisition Initiation Within the Information Services Procurement Library (ISPL)

Uncategorized
Image by/from User:Mcalukin of the English Wikipedia

Acquisition Initiation is the initial process within the Information Services Procurement Library (ISPL) and is executed by a customer organization intending to procure Information Services. The process is composed of two main activities: the making of the acquisition goal definition and the making of the acquisition planning. During the acquisition initiation, an iterative process arises in which questions about the goal of the acquisition are usually asked. In response to these questions the Library provides details of the requirements, covering areas such as cost, feasibility and timelines. An example of such requirements is the “planning of the acquisition”, a component that may also lead to more questions about the acquisition goal (thus, it is reasonable to state that a relationship exists between the acquisition goal and the acquisition planning).

The process-data model shown in the following section displays the acquisition initiation stages. It shows both the process and the data ensuing from the process, and parts of the image will also be used as references in the body of this article. The concepts and data found in the model are explained in separate tables which can be found in the section immediately following the model. A textual, and more thorough, explanation of the activities and concepts that make up the Acquisition Initiation process can be found in the remainder of this article.

The draft acquisition goal is the description of the global goal that is to be achieved by starting procurement. It is inspired by the business needs or business strategy. It is similar, though simpler, to the concept of the project brief in PRINCE2. It is the first draft of the acquisition goal, containing at least a (short) problem definition and a (short) goal definition. The draft acquisition goal is meant to give the main reasons and the main goals to those people who will have to make the decision to actually start of the acquisition or not. It may thus also encapsulate items like a cost-benefit analysis, stakes & stakeholders and other items that will be further refined during the actual Acquisition Initiation.

It is, in this sense, not an activity of the acquisition initiation process, but it is the input for starting the process.

The problem definition is a statement about the problem that could be resolved by starting the acquisition process.

The goal definition is a statement about the goal that will have to be reached when the acquisition is executed:

The draft acquisition goal can be made as short or as long as is needed by the organization, as long as it serves to be a good basis to make the initial decision to start of an acquisition process.

When the decision is made to start an acquisition process, the first activity of the acquisition initiation is to define the acquisition goal.

The acquisition goal is the whole of defined systems and services requirements, attributed by costs & benefits and stakes & stakeholders, with a defined target domain serving as the boundary. The acquisition goal is the basis of the acquisition process and for formulating the acquisition strategy during the acquisition planning. Input can be the draft acquisition goal and the business needs (of the target domain). The business needs can be derived from strategic business plans or information system plans.

The target domain is that part of the customer organization that is involved in, or influenced by an information service. It is defined in terms of business processes, business actors, business information, business technology and the relations between these four aspects. The target domain is identified to ensure a fitting acquisition goal with fitting requirements for the systems and services to be acquired.

A limited description of a target domain can thus be, for example:The part of customer organization that uses the software program MarketingUnlimited (fictional), involving the marketing-process, several types of information related to the marketing-department of the customer organization, the employees working in the marketing department and the production platform for MarketingUnlimited consisting of an application server, several workstations, and tools related to MarketingUnlimited.

The acquisition goal is then described by system descriptions and service descriptions:

Other information on how ISPL defines the deliverables of the acquisition can be found in the general ISPL entry.

Cost-benefit analysis concerns the analysis of:

to successfully evaluate the investment issues of the acquisition.

It is important to identify all actors affected, and in what way they are affected (their stake), because a negative attitude of actors may negatively influence the success of the acquisition. ISPL proposes to perform a SWOT analysis (Strengths, Weaknesses, Opportunities and Threats) for the actors involved to properly and thoroughly identify the stakes of the actors. The results of this analysis can serve as input for the situation & risk analysis.

The information contained within the Acquisition Goal is used to produce the acquisition plan. The acquisition plan is the master plan of the entire acquisition. In this plan, delivery scenarios are determined and the situation and risks are evaluated. Based on the scenarios, situations, and risks, a strategy is formed to manage the acquisition. Furthermore, the acquisition plan will hold the main decision points, in which decisions are made about the deliverables within the acquisition and the acquisition organization (similar to a project organization) is formed.

On the basis of the acquisition goal, which contains among others the systems and services requirements and descriptions, scenarios can be formed for the deliveries of the information services to be acquired. Multiple scenarios may be built, which will then be evaluated and used in the design of the acquisition strategy. The scenarios are built with the priorities and interdependence of the deliverables in mind.

Priorities are related to the importance of each delivery: which delivery has time-preference over another.

Some deliveries may be dependent on each other, requiring one services to be delivered before the next one can be.

Example:

During a project to make ISPL more specific for generic product software implementations, a number of scenario’s were made. One of these was for an approach of a one-shot implementation. The below picture shows a diagram of the scenario that was made. An example of a scenario for the implementation of software is shown in the thumbnail on the right.

In this example, the general deliverables within an implementation of software are mentioned, executed and delivered differently as time goes by, mainly because of dependencies between deliverables. For instance, the actual go for the delivery of the software and the other related deliverables are dependent on the outcome of the deliverable “Proeftuin”. “Proeftuin” is an agreed period in which the software is extensively tested by the customer organization, provided and supported by the supplier. The customer organization can get a feel for the use of the software in the target domain, to guarantee that the software is a “fit” within the organization.

ISPL adheres to a situational approach to manage an acquisition. The situational approach takes into account properties of the problem situation, which are called situational factors. ISPL provides a number of these situational factors. Some of these situational factors affect events that have adverse consequences: the risks. Thus, the situational factors and risks within ISPL are related to each other. This makes it possible to provide a number of heuristics on which factors have an influence on certain risks.
First the situation is analysed, then ISPL proposes a number of risks which may arise from the situation at hand. With this information, an acquisition strategy can be formed to mitigate both the situation and risks in a number of areas.
Other information of the situation & risk analysis of ISPL can be found in the ISPL entry.

The acquisition strategy within ISPL acts as the design of a risk management strategy. The risk management strategy provides choices for options that reduce the probability and/or effect of risks. ISPL provides several options, divided over four classes:

Options are chosen based on their efficiency, costs and the related delay for delivery.

Based upon all the previous activities, the decision points planning is made. This is a time-set planning of decision points.

A decision point is described by:

An example of a decision points planning can be found through the thumbnail on the right. In this planning the decisions points are planned through time (top to bottom, left to right). This planning was taken from a study to make ISPL more specific for product software implementations. The decision points planning is thus aimed at a part of the process of a software implementation.

A shortened example of a decision point description can be found in the image below. This description was taken from the same study to make ISPL more specific for product software implementations.

The acquisition organization is set, which is similar to a project organization. Although the acquisition organization is more focused on the (legal) relationship that it has to maintain with the supplier organization.