Project Management: Risk Management

As all project managers know, the best project planning can never deliver a project in which all outcomes are known in advance of their occurrence.  As the saying goes; we hope for the best, but plan for the worst.  Project risk management is just that -- planning for the unknown.  And it is not an optional activity -- it is essential to successful project management.  

Project risk is any uncertain event or condition that, if it occurs, has a posiitve or negative effect on the project's objectives.

Project risk management includes the processes concerned with conducting risk identification, risk analysis, risk response and risk monitoring and control on a project.  Risk Management aims to identify and prioritize risks in advance of their occurrence, and provide action-oriented steps to increase the probability and impact of positive events during the course of the project, and to decrease the probability and impact of negative events during the course of the project. 

The general criteria for successful risk management during the course of a project are:

• Recognize the value of risk management - the management of risk must be recognized as a valuable discipline that provides a positive return on investment for the time and effort taken to assess risk
• Individual committment and responsibility - all resources on the project must take part in the risk management process
• Organizational committment - risk management must be in line with the overall goals and values of the organization
• Open and honest communication - potential project risk must be communicated early and often
• Risk effort scaled to project - the cost of project risk management must be in direct proportion to the value it will deliver on the project
• Integration with the other project management processes - risk management does not exist in the vaccum.  It must take place within the overall project management context

Project risk management includes the following steps:

• Plan risk management - defines the scope and objectives of the risk management process
• Identify risks
• Perform qualitative risk analysis - prioritize/rank the identified risks
• Perform quantitative risk analysis - evaluate the effect of risk on project outcomes
• Plan risk responses - identify response strategies and actions for all identified risks
• Monitor and control risk - implement agreed upon risk responses and assess overall effectivness of risk management plan throughout the life of the project

Vendor Assessment

The implementation of Corporate Performance Management software solution is the result of many months -- perhaps years -- of work, invovling many resources in the organization.  Most likely the decision was the result of a specific stragetic decision made by the organization, fullfilled by the successful execution of the program and project management methodoliges of the company.  The company can choose to either implement their own Corporate Management software solution, or choose from a number "off-the-shelf" software vendors in the Corporate Performance Management space. 

When an organization decides to look outside the company for it's solution, it must perform a vendor assessment to assess the ability of a potential vendor to meet commitments regarding the product/service. In doing so, there are typically 6 criteria that the company measures when choosing an external vendor:

1. Knowledge and Expertise - a common reason for using third-party vendors is that they can provide knowledge and expertise not available within the organization. In such cases, the business analyst should consider whether that expertise will need to be transferred and how capable the supplier is of performing that transfer. It may be desirable to target vendors with particular expertise in methodologies or technologies, with the goal of having that expertise transferred to people within the enterprise
2. Licensing and Pricing Models - in cases when a solution or solution component is purchased from or outsourced to an outside vendor, the licensing or pricing model will need to be taken into account. In many cases, solutions that offer similar functionality may differ greatly in their licensing models, requiring an analysis of different usage scenarios to determine which option will provide the best cost/benefit ratio under the scenarios likely to be encountered in the enterprise.
3. Product Reputation and Market Position - how many customers are currently using the product or service? Is the product widely accepted or used in similar organizations? Is there a regular update schedule and roadmap of features that are planned for delivery?
4. Terms and Conditions - are the services provided by the vendor to be temporary or permanent? The business analyst should investigate whether the vendor’s licensing terms and technology infrastructure are likely to present challenges if the organization later chooses to transition to another supplier. There may also be considerations regarding the vendor’s use of and responsibility for protecting the integrity of the organization’s confidential data. In addition, the terms under which customizations of the product should be considered.
5. Vendor reputation - the vendor’s experience with other customers may provide valuable information on how likely it is that they will be able to meet their contractual and non-contractual obligations. The vendor can also be evaluated for conformance and compliance with external relevant standards for quality, security, and professionalism.
6. Vendor Stability - how certain is it that the vendor will be able to provide the required services in the future? It may be necessary to request that steps be taken to ensure that there are no risks if the vendor encounters financial difficulties and that it will be possible to maintain and enhance the solution even if the vendor’s situation changes radically.

While vendor assessment can be a time consuming task for the organization, an effective vendor assessment reduces the risk of the organization developing a relationship with an unsuitable vendor and is likely to improve the successful implementation of the required solution.

Business Analysis: Knowledge Areas

The business analysis body of knowledge defines 6 knowledge areas, which group together related sets of tasks and techniques. Each of these tasks and techniques describes the typical knowledge, skills, processes, and deliverables that the business analyst requires to be able to perform those tasks competently.

Business analysts are likely to perform tasks from all knowledge areas in rapid succession, iteratively, or simultaneously. Tasks may be performed in any order as long as the required inputs are available.

The following knowledge areas are not intended to represent phases in a project. It is certainly possible and permissible to proceed in a waterfall-like fashion, however, true business analysis does not require that you do so, and it should not be construed as a methodology for the performance of business analysis.

1. Business Analysis Planning and Monitoring is the knowledge area that covers how business analysts determine which activities are necessary in order to complete a business analysis effort. It covers identification of stakeholders, selection of business analysis techniques, the process that will be used to manage requirements, and how to assess the progress of the work. The tasks in this knowledge area govern the performance of all other business analysis tasks.
2. Elicitation describes how business analysts work with stakeholders to identify and understand their needs and concerns, and understand the environment in which they work. The purpose of elicitation is to ensure that a stakeholder’s actual needs are understood, rather than their stated or superficial desires.
3. Requirements Management and Communication describes how business analysts manage conflicts, issues and changes in order to ensure that stakeholders and the project team remain in agreement on the solution scope.  It also describes how requirements are communicated to stakeholders, and how knowledge gained by the business analyst is maintained for future use.
4. Enterprise Analysis describes how business analysts identify a business need, refine and clarify the definition of that need, and define a solution scope that can feasibly be implemented by the business. This knowledge area describes problem definition and analysis, business case development, feasibility studies, and the definition of solution scope.
5. Requirements Analysis describes how business analysts prioritize and progressively elaborate stakeholder and solution requirements in order to enable the project team to implement a solution that will meet the needs of the sponsoring organization and stakeholders. It involves analyzing stakeholder needs to define solutions that meet those needs, assessing the current state of the business to identify and recommend improvements, and the verification and validation of the resulting requirements.\
6. Solution Assessment and Validation describes how business analysts assess proposed solutions to determine which solution best fits the business need, identify gaps and shortcomings in solutions, and determine necessary workarounds or changes to the solution. It also describes how business analysts assess deployed solutions to see how well they met the original need so that the sponsoring organization can assess the performance and effectiveness of the solution.

As I alluded to in the introduction, there are specific tasks, tools & techniques associated with each of these knowledge areas.  I have spoken about a few of them in earlier posts:

• Scenario and Use cases - applicable to the Business Analysis Planning and Monitoring knowledge area
• Benchmarking, Metrics and KPI's - applicable to the Business Analysis Planning and Monitoring, Enterprise Analysis and  Requirements Analysis knowledge areas

 Please be sure to join me in the future for a more in depth discussion of other tasks, tools & techniques. 

Corporate Performance Management: Software Vendors

As we've discussed, Corporate performance management is a step-by-step process, which includes:

1. Defining the goals of a company or business unit (strategic planning)
2. Attaching KPI's and metrics that will be used to measure those goals (benchmarking)
3. Gathering the relevant data for those KPI's and metrics (benchmarking)
4. Consolidating and reporting on that data (financial reporting)
5. Comparing and contrasting the actual performance vs. performance goals (the budgeting process)
6. Making operational and strategic decisions in light of that information (The Balanced Scorecard)

People working in corporate performance management utlitize software tools that ease their day-to-day duties, especially when the task involves gathering and analyzing large amounts of unstructured data.

Software tool categories commonly used for business performance management include:

• OLAP (online analytical processing) - enable users to interactively analyze multidimensional data from multiple perspectives
• Scorecarding, dashboarding and data visualization -  a user interface that is designed to be easy to read, providing the user with a visual representation of KPI's and metrics
• Data warehouses - is a database used to house, report and analyze company data
• Data mining - is the process of discovering new patterns from large data sets
• Decision support systems - information system that supports business or organizational decision-making activities

There are a plentora of vendors in the Corporate Performance Management space.  The following is a list of the major players in the industry:

• IBM Cognos
• Oracle Hyperion
• Longview Khalix
• SAP
• Prophix
• Tagetik