Phekla

From apppm
Revision as of 12:10, 6 March 2020 by Elenibatsiou (Talk | contribs)

Jump to: navigation, search
PHEKLALOGO.png

Toolbox by Phekla

Phekla group!
- 5-10 tools (use from previous years or others)
- A short description
- How it can be used
- Limitations
- Link to the tool

Contents



Portfolio Risk Management Process

Description

A portfolio risk management process is a process which a manager must work through to control the risk that may affect the portfolio. The outcome of this process is a solid strategy where risks are dealt with. The process is divided in 4 phases; identification, analysis, response and monitoring.

Management

In the first phase of the process, identification, all risk are identified. The risk that are identified will in the second phase be analysed and prioritized in relation to the impact an probability of the risk. Response to the risk are now developed where responsibility are defined so risk owners know how to handle the risks. In the last phase of the process the risks are monitored with the elements that are defined in "The Standard for Portfolio Management". Furthermore the monitoring and controlling manager should also develop responses to emerging risks and existing risks.

Limitations

As mentioned Portfolio Risk Management Process is a process to identify risks, analyse risks, develop responses and monitor the risks. These processes have limitations, e.g it is assumed that no "new" risk will occur. This defines that the world will act in the way we have seen before.

Link

http://wiki.doing-projects.org/index.php/Portfolio_Risk_Management_Process


Managing successful programs (MSP)

Description

Managing successful programs is a key tool to secure a beneficial outcome of their business success. Today, organizations are facing constant changes in order to maintain with the fast-growing markets and compete with other companies, MSP has become more and more important. The goal of management is to maximize the benefits, while minimize costs and the need of effort by combining and coordinate all involved projects. To handle program management and tackle changes, MSP is a detailed framework where governance can be improved by organize planning and define common goals to achieve success.

The concept of MSP is to provide a method which manage programs in an efficient and structured appearance, so organizations can be more effective and contribute better services. The main idea about MSP is to divide the program into various smaller projects that are simpler to manage. MSP is based on three main elements:

  • The Foundations: principles, vision, blueprint & benefits.
  • People: organization, roles, leadership & stakeholder engagement.
  • Structure: transformational flow, themes, blueprint, tranches.


Management

MSP is a successful tool for managing because of the flexibility, where different situations can be adaptive into the same framework with a structured program management methodology.

How it can be used:

  • Set a goal for each project
  • Identify the problem
  • Define the problem
  • Managing the tranches
    • Delivering of capability
    • Realizing the benefits
  • Closing a program


Limitations

One of the limitations of MSP is the required workload and planning, since the tool has a explicit and complex protocol. This tool can be adapted for all types of programs; however, it is most suitable for smaller programs with fewer projects and less reasonable transformations required. Investment into a program can require high-level management, important founding and broad change within the organization. This can lead to challenges and difficulties during the program, especially if the program varies for a longer period. It can then be hard to motivate the employees and complications of staying on the right path can occur.


Link

http://wiki.doing-projects.org/index.php/Managing_Successful_Programmes_(MSP)


Benefits Realisation Management (BRM)

Description

The Benefits Realisation Management (BRM) is a collective set of processes and practices that defines and measures the value that a project, program or portfolio management bring into an organization. BRM constitutes a link between strategic planning and strategy execution since it translates the business strategy drivers into benefits. The benefits refer to the positive outcomes of a project, program or portfolio and they can be categorized in three main groups: i) economic benefits, ii) effectiveness benefits and iii) efficiency benefits. The generated benefits increase and add value to the organization or the stakeholders when they are aligned with the corporate objectives and they lead from the current situation of the organisation to the future desired one. Main purpose of the BRM is evaluating whether the achieved benefits are in accordance to the baselines and the expected outcomes, while decreasing the risks that are related to these benefits. The process of the benefits realization management consists of three phases:

  • Identifying benefits: The determination of the desired outcomes based on the organization’s business plan and specification of the key performance indicators (KPIs) are the main parts of “Identifying benefits”. At this phase it is defined whether a project/program can produce the desired value and different tools are used in order to map the benefits. Information about the beneficiary, the time and the life span of the outcomes are analyzed in order to be identified that the considered benefits are in accordance with the initial business’ goals.
  • Execute benefits: The monitoring of the benefits is the main process that occurs during the “Execute benefits” phase. The progress of the planned actions and the intermediate deliveries are repeatedly assessed during the project’s development providing useful feedback that enhances management and decreases the risk related to the final outcome. Moreover, since the project development is a dynamic process, new opportunities may arise or the initial business goals may change. Hence, it is useful to be reviewed whether the formerly identified outcomes are still relevant or whether additional benefits should be considered.
  • Sustain benefits: In the last phase of the BRM the main goal is to be ensured that programs’ outcomes will continue to add value to the organization even after the end of the programs. It is important that the organizations are able to sustain benefits which contribute to the achievement of the strategic objectives. Therefore, through the benefits sustainment and the post-project evaluations it can be ensured the continued realization of the intended benefits.

Management

Projects and programs are driven by benefits, therefore the BRM can constitute crucial part of their success. Mapping the benefits that can be delivered by the organization’s projects and programs and define the relation they have with the corporate objectives provides a comprehensive overview of the cause and effects relationships between elements. The latter could facilitate effectively the management of the different processes during the projects’ lifetime and leads to the accomplishment of the projects’ goals. Through the monitoring of the intermediate benefits, the managers can continuously review the progress of the planned activities and keep projects on track. Moreover, it is important to be ensured that programs outcomes will continue to create value after the end of the programs. Hence, the performance of the benefits on a long-term basis could be measured through a benefits sustainment plan. Additionally, the evaluation on the final outcomes will be a valuable contribution to the assessment of the implemented processes and the derived conclusions could be used in order to increase the efficiency of the future planning.

Limitations

Although BRM is a powerful tool that has a strong influence over project success, there are limitations that may result to complicated and laborious processes. The interdependence of the benefits with internal and external elements is sometimes related to high uncertainty, which leads to complex and ambiguous evaluation of the outcomes. Moreover, the reliability of the benefits evaluation may decrease due to the constraints imposed by benefits which are unquantifiable. The discrepancy between the stakeholders’ visions might be another challenge for the BRM. The different impact that the benefits have on various stakeholders affects their interest on the project and respectively their engagement and their support. Hence, significant attention should be given on the different perspectives that the stakeholders might have on the considered benefits at the BRM.

Link

http://wiki.doing-projects.org/index.php/Benefits_Realisation_Management_(BRM)#cite_note-Fra-0


Stakeholder management

Description

A stakeholder can be any group or person that has interest in or can be affected by a project. Stakeholder, both internal and external can influence decision-making processes, perceived outcomes and the successful delivery of projects. Therefore it is important for project managers to perform these steps, regarding stakeholders in some way or another: • Identify • Classify • Manage

Management

The three steps mentioned, identify, classify and manage will be detailed below. It is important to know that these steps can be performed in multiple ways, and that no one way is the best one. It is the job of the project manager to pick the right tool for the right job, given the constraints of the project, the affinity of the project manager and the requirements of the stakeholders in the specific case.

Identify

The first step in stakeholder management is identifying the key stakeholders. This can be done with simple brainstorming techniques or by using a structured approach like identifying stakeholders according to “direction”. Upward stakeholders being members of the larger organisation higher up in the hierarchy in which the project organisation is embedded. Downward stakeholders being members of the project team and project organisation. Outward stakeholders can be both internal and external. Internal being other members of the organisation at the same level, like simultaneous project teams. External stakeholders are everybody else, such as, customer groups, unions, partners, authorities etc. Key stakeholders not identified in the initial stakeholder identification process in the beginning of the project period may become visible later, and this can have dramatic effects on the outcome of the project if not managed properly. It is therefore crucial for the project team to be open to start managing unforeseen stakeholders at any point during the project period.

Classify

Since project organisation have limited resources it is therefore necessary to prioritise the management of stakeholders and analyse them in order to managing them accordingly. There are numerous ways to do this, and here a few of the methods will be summarized shortly.

Power/interest matrix

A classic method classifying stakeholders into 4 main categories: High Power / High Interest: Encourage and Influence. High Power / Low Interest: Keep satisfied Low Power / High Interest. Keep informed Low power / Low interest: Monitor

Other methods

Stakeholder salience model: Power, Legitimacy, Urgency Detailed: Dormant, Discretionary, Demanding, Dominant, Dangerous, Dependent.

It is important to note if any one of the mentioned classifications is useful in the given project, that there are a multitude of other approaches available and the point of utilising a tool for a project is to gain an advantage. If the advantage is not immediately visible, consider using another method, or use multiple to spend time wrapping your heads around the stakeholder environment in the given project.

Manage

After the stakeholders have been identified and classified, now comes for the practical phase: Manage. The key word when managing stakeholders are engagement, in the right amount, at the right time and in the right way. At least, the management of stakeholders should entail a communication plan detailing when to distribute what information, to whom and what information to retrieve at what point. One way to prioritise the amount of resources spend at managing each stakeholder could be to engage them in one of the following ways: Partnership: Stakeholders share responsibilities of the project with the project organisation Participation: Stakeholders are invited in decision processes, but the final decision is with the project organisation. Consultation: Stakeholders are asked about various things, but their input isn’t necessarily used. Push communication: Information is sent directly to stakeholders. Pull communication: Information is made available for stakehodlers.

Limitations

A full identification of all relevant stakeholders is never realistic, and the project team should have open ears towards incoming stakeholders. Even though stakeholders are managed carefully they may not deem the project itself to be good and could therefore try to block it no matter what. Stakeholder management take resources and the benefits may not seem worth the investment or the inputs from the stakeholders may be of low quality.

Link

http://wiki.doing-projects.org/index.php/Stakeholder_Management


Stage-gate process

Description

Stage-gate process is a project management tool, dividing the time horizon of a project into several information-gathering stages. All stages are separated by gates, which categorize decisions into go-kill-hold or recycle. To manage risk, the firm have to manage the project portfolio into promising and beneficial projects. The basic idea about stage-gate process is that the project is divided in a set of stages with different activities. Moreover, the gates are connected to a set of deliverables or inputs, together with a set of criteria, and outputs to be able to manage the risks of the project. All gates represent different time periods, some last for weeks and others last longer. The benefit of the gate phases is to use a more efficient tool to get the best improvement and to reduce time spending on decisions.

Link

http://wiki.doing-projects.org/index.php/Stage-Gate_Process


Results Framework

Description

Results framework was first created in order to design a program that could gather and control programs.

This management approach is a system that involves both logic, analysis, standard theories and on-the-ground expertise managers.

The purpose of a results framework is to have a graphically presentation, a log-series, that structural shows the projects agendas needed to achieve the goals and objectives behind the project. The graphical chain shows the project hypothesis, activities, processes and the intended changes that are expected to occur throughout the project cycle.

For most companies they design the results framework in the beginning of the identification phase of the project, for undergoing further improvements as the projects develops.

The common naming an organisation uses for the results framework levels are given in the figure below

Results framework.png

Moreover, a results framework consists of several levels. This tool should deliver the needed information for a person to understand the planned activities intended in the process for the project to achieve its objectives.

Management

The results framework can be a useful tool to analyse it as a specific tool-case and its effectiveness for the organisation. This tool also provides a help to evaluate how the progress within each level gets measured and documented.

Limitations

For the results framework to be effective is must be continuous revised to secure that it is current for the project.

Link

https://www.toladata.com/blog/build-a-results-framework/


Cost Estimation Techniques for Projects

There are number of different ways of making project estimates. Below is a short overview of a number of techniques

- Expert Judgement: The quickest and easiest, but can be inaccurate. This technique relies on the experience and knowledge of expert making the judgement.

- Analogous Estimate: Finding comparable project to determine the costs of the upcoming project. This requires historical data on previous projects. Things may need to be adapted, thus requiring judgements on this.

- Parametric Estimate: Besides using historical data from previous projects, this technique also uses statistical data of key cost drivers. The technique relies on having updated statistical data because changes in methods or equipment may skew parametric estimates.

- Three Point Estimate: Instead of making a single estimate, this techniques makes three estimates of the most likely case, a worst case and a best case scenario. The final estimate is then computed by making a weighted average of the three.

- Bottom Up Technique: This is the most laboursome and costly estimation technique. It requires that the project is divided into individual tasks which are calculated individually and then added together. The more detailed the subdivision the more accurate the method is, but the larger and more complex the project is the laboursome it is.

- Reserve Analysis: After making an estimate this technique can be used by making a buffer by adding a percentage or fixed number to an estimate, thus creating some room for uncertainties and risks.

- Vendor Bid Analysis: This method is relevant when the project owner have subcontractors or outsource certain tasks. The project manager collect cost estimations from subcontractors by sending them a detailed proposal which the subcontractors can reply on. This technique relies on the capabilities of the subcontractors/vendors.

Link

http://wiki.doing-projects.org/index.php/Cost_Estimation_Techniques_for_Projects


Lessons Learned

Description

A tool for sharing knowledge in project management. Lessons learned data driven reports are documents generated by an organisation that might have value for future projects.

The lessons learned aims to bring insight and knowledge gained during previous projects, mean to learn from what went wrong as well as right in specific project processes and share this knowledge of specific lessons reports that most likely have the acquired experiences to improve future projects.

The knowledge is collected in the end of the project stage, though in larger projects the lessons learned could be collected during a project. The purpose is to awake an awareness of previous projects, in order to avoid the same mistakes or wrong assumptions. Positive results as an outcome of assumption that went well is also relevant information to conduct.

As stated, the lessons learned reports could be developed during projects, but should be incorporated in the end stage of a project. For an effective reuse of the knowledge the reports could be divided into different lessons, and designed to a specific target, ex. Specific field, supplier, technology, budget.

Management

The lessons learned tool is not a fixed template. An organisation must develop their own template for applying this to include case-specific field/themes necessarily for the organisation.

The procedure for lesson learned can be divided into five steps, as follows:

-Step 1: Collect (Record data)

-Step 2: Validate data

-Step 3: Storing (and categorise)

-Step 4: Disseminate (Data-communication)

-Step 5: Reuse (Learn from previous knowledge)


A short description of the 5 steps within management

Collecting:        the knowledge or lessons from project that are conducted troughout the process 
Validating data: is the process where the knowledge must be evaluated to see if it relevant and useful recommendations are generated
Storing: the lessons learned needs to be stored, but the organisation must have a storage unit. This is decided by the project manager who is responsible for deciding the most appropriate solution or system for storage and defining the appropriate categorising of lessons learned. Categorising and easy access is substantially for the efficient use of the conducted lessons knowledge
Disseminating: sharing is the next important step to consider - how do the organisation distribute the knowledge?
Reusing: how does the new / other projects reuse the lessons learned data?


An example of a lessons learned template is shown in the figure below, developed by PRINCE2, created by Amanda Slyngborg

LessonsLearnedPRINCE.png


Instead of assessing the project in the final end, it is recommended that the lessons learned is more effective if the lessons report are created at the end of each stage, this way it prevents from mistakes committed later in the project, and manager of each fields are more open to learn from mistakes than later in the development process.

Limitations

An organisation working with the lessons learned tool will meet some limitations and challenges. In the early stage of the project it can bring greater effectiveness to the lesson’s reports, if the project manager is aware of these limitations and take them into consideration.

Lack of engagement from the participants (employees)

The lessons report is depending on the willingness of the employees to contribute and being encouraged to be involved in the documenting. Therefore, it is important that the project manager succeeds in communicate how, when, what and most important why they need to register and participate in the lessons learned.

Clear presentation of knowledge

One of the risks of failure with the lessons report, is if the knowledge isn’t understandable for the colleagues. It is important that they capture the explicit knowledge, but also remembers to include the implicit knowledge, which is easy to forget, but might play a huge role in learning the coherence in the progress.

Lack of time

If the time expected to be spent on the reports is not included in the employees’ time schedules / estimation the agenda and result of the report outcomes may failure.

Lack of clear guidelines

It’s important that the employees get well-instructed in how to conduct the lessons learned. Lessons learned is both about the explicit as the implicit knowledge, and therefore it is important that the project manager ensures the participates only include important and relevant lessons. It can be difficult to differ between relevant and irrelevant in a cornucopia of knowledge.

Lack of storage

If the lessons learned has been successfully conducted, it is of no-use for future projects, and waste of worktime if the lessons learned is storage in a random location. The project manager should make sure that the lessons learned will be stored in relevant location, that is available and easy to access.

Lack of sharing

The employees and project manager may think that a project is finally finished when they have stored the lessons learned, and therefore then move on and discard the project. But this is not the case. To fully utilise the lessons learned the existence of it must be communicated to other employees. The storage of lessons reports plays a key role for easy access but sharing of existence and guidance of which relevant lessons learned might be useful for other projects is also essential.

Link

http://apppm.man.dtu.dk/index.php/Lessons_learned_-_a_tool_for_sharing_knowledge_in_project_management

https://prince2.wiki/management-products/lessons-report/


Risk tolerances

Figure 1: Risk tolerance profile.

Risk tolerance is a significant element of a risk management plan since it identifies the degree or the amount of risk that an organisation can withstand. High tolerance corresponds to high willingness of accepting risks, that might have either positive or negative effect on the final objectives. The estimation of risk tolerances refers both to the probability of a risk to occur and the impact that a risk might have. Plotting this information in a chart (Figure 1) results in a graph where the tolerance line is mapped out, addressing the level of tolerance that a company can withstand for each one of the charted risks.

Prioritisation of the risks based on the capability of the risk-taker to endure a probable threat or opportunity is of significant importance for the decision making since it leads to more efficient use of resources. In addition it is important that the risk tolerance is analysed and revised continuously during the project life time.

The risk tolerance can be analysed in different ways from either the company, the project manager and or the stakeholders. As a result there is a possibility that risks tolerances for a project might conflict because of either the different perceptions or due to the complexity of the project.

Link

http://wiki.doing-projects.org/index.php/Risk_tolerances

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox