| Prince2 Project Management Authority Site

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 Risk Management

Image by/from Kokcharov

Project risk management is an important aspect of project management. Project risk is defined by PMI as, “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.”

Project risk management remains a relatively undeveloped discipline, distinct from the risk management used by Operational, Financial and Underwriters’ risk management. This gulf is due to several factors: Risk Aversion, especially public understanding and risk in social activities, confusion in the application of risk management to projects, and the additional sophistication of probability mechanics above those of accounting, finance and engineering.

With the above disciplines of Operational, Financial and Underwriting risk management, the concepts of risk, risk management and individual risks are nearly interchangeable; being either personnel or monetary impacts respectively. Impacts in project risk management are more diverse, overlapping monetary, schedule, capability, quality and engineering disciplines. For this reason, in project risk management, it is necessary to specify the differences (paraphrased from the “Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs”):

An improvement on the PMBOK definition of risk management is to add a future date to the definition of a risk. Mathematically, this is expressed as a probability multiplied by an impact, with the inclusion of a future impact date and critical dates. This addition of future dates allows predictive approaches.

Good Project Risk Management depends on supporting organizational factors, having clear roles and responsibilities, and technical analysis.

Chronologically, Project Risk Management may begin in recognizing a threat, or by examining an opportunity. For example, these may be competitor developments or novel products. Due to lack of definition, this is frequently performed qualitatively, or semi-quantitatively, using product or averaging models. This approach is used to prioritize possible solutions, where necessary.

In some instances it is possible to begin an analysis of alternatives, generating cost and development estimates for potential solutions.

Once an approach is selected, more familiar risk management tools and a general project risk management process may be used for the new projects:

Finally, risks must be integrated to provide a complete picture, so projects should be integrated into enterprise wide risk management, to seize opportunities related to the achievement of their objectives.

In order to make project management effective, the managers use risk management tools. It is necessary to assume the measures referring to the same risk of the project and accomplishing its objectives.

The project risk management (PRM) system should be based on the competences of the employees willing to use them to achieve the project’s goal. The system should track down all the processes and their exposure which occur in the project, as well as the circumstances that generate risk and determine their effects. Nowadays, the Big Data (BD) analysis appears an emerging method to create knowledge from the data being generated by different sources in production processes. According to Gorecki, the BD seems to be the adequate tool for PRM.

Get More PRINCE2 Information by Clicking HERE

Acquisition Initiation Within the Information Services Procurement Library (ISPL)

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.