Phekla
Elenibatsiou (Talk | contribs) (→Title 2) |
(→Description) |
||
(71 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
− | + | [[File:PheklaLOGO.jpg|right|170px]] | |
− | - | + | <h1 style="color: #5e9ca0; text-align: justify;">'''Toolbox by Phekla'''</h1> |
− | + | __TOC__ | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | |||
− | + | =='''Portfolio Risk Management Process'''== | |
− | ==Portfolio Risk Management Process== | + | |
===Description=== | ===Description=== | ||
− | A portfolio risk management process is a process | + | A portfolio risk management process is a process that 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 into 4 phases; identification, analysis, response, and monitoring. |
===Management=== | ===Management=== | ||
− | In the first phase of the process, identification, all | + | In the first phase of the process, identification, all risks are identified. The risk that is identified will in the second phase be analyzed and prioritized in relation to the impact an probability of the risk. Response to the risk is now developed where responsibility is 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=== | ===Limitations=== | ||
− | As mentioned Portfolio Risk Management Process is a process to identify risks, | + | As mentioned Portfolio Risk Management Process is a process to identify risks, analyze 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=== | ===Link=== | ||
Line 30: | Line 24: | ||
http://wiki.doing-projects.org/index.php/Portfolio_Risk_Management_Process | http://wiki.doing-projects.org/index.php/Portfolio_Risk_Management_Process | ||
− | + | ||
− | ==Managing successful programs | + | =='''Managing successful programs'''== |
===Description=== | ===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 | + | 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 minimizing costs and the need for the 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 organizing planning and define common goals to achieve success. |
− | The concept of MSP is to provide a method which | + | The concept of MSP is to provide a method which manages 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. | *'''The Foundations:''' principles, vision, blueprint & benefits. | ||
Line 54: | Line 48: | ||
*Closing a program | *Closing a program | ||
+ | ===Limitations=== | ||
+ | One of the limitations of MSP is the required workload and planning since the tool has an 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 in 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 '''== | ||
+ | ===Description=== | ||
+ | The Benefits Realisation Management (BRM) is a collective set of processes and practices that define and measure the value that a project, program or portfolio management brings 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 into 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 organization to the future desired one. | ||
+ | The main purpose of the BRM is evaluating whether the achieved benefits are in accordance with 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 that contribute to the achievement of the strategic objectives. Therefore, through the benefits of sustainment and 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 a crucial part of their success. Mapping the benefits that can be delivered by the organization’s projects and programs and define the relationship 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 of 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 future planning. | ||
===Limitations=== | ===Limitations=== | ||
− | + | Although BRM is a powerful tool that has a strong influence on project success, there are limitations that may result in complicated and laborious processes. The interdependence of the benefits with internal and external elements is sometimes related to high uncertainty, which leads to the complex and ambiguous evaluation of the outcomes. Moreover, the reliability of the evaluation of the benefits may decrease due to the constraints imposed by benefits that 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 in 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 an interest in or can be affected by a project. Stakeholders, 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 organization higher up in the hierarchy in which the project organization is embedded. | ||
+ | Downward stakeholders being members of the project team and project organization. | ||
+ | Outward stakeholders can be both internal and external. Internal being other members of the organization 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 at 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 organization have limited resources it is, therefore, necessary to prioritize the management of stakeholders and analyze them in order to manage 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 utilizing 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, they now come for the practical phase: Manage. The keyword 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 prioritize the number 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 organization | ||
+ | Participation: Stakeholders are invited in decision processes, but the final decision is with the project organization. | ||
+ | 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 stakeholders. | ||
+ | |||
+ | ===Limitations=== | ||
+ | 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 takes resources and the benefits may not seem worth the investment or the inputs from the stakeholders may be of low quality. | ||
===Link=== | ===Link=== | ||
− | http://wiki.doing-projects.org/index.php/ | + | http://wiki.doing-projects.org/index.php/Stakeholder_Management |
− | + | =='''Stage-gate process'''== | |
− | = | + | ===Description=== |
− | + | The 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 has to manage the project portfolio into promising and beneficial projects. The basic idea about the stage-gate process is that the project is divided into 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 graphical presentation, a log-series, that structural shows the project's 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 at the beginning of the identification phase of the project, for undergoing further improvements as the projects develop. |
+ | |||
+ | The common naming an organization uses for the results framework levels are given in the figure below | ||
+ | [[File:Results framework.png|600px|thumb|center|'''Figure 1:''' Levels of a result framework.]] | ||
+ | |||
+ | 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 analyze it as a specific tool-case and its effectiveness for the organization. | ||
+ | This tool also provides help to evaluate how the progress within each level gets measured and documented. | ||
+ | |||
+ | ===Limitations=== | ||
+ | For the results framework to be effective is must be continuously 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 is a 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 experts making the judgment. | ||
+ | |||
+ | - '''Analogous Estimate''': Finding a 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 judgments 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 technique makes three estimates of the most likely cause, a worst-case and a best-case scenario. The final estimate is then computed by taking 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 has subcontractors or outsource certain tasks. The project manager collects cost estimations from subcontractors by sending them a detailed proposal which the subcontractors can reply to. 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 reports are documents generated by an organization that might have value for future projects. | ||
+ | |||
+ | The lessons learned aim 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 lesson reports that most likely have the acquired experiences to improve future projects. | ||
+ | |||
+ | The knowledge is collected at the end of the project stage, though in larger projects the lessons learned could be collected during a project. The purpose is to awake awareness of previous projects, in order to avoid the same mistakes or wrong assumptions. Positive results as an outcome of the assumption that went well are 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 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 organization must develop their own template for applying this to include case-specific field/themes necessarily for the organization. | ||
+ | |||
+ | The procedure for the 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 the management | ||
+ | |||
+ | {| border=1 style="border-collapse: collapse;" | ||
+ | |- | ||
+ | | ''Collecting'' ||the knowledge or lessons from the project that is conducted throughout 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 need to be stored, but the organization 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 categorizing of lessons learned. Categorizing and easy access is substantially for the efficient use of the conducted lessons knowledge | ||
+ | |- | ||
+ | | ''Disseminating'' || sharing is the next important step to consider - how does the organization distribute the knowledge? | ||
+ | |- | ||
+ | | ''Reusing'' || how do the new/other projects reuse the lessons learned data? | ||
+ | |} | ||
+ | |||
+ | |||
+ | '''''An example of a lessons learned template is shown in the figure 2, developed by PRINCE2, created by Amanda Slyngborg''''' | ||
+ | [[File:LessonsLearnedPRINCE.png|550px|thumb|right|'''Figure 2:''' An example of a lessons learned template.]] | ||
+ | |||
+ | Instead of assessing the project in the final end, it is recommended that the lessons learned are 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 field are more open to learning from mistakes than later in the development process. | ||
+ | |||
+ | ===Limitations=== | ||
+ | An organization 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 are 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 differentiate between ''relevant'' and ''irrelevant'' in a cornucopia of knowledge. | ||
+ | |||
+ | • '''Lack of storage''' | ||
+ | |||
+ | If the lessons learned have been successfully conducted, it is of no-use for future projects, and a waste of work time if the lessons learned are stored in a random location. The project manager should make sure that the lessons learned will be stored in a 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 utilize 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'''== | ||
+ | |||
+ | ===Description=== | ||
+ | [[File:matrix.PNG|350px|thumb|right|'''Figure 3:''' 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 organization can withstand. High tolerance corresponds to a high willingness of accepting risks, that might have either a 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 risk might have. Plotting this information in a chart (Figure 3) 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. | ||
+ | |||
+ | Prioritization of the risks based on the capability of the risk-taker to endure a probable threat or opportunity is of significant importance for decision making since it leads to more efficient use of resources. In addition, it is important that risk tolerance is analyzed and revised continuously during the project lifetime. | ||
+ | |||
+ | The risk tolerance can be analyzed in different ways from either the company, the project manager and or the stakeholders. As a result, there is a possibility that risk 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 | ||
+ | |||
+ | |||
+ | =='''Risk and Opportunities Management'''== | ||
+ | |||
+ | ===Description=== | ||
+ | |||
+ | Risk and Opportunities management is a tool to identify risks and opportunities in a project. To avoid uncertainty in a project, the risk is identified and managed through the project life cycle. Risk management is an important concept that maintains stability and success throughout a project. The process of risk management process (RMP), is a 7-step process: Communication and consultation, establishing the context, risk identification, risk analysis, risk evaluation, risk treatment, and monitoring and review. Opportunities management deals with the positive effects that can occur throughout a project. To take advantage of all positive opportunities, OM is an important process. | ||
+ | |||
+ | ===Link=== | ||
+ | http://wiki.doing-projects.org/index.php/Risk_and_Opportunities_Management | ||
+ | |||
+ | =='''Scenario Planning Strategy'''== | ||
+ | |||
+ | ===Description=== | ||
+ | |||
+ | During the second world war, scenario planning used as a practice and became a revolutionary tool in the business sector in the upcoming decades. Scenario Planning Strategy is a systematic and methodical Strategic management tool, which aims to implement a scalable plan that will support the company in the long term. The application of scenario planning is quite broad and can be beneficial for different conditions considering a wide spectrum of possibilities. In addition, the main contributions of the tool can be seen in Preparatory Planning, Risk Management and Generation of new ideas and there is a 7-step process: define the critical issue, identify critical decision factors, analyze and rank decision factors by order of importance and uncertainty, create scenarios, identify Implications and interrelationships of scenarios, select leading scenario indicators monitoring which scenario to implement strategic plans. | ||
+ | |||
+ | ===Link=== | ||
+ | |||
+ | http://wiki.doing-projects.org/index.php/Scenario_Planning_Strategy | ||
+ | |||
+ | =='''Earned value analysis'''== | ||
+ | |||
+ | ===Description=== | ||
+ | |||
+ | Earned value analysis (EVA) provides objective performance indicators and quantitative analysis techniques, in order to measure the cost-efficiency. Successful execution of EVA requires a time-based schedule, work breakdown structure, cost assessment, progress measurement, responsibility/ authority matrix, and a monitoring and review process, while the main areas of application are organizational level - earned value management system (EVMS), project controlling and forecasting. As far as the key benefits are concerned, the improvement of the overall process of an organization is related to the framework, provided by EVA. On the other hand, the major drawback of EVA is not taking into consideration the sequence of work packages, created by network analysis. | ||
+ | |||
+ | ===Link=== | ||
+ | http://wiki.doing-projects.org/index.php/Decision_Tree |
Latest revision as of 09:06, 11 May 2020
Toolbox by Phekla
[edit] Portfolio Risk Management Process
[edit] Description
A portfolio risk management process is a process that 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 into 4 phases; identification, analysis, response, and monitoring.
[edit] Management
In the first phase of the process, identification, all risks are identified. The risk that is identified will in the second phase be analyzed and prioritized in relation to the impact an probability of the risk. Response to the risk is now developed where responsibility is 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.
[edit] Limitations
As mentioned Portfolio Risk Management Process is a process to identify risks, analyze 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.
[edit] Link
http://wiki.doing-projects.org/index.php/Portfolio_Risk_Management_Process
[edit] Managing successful programs
[edit] 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 minimizing costs and the need for the 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 organizing planning and define common goals to achieve success.
The concept of MSP is to provide a method which manages 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.
[edit] 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
[edit] Limitations
One of the limitations of MSP is the required workload and planning since the tool has an 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 in 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.
[edit] Link
http://wiki.doing-projects.org/index.php/Managing_Successful_Programmes_(MSP)
[edit] Benefits Realisation Management
[edit] Description
The Benefits Realisation Management (BRM) is a collective set of processes and practices that define and measure the value that a project, program or portfolio management brings 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 into 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 organization to the future desired one. The main purpose of the BRM is evaluating whether the achieved benefits are in accordance with 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 that contribute to the achievement of the strategic objectives. Therefore, through the benefits of sustainment and post-project evaluations, it can be ensured the continued realization of the intended benefits.
[edit] Management
Projects and programs are driven by benefits, therefore the BRM can constitute a crucial part of their success. Mapping the benefits that can be delivered by the organization’s projects and programs and define the relationship 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 of 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 future planning.
[edit] Limitations
Although BRM is a powerful tool that has a strong influence on project success, there are limitations that may result in complicated and laborious processes. The interdependence of the benefits with internal and external elements is sometimes related to high uncertainty, which leads to the complex and ambiguous evaluation of the outcomes. Moreover, the reliability of the evaluation of the benefits may decrease due to the constraints imposed by benefits that 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 in 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.
[edit] Link
http://wiki.doing-projects.org/index.php/Benefits_Realisation_Management_(BRM)#cite_note-Fra-0
[edit] Stakeholder management
[edit] Description
A stakeholder can be any group or person that has an interest in or can be affected by a project. Stakeholders, 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
[edit] 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.
[edit] 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 organization higher up in the hierarchy in which the project organization is embedded. Downward stakeholders being members of the project team and project organization. Outward stakeholders can be both internal and external. Internal being other members of the organization 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 at 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.
[edit] Classify
Since project organization have limited resources it is, therefore, necessary to prioritize the management of stakeholders and analyze them in order to manage them accordingly. There are numerous ways to do this, and here a few of the methods will be summarized shortly.
[edit] 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
[edit] 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 utilizing 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.
[edit] Manage
After the stakeholders have been identified and classified, they now come for the practical phase: Manage. The keyword 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 prioritize the number 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 organization Participation: Stakeholders are invited in decision processes, but the final decision is with the project organization. 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 stakeholders.
[edit] Limitations
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 takes resources and the benefits may not seem worth the investment or the inputs from the stakeholders may be of low quality.
[edit] Link
http://wiki.doing-projects.org/index.php/Stakeholder_Management
[edit] Stage-gate process
[edit] Description
The 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 has to manage the project portfolio into promising and beneficial projects. The basic idea about the stage-gate process is that the project is divided into 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.
[edit] Link
http://wiki.doing-projects.org/index.php/Stage-Gate_Process
[edit] Results Framework
[edit] 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 graphical presentation, a log-series, that structural shows the project's 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 at the beginning of the identification phase of the project, for undergoing further improvements as the projects develop.
The common naming an organization uses for the results framework levels are given in the figure below
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.
[edit] Management
The results framework can be a useful tool to analyze it as a specific tool-case and its effectiveness for the organization. This tool also provides help to evaluate how the progress within each level gets measured and documented.
[edit] Limitations
For the results framework to be effective is must be continuously revised to secure that it is current for the project.
[edit] Link
https://www.toladata.com/blog/build-a-results-framework/
[edit] Cost Estimation Techniques for Projects
There is a 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 experts making the judgment.
- Analogous Estimate: Finding a 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 judgments 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 technique makes three estimates of the most likely cause, a worst-case and a best-case scenario. The final estimate is then computed by taking 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 has subcontractors or outsource certain tasks. The project manager collects cost estimations from subcontractors by sending them a detailed proposal which the subcontractors can reply to. This technique relies on the capabilities of the subcontractors/vendors.
[edit] Link
http://wiki.doing-projects.org/index.php/Cost_Estimation_Techniques_for_Projects
[edit] Lessons Learned
[edit] Description
A tool for sharing knowledge in project management. Lessons learned reports are documents generated by an organization that might have value for future projects.
The lessons learned aim 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 lesson reports that most likely have the acquired experiences to improve future projects.
The knowledge is collected at the end of the project stage, though in larger projects the lessons learned could be collected during a project. The purpose is to awake awareness of previous projects, in order to avoid the same mistakes or wrong assumptions. Positive results as an outcome of the assumption that went well are 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 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.
[edit] Management
The lessons learned tool is not a fixed template. An organization must develop their own template for applying this to include case-specific field/themes necessarily for the organization.
The procedure for the 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 the management
Collecting | the knowledge or lessons from the project that is conducted throughout 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 need to be stored, but the organization 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 categorizing of lessons learned. Categorizing and easy access is substantially for the efficient use of the conducted lessons knowledge |
Disseminating | sharing is the next important step to consider - how does the organization distribute the knowledge? |
Reusing | how do the new/other projects reuse the lessons learned data? |
An example of a lessons learned template is shown in the figure 2, developed by PRINCE2, created by Amanda Slyngborg
Instead of assessing the project in the final end, it is recommended that the lessons learned are 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 field are more open to learning from mistakes than later in the development process.
[edit] Limitations
An organization 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 are 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 differentiate between relevant and irrelevant in a cornucopia of knowledge.
• Lack of storage
If the lessons learned have been successfully conducted, it is of no-use for future projects, and a waste of work time if the lessons learned are stored in a random location. The project manager should make sure that the lessons learned will be stored in a 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 utilize 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.
[edit] Link
https://prince2.wiki/management-products/lessons-report/
[edit] Risk tolerances
[edit] Description
Risk tolerance is a significant element of a risk management plan since it identifies the degree or the amount of risk that an organization can withstand. High tolerance corresponds to a high willingness of accepting risks, that might have either a 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 risk might have. Plotting this information in a chart (Figure 3) 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.
Prioritization of the risks based on the capability of the risk-taker to endure a probable threat or opportunity is of significant importance for decision making since it leads to more efficient use of resources. In addition, it is important that risk tolerance is analyzed and revised continuously during the project lifetime.
The risk tolerance can be analyzed in different ways from either the company, the project manager and or the stakeholders. As a result, there is a possibility that risk tolerances for a project might conflict because of either the different perceptions or due to the complexity of the project.
[edit] Link
http://wiki.doing-projects.org/index.php/Risk_tolerances
[edit] Risk and Opportunities Management
[edit] Description
Risk and Opportunities management is a tool to identify risks and opportunities in a project. To avoid uncertainty in a project, the risk is identified and managed through the project life cycle. Risk management is an important concept that maintains stability and success throughout a project. The process of risk management process (RMP), is a 7-step process: Communication and consultation, establishing the context, risk identification, risk analysis, risk evaluation, risk treatment, and monitoring and review. Opportunities management deals with the positive effects that can occur throughout a project. To take advantage of all positive opportunities, OM is an important process.
[edit] Link
http://wiki.doing-projects.org/index.php/Risk_and_Opportunities_Management
[edit] Scenario Planning Strategy
[edit] Description
During the second world war, scenario planning used as a practice and became a revolutionary tool in the business sector in the upcoming decades. Scenario Planning Strategy is a systematic and methodical Strategic management tool, which aims to implement a scalable plan that will support the company in the long term. The application of scenario planning is quite broad and can be beneficial for different conditions considering a wide spectrum of possibilities. In addition, the main contributions of the tool can be seen in Preparatory Planning, Risk Management and Generation of new ideas and there is a 7-step process: define the critical issue, identify critical decision factors, analyze and rank decision factors by order of importance and uncertainty, create scenarios, identify Implications and interrelationships of scenarios, select leading scenario indicators monitoring which scenario to implement strategic plans.
[edit] Link
http://wiki.doing-projects.org/index.php/Scenario_Planning_Strategy
[edit] Earned value analysis
[edit] Description
Earned value analysis (EVA) provides objective performance indicators and quantitative analysis techniques, in order to measure the cost-efficiency. Successful execution of EVA requires a time-based schedule, work breakdown structure, cost assessment, progress measurement, responsibility/ authority matrix, and a monitoring and review process, while the main areas of application are organizational level - earned value management system (EVMS), project controlling and forecasting. As far as the key benefits are concerned, the improvement of the overall process of an organization is related to the framework, provided by EVA. On the other hand, the major drawback of EVA is not taking into consideration the sequence of work packages, created by network analysis.