Chapter+7

Hi Group 1, add or modify your content in this page by Sunday Nov 8 at 2359.

=** [20091103] Please don't direct copy from the web and try to use your own words to describe!!! **=

=**Table of Content**= [g1-3705]

flat

[g1-2816]

=10 musts for Earned value of project management=

Define Work Scope The most challenging and most critical requisite to employ earned value technique is to define the project’s total work scope. How does one define a job when specific details are often lacking ? I think the most useful of all tools available to any project manager is the WBS (work breakdown structure). It allows the project manager to define a new endeavor by laying out all the assumed work and decomposing each task into measurable work packages.

Create an Integrated Bottom-up Plan After that, we must combine critical processes, including defined work scope, schedule and all other estimated resources into an integrated bottom-up plan of detailed measurement cells called Control Account Plans (CAPs). Performance measurement will take place within the detailed CAPs and the total project’s performance is the summation of what was reflected in the detailed CAPs.

Formally Schedule CAPs Each CAP must be scheduled with a formal scheduling system. This system will portray the approved work scope into a specific timeframe for performance. In earned-value vernacular, this work will constitute the project’s planned value. As performance takes place, the portion of the planned value that is physically accomplished becomes the earned value. The planned value and the resulting earned value must use the same metrics to measure their performance.

Assign each CAP to an executive for performance This assignment effectively commits the executive to oversee the performance of each CAP. Projects are by their nature transient within any firm’s permanent organizational structure, then eventually go out of existence.

Establish a Baseline that summarize CAPs Baseline must be established which can represent the summation of the detailed CAPs. Such baseline must include all defined CAPs plus any management reserves that may be held by the project manager.

Measure performance against schedule A negative schedule variance means that the value of the work accomplished does not match the value of the work scheduled which means the project is falling behind in its scheduled work. We must avoid negative schedule variance happened.

Measure cost efficiency against the costs incurred This represents the relationship between the project’s earned value performed and the costs incurred to achieve the earned value. The cost efficiency factor is an important metric for project manager to monitor.

Forecast final costs based on performance One of the beneficial aspects of the earned-value concept is its ability to independently forecast the total required funds at the end of a project. Based on performance against the plan, manager can accurately estimate the total funds within a finite range of values.

Manage remaining work Earned value allows the project to accurately quantify the value of its work achieved and also allows the project manager to quantify the value of the work ahead to stay within the objectives set by management.

Manage baseline changes We must continuously maintain the baseline by managing all changes to the baseline. All new changes of project work must be addressed either by the approval or rejection of changes. Maintaining a baseline is as challenging as the initial definition of the project scope at the start of the project.

 [g1-3494]

Project management is a complex, planned and organized effort with many stages and processes. Most of the project should follow the full business lifecycle. from definition and justification of the project, through to delivering demonstrable benefits for the business.

Project management includes developing a project plan, which includes defining and confirming the project goals and objectives, identifying tasks and how goals will be achieved, quantifying the resources needed, and determining budgets and timelines for completion. It also includes managing the implementation of the project plan, along with operating regular 'controls' to ensure that there is accurate and objective information on 'performance' relative to the plan, and the mechanisms to implement recovery actions where necessary.

Entreprise need project management because it take the benefits of organising work around projects. Additionally, the critical need to co-ordinate, communicate work across different departments and professions.

The ultimate objective of project management are to ensure the delivery of quality products that finally output in projects, that are completed on time, within budget and accomplish the stated business objectives.

[g1-3705] risk media type="youtube" key="wJ8HZ7hqUs8" height="344" width="425" Project Management consist of three core components: Reference: The Project Management Life Cycle, A complete step-by-step [g1-2594] =Nine Knowledge for Project Management=
 * A set of skills. Specialist knowledge, skills and experience are required to reduce the level of risk within a project and thereby enhance its likelihood of success.
 * A suite of tools. Various types of tools are used by project managers to improve their chances of success. Examples include document templates, registers, planning software, modeling software, audit checklists and review forms.
 * A series of processes. Various processes and techniques are required to monitor and control time, cost, quality and scope on projects. Examples include time management, cost management, quality management, change management, risk management and issue management.

There are nine knowledge for project management. For each knowledge, it contain some or all of the project management processes.


 * 1.** **Project Integration Management**

Project integration management is primarily concerned with integrating processes to accomplish project objectives. The seven process are: - Develop Project Charter - Develop Preliminary Project Scope Statement - Develop the Project Management Plan - Direct and Manage Project Execution - Monitor and Control Project Work - Integrated Change Control - Close Project The seven processes in the Project Integration Management knowledge area work in concert to facilitate proper project coordination. The project integration requires each process seamlessly links and fuels the next process

**2.** **Project Scope Management**

The Scope Statement provides a common understanding of the project among stakeholders. Some organizations create a separate Scope Statement Document while others make it a part of the Project Charter or Project Plan.

Project Scope Management comprises five processes: - Scope Planning - Scope Definition - Create work break down structure - Scope Verification - Scope Control


 * 3. Project Time Management**

Project Time Management is all about recording the time spent by people on a project. To record time spent, the team implement a Project Time Management Process (or "Time Process"). This time process involves recording the time spent on tasks, using Time sheets. The time process helps the manager know which tasks has been worked on, when and for how long.


 * 4. Project Cost Management**

Several major functions of project cost management - Identify each of the costs of the project - Keep a central record of all costs incurred -  Control the overall cost of project


 * 5. Project Quality Management**

Quality Management has to deal with deliverable of the project. The objective of the project management is to generate quality deliverable by ensuring the project to be satisfied the needs for which it was undertaken.


 * 6. Project Human Resource Management**

This element deals with all aspects of human resources, from resource planning to acquiring, developing and managing the project team with a view to making the most effective use of the people involved.


 * 7. Project Communication Management**

During project management process, effective communication is of great importance to ensure timely and appropriate generation, collection, dissemination, storage and disposition of project. This element deals with who needs to know what and when. Processes covered by communication management include:

- Communications Planning - Information Dissemination - Reporting Performance - Stakeholder Management


 * 8. Project Risk Management**

Risk Management is a vital element for managing a successful project. Processes include:

- Risk management planning - Risks Identification - Qualitative and quantitative risk analysis - Planning risk response - Risk monitoring and control


 * 9. Project Procurement Management**

Procurement Management is the final element of the project management relating to acquiring goods and services. There are six processes in this element:

- Planning purchases - Acquisitions - Plan contracting - Requesting responses from sellers - Selecting sellers - Administering contracts and closing contracts

Reference: []

[g1-2594]

[g1-3705]

A "Dashboard" concept for "Project Health Status".

[g1-0800]

=Project Management= =Five Phases of Project Management=
 * IT and business unit managers
 * enforce a project plan which includes
 * job responsibilities
 * time lines for major stages of development
 * financial budgets
 * Initiating/defining
 * State the problems/goals
 * Identify the objectives
 * Secure resources
 * Explore costs/benefits in feasibility study
 * Planning
 * Identify and sequence activities
 * Identify the 「critical path」
 * Estimate time and resources needed for completion
 * Write a detailed project plan
 * Executing
 * Commit resources to specific tasks
 * Add additional resources/personnel if necessary
 * Initiate project work
 * Controlling
 * Establish reporting obligations
 * Create reporting tools
 * Compare actual progress with baseline
 * Initiate control interventions if necessary
 * Closing
 * Install all deliverable
 * Finalize all obligations/commitments
 * Meet with stakeholders
 * Release project resources
 * Document the project
 * Issue final report



=Projects and Programs=

[g1-8900]

The purpose of both projects and programs is to produce a product or service, or both, according to a requirement, by some moment in time, for a certain cost. A project is performed for an in-house customer; a program is performed for an out-of-house customer under aegis of a legal contract. in order to accomplish this, a requirement is developed and assigned to a group for execution. The group, led by a project or program manager, plans how they will perform the task and documents the plan. Then, they go about executing the plan. Finally, when the task is completed, the project or program is closed, and the product is transferred to the originator of the requirement.



Ref: [Your successful project management career] Ronald B. Cagle.

Project Manager's Role and Responsibilities
[g1-3494]

The Project Manager is the person responsible for ensuring that the Project Team completes the project. The Project Manager develops the Project Plan with the team and manages the team's performance of project tasks. It is also the responsibility of the Project Manager to secure acceptance and approval of deliverable from the Project Sponsor and Stakeholders.

The Project Manager is responsible for communication, including status reporting, risk management, escalation of issues that cannot be resolved in the team. In general, making sure the project is delivered in budget, on schedule, and within scope.

Once the project starts, the project manager must successfully manage and control the work, including:
 * __Process Responsibilities__**


 * Identifying, tracking managing and resolving project issues
 * Proactively disseminating project information to all stakeholders
 * Identifying, managing and mitigating project risk
 * Ensuring that the solution is of acceptable quality
 * Proactively managing scope to ensure that only what was agreed to is delivered, unless changes are approved through scope management
 * Defining and collecting metrics to give a sense for how the project is progressing and whether the deliverable produced are acceptable
 * Managing the overall schedule to ensure work is assigned and completed on time and within budget

This does not mean that the project manager physically does all of this, but they must make sure it happens. If the project has problems, or scope creep, or faces risks, or is not setting expectations correctly, then the project manager is the person held accountable.

To manage the project management processes, a person should be well organized, have great follow-up skills, be process oriented, be able to multi-task, have a logical thought process, be able to determine root causes, have good analytical ability, be a good estimator and budget manager, and have good self-discipline. People Responsibilities

__**People Responsiblilties**__ In addition to process skills, a project manager must have good people management skills. This includes:


 * Having the discipline and general management skills to make sure that people follow the standard processes and procedures
 * Establishing leadership skills to get the team to willingly follow your direction. Leadership is about communicating a vision and getting the team to accept it and strive to get there with you.
 * Setting reasonable, challenging and clear expectations for people, and holding them accountable for meeting the expectations. This includes providing good performance feedback to team members
 * Team building skills so that the people work together well, and feel motivated to work hard for the sake of the project and their other team members. The larger your team and the longer the project, the more important it is to have good team-building skills.
 * Proactive verbal and written communicator skills, including good, active listening skills.

They are responsible for the success of the project. If the team has poor morale and is missing deadlines, you need to try to resolve it. If team members don't understand exactly what they need to do and when it is due, then you are responsible.

Ref: http://civilengineerlink.com/project-manager-responsibilities/ http://www.buzzle.com/articles/project-manager-duties-and-responsibilities.html

IT-enabled Business Change: An Approach to Understanding and Managing Risk
[g1-1258]

The problem stems from senior and project management failing to take three steps:

(1) Assessing the risks of the change up front the most serious are the changes needed in the business, not the changes in the technology Three predominant risk factors: – Leadership of the business change – Employees' perspective of the change – Scope and urgency of the change

(2) Mitigating the causes of highest risk at the front end and as the project progresses; – Project management styles  Authoritative Vs. Participative – Project's budget and time frame  Rigid Vs. Adjustable – Gibson's Four Approaches  • Big Bang - Only appropriate when all 3 factors = positive  • Improvisation - Leadership and employee = positive but scope or urgency place the project at risk - Committed workforce can adapt etc.  • Guided Evolution - Used when only the employee perception is negative - Can be overcome by involving them  • Top-down Coordination - Only works when the leadership factor supports the business change and when the leadership is respected, full-time and highly experienced in leading business change

(3) Adjusting the method of project management to minimize the remaining risks.

This assess-mitigate-adjust approach aims to minimize the risks over a project's life cycle and thereby increase the changes of success.

Good IT Project Management
• Establish the Ground Rules – Open systems, industry standards, web-enabled etc. • Foster Discipline, Planning, Documentation and Management – If the process is not controlled properly, anything can happen or, more realistically, potentially nothing will happen • Obtain and Document the 『Final' User Requirements – Don't get too technical • Obtain Tenders from All Appropriate Potential Vendors • Include Suppliers in Decision Making • Convert Existing Data – Task might appear quite simple but often causes the biggest headaches • Follow Through After Implementation – Cross the t's and dot the i's in terms of documentation, future maintenance processes etc.

Change Management
It would typically be composed of the raising and recording of changes, assessing the impact, cost, benefit and risk of proposed changes, developing business justification and obtaining approval, managing and co-coordinating change implementation, monitoring and reporting on implementation, reviewing and closing change requests. The goal of the Change Management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization. Change management is responsible for managing change process involving: 1. Hardware 2. Communications equipment and software 3. System software 4. All documentation and procedures associated with the running, support and maintenance of live systems.

Reference: [] [Management The Job of a Project Manager] [|http://en.wikipedia.org/wiki/Change_Management_(ITSM)#Change_management_in_development_projects]

[g1-8038]

Project Initiation Document

 * KickOff Meeting
 * Quality Assurance

Project Process
In project process describes the procedures you would take as a Project Manager, to manage an element of the project and how to identify, review, mitigate and monitor project risks more effectively.
 * Time Management Process - The overview timing control of statue in the project, part of the project schedule.
 * Cost Management Process - Manage the overall project expenditure
 * Quality Management Process -Ensure that your deliverable meet the requirements of project
 * Change Management Process -Identify & mange the uncontrollably, eg: Ad-hot request, leads to delays, over-spending and poor deliverable quality
 * Risk Management Process - Under the fixed resource, how to manage the project risk to success
 * Issue Management Process -Base on the Risk Management, considering that how afford your overall plan or re-schedule.
 * Tender Management Process -3 issues for supplier support: Statement of Work (SOW), Request for Information (RFI) and Request for Proposal (RFP).
 * Procurement Management Process -After Tender Management Process, you should be make a selection from the supplier.
 * Acceptance Management Process -This can help you how to understanding & completely satisfy Customer/User needs
 * Communications Management Process -Keep your stakeholders informed of the progress of the project at all times.

Closure
= =
 * Lesson Learned

Expectation Management
Expectation Management is a planning override Quality Assurance, Risk Management, Human Management

Joseph Yam has make a definition of expectation management: "Expectation management is very much a part of life. We do it before breaking bad news to minimize adverse impact. We do it before breaking good news to maximize favorable response."

Security Concerns on Legacy System Migration
The steps of Legacy System mitigation security concerns :


 * 1) **List All Legacy Systems**


 * 1) **Identify Potentially High-Risk Systems**


 * 1) **Assess Potentially High-Risk Systems**


 * 1) **Define Security Mitigation Projects**
 * Do Nothing


 * Harden the legacy system


 * Enhance the legacy system


 * Replace the legacy system

Implementing Legacy System Mitigation Projects

[]

Risk Management
[g1-3494]

Risk management consists of identification, analysis and assessment of all risks. Effective measures can help to establish and control the risk. By understanding of what needs to be control, organization can take the appropriate actions to overcome the risk.

The objective of Risk Management is to guarantee organization identifies and know the risks that will be exposed. The other objectives is to help the organization to creates and complete an effective plan to avoid losses or minimize impact if a loss occurs.

 Ref: http://en.wikipedia.org/wiki/Risk_management

= ** The benefits of risk management ** =

An effective risk management is important to project management. It can supporting a strategic and business planning, manager can mitigate the risk and adjust the project approach. It also is promoting continuous improvement. On the other hands, objectives are more likely to be achieved, so that the damaging things are less likely to happen. [g1-2594]

Risk Management - Business Risk
[g1-3494]

A business risk is a circumstance or factor that may have a negative impact on the operation or profitability of a given company. Sometimes referred to as company risk, a business risk can be the result of internal conditions, as well as some external factors that may be evident in the wider business community.

In general, any investor will consider the relationship of a company's securities and the business risk associated with the company before choosing to invest in the future of the corporation. While there is an element of business risk associated with any corporate operation, proper management will result in creating a balance between assets and securities that will keep the degree of business risk attractive to individuals and entities that consider investing funds into the operation.

Market risk is the risk that the value of an investment will decrease due to moves in market factors. The market will not respond to your products or services, either because there is no real market need or the market isn't yet ready. Market risks are very difficult to overcome.
 * __Market Risk__**

Volatility frequently refers to the standard deviation of the change in value of a financial instrument with a specific time horizon. It is often used to quantify the risk of the instrument over that time period. Volatility is typically expressed in annualized terms, and it may either be an absolute number ($5) or a fraction of the initial value (5%).

Ref: http://en.wikipedia.org/wiki/Market_risk

__**Strategic risk**__ Strategic risk is the current and prospective impact on earnings or capital arising from adverse business decisions, improper implementation of decisions, or lack of responsiveness to industry changes. This risk is a function of the compatibility of an organization's strategic goals, the business strategies developed to achieve those goals, the resources deployed against these goals, and the quality of implementation.

Ref: []



Advantage of using Risk Management
[g1-3494]

Risk management can give a clear and structured approach to identifying risks. If organization can understand their risks, this can allows an organization to plan and organize them. Organization can make some proper actions to minimize losses.

Moreover, Risk management has the following advantage:


 * Maintain the organization image and rank
 * Stabling organization operations
 * Save all valuable resources, for example income, time, labour
 * Reduce asset
 * Assist to define the suitable insurance
 * Improve the ability to handle different situation

=Risk Assessment= Risk assessment is the first process in risk management. Organization use risk assessment to determine the extene of the potential threat and the risk associated with an IT system. The output of the process helps to identify appropriate controls for reducing or eliminating risk during the risk mitigation process.

Risk is a function of the likelihood of a given threat-source's exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization.

To determine the likelihood, threats to an IT system must be analyzed in conjunction with the potential vulnerabilities and the controls in place for the IT system. Impact refers to the magnitude of harm that could be caused by a threat's exercise of a vulnerability. The level of impact is governed by the potential mission impacts and in turn produces a relative value for the IT assets and resources affected. The risk assessment encompasses nine primary steps shown in the following:

RISK IDENTIFICATION
[g1-8102] Risks occur in IT systems when vulnerabilities (i.e., flaws or weaknesses) in the IT system or its environment can be exploited by threats (i.e. natural, human, or environmental factors). For example, Oracle 9i will stop responding when sent a counterfeit packet larger than 50,000 bytes. This flaw constitutes a vulnerability. A malicious user or computer criminal might exploit this vulnerability to stop an IT system from functioning. This possibility constitutes a threat. This vulnerability-threat pair combines to create a risk that an IT system could become unavailable. The process of risk identification consists of three components: 1. Identification of vulnerabilities in the IT system and its environment; 2. Identification of credible threats that could affect the IT system; and 3. Pairing of vulnerabilities with credible threats to identify risks to which the IT system is exposed.

Identification of Vulnerabilities
The first component of risk identification is to identify vulnerabilities in the IT system and its environment. There are many methodologies or frameworks for determining IT system vulnerabilities. The methodology should be selected based on the phase of the IT system is in its life cycle.

Identification of Credible Threats
The purpose of this component of risk identification is to identify the credible threats to the IT system and its environment. A threat is credible if it has the potential to exploit an identified vulnerability.

Identification of Risks
The final component of risk identification is to pair identified vulnerabilities with credible threats that could exploit them and expose the following to significant risk:
 * IT system;
 * The data it handles; and
 * The organization.

-

[g1-0260]

** Risk management **
Risk management is the process of risk identification, risk mitigation and evaluation and assessment. All of these steps can minimize delays, reduce cot, improve ROI and increase the number of opportunity. So risk management plays a critical role in protecting an organization’s information assets. An effective risk management process is important for an organization.

__ **Risk Identification** __ Risk management process is going through all the activities to identify the risks that have an impact on the project. During the process, new risks will appear. These risks will be documented. __ There are some tools and techniques used to identify risks. __ 1. Documentation review: This technique require us to go through all the assumptions, project plans and project outcome. Then we can find out a risk in project. 2. Information gathering: It requires project’s stakeholders to arrange a meeting and from the primary data the group of people comes up with the list of risk. 3. Diagramming technique: Diagramming technique is also common risk identification process in project risk management. 4.Assumption analysis: Assumptions analysis is a process of validating assumptions that are made previously and then documenting the risks as the project progresses.

__ **Risk mitigation** __ Risk mitigation is the second process of risk management. This process provides some options that can be used to implement the appropriate risk-reducing control. This process is not used to eliminate all risk from the IT project. It only reduces the risk to appropriate level. Risk mitigation can be achieved by the following risk mitigation options:

1. Risk Avoidance. To avoid the risk by eliminating the risk cause and/or consequence 2. Risk Limitation. To limit the risk by implementing controls that minimize the adverse impact of a threat’s exercising a vulnerability 3. Risk Transference. To transfer the risk by using other options to compensate for the loss, such as purchasing insurance.

All of these options cannot be practical to address all identified risks. We need to prioritize the threats that cause significant impact. Then we select the suitable options. Moreover, every organization has its own environment and mission. These options can also used to mitigate the potential risk in organization. A good risk management can bring a lot of benefits to the organization. If the potential risks can be identified earlier, the organization can fix the risk during the risk mitigation process. The project delivery time will be more flexible and the cost can be reduced. So the top manager can concentrate on other opportunities which can enhance the output of the project furthermore. A good risk management also ensures a return on investment and avoids the late delivery which causes repay investment.

=Project Risk Management Plan= [g1-6880] As we know a project risk management is very important for the project that ensure the process of project run smoothly. A project risk management plan is essential tasks in whole project. The plan should contains the following items:


 * Define which the risk management methods should be used, for example, the risk identification, categorize risk and risk impact assessment, etc.
 * Make assumptions that have a significant impact on the project
 * Define the roles and responsibilities to manage and handle the risk
 * Define Risk Management Milestones
 * Define risk rating/scoring techniques
 * Establish risk thresholds
 * Define risk communications
 * Define risk tracking process

Symantec is large company that not only product software but also provides a number of services and solutions, they understands IT risk as encompassing security, availability, performance and compliance, all of which are related to the requirements of both IT services and the business organization. The importance of risk analysis is discussed in relation to the overall Symantec Integrated IT Risk Management methodology. The below figure is the Symantec five-step IT risk management process: The five steps may be summarized as follows: Step 1: Acknowledge and understand all aspects of IT risk, as they fall into the four categories outlined in the Operational risk and IT risk Step 2: Quantify the impact that the categories of IT risk will have on the identified critical business assets that are the responsibility of IT services Step 3: Design appropriate solutions that will enable effective and efficient management of the identified risks Step 4: Implement the designed solutions in such a way that they will reduce business impact to a minimum and maximize the value of IT services to the business Step 5: Ensure that efficient and effective IT risk management is baked in to the way in which the organization conducts its business

Ref: Symantec White paper for integrated IT Risk management 2007

The Proactive Risk Strategy
[g1-8900]

Project risk management addresses the following questions: A proactive risk strategy should always be adopted, as shown in figure under. It is better to plan for possible risk than have to react to it in a crisis.  Ref: [Leading IT projects : the IT manager's guide] / Keyes, Jessica
 * Are we losing sight of goals and objectives as the project moves forward?
 * Are we ensuring that the results of the project will improve the organization's ability to complete its mission? The result should be an improvement over the previous process.
 * Are we ensuring availability of sufficient funds, including funds to address risks?
 * Are we tracking implementation to ensure that "quicker/better/cheaper" objectives are being met?
 * Are we applying appropriate risk management principles throughout the project?
 * Are we taking corrective action to prevent or fix problems, rather than simply allocating more money and time to them?
 * Have changes in the environment, such as new IT systems or leadership, created new risks that need to be managed?

Risk Exposure
[g1-3494]

A problem when you have a number of possible risks is that it can be difficult to decide which risks are worth putting effort into addressing. Risk Exposure is a simple calculation that gives a numeric value to a risk, enabling different risks to be compared.

Risk Exposure of any given risk = Probability of risk occurring x total loss if risk occurs

A limitation of this calculation is that it will give the same scores to high-probability/low loss risks and low-probability/high loss risks. If you are concerned with these differences, a Risk Matrix may be a better way of evaluating risks.

Example:

「The probability that a server will be delayed is 60%. The impact out of 10 is 7, which is very damaging. Therefore, the exposure is 60% of 7, which is 4.2.」

=Legacy Systems= [g1-4939] Legacy System is an older software systems that remain vital to an organisation

1) Software systems that are developed specially for an organisation have a long lifetime 2) Many software systems that are still in use were developed many years ago using technologies that are now obsolete 3) These systems are still business critical that is, they are essential for the normal functioning of the business 4) They have been given the name legacy systems

=Legacy system replacement= There is a significant business risk in removing a legacy system and replacing it with a system that has been developed using modern technology 1) Legacy systems rarely have a complete specification. During their lifetime, they have major changes which may not have any documentation 2) Business processes depend on the legacy system 3) The system may embed business rules that are not formally documented elsewhere 4) New software development is risky and may not be successful

=Legacy system change= Systems must change in order to remain useful. However, changing legacy systems is often expensive 1) Different parts implemented by different teams so no consistent programming style 2) The system may use an obsolete programming language 3) The system documentation is often out-of-date 4) The system structure may be corrupted by many years of maintenance 5) Techniques to save space or increase speed at the expense of understandability may have been used 6) File structures used may be incompatible

=The legacy dilemma= 1) It is expensive and risky to replace the legacy system 2) It is expensive to maintain the legacy system 3) Businesses must weigh up the costs and risks and may choose to extend the system lifetime using techniques such as re-engineering.

=Legacy system structures= Legacy systems can be considered to be socio-technical systems and not simply software systems 1) System hardware - may be mainframe hardware 2) Support software - operating systems and utilities 3) Application software - several different programs 4) Application data - data used by these programs that is often critical business information 5) Business processes - the processes that support a business objective and which rely on the legacy software and hardware 6) Business policies and rules - constraints on business operations

=Legacy system design= 1) Most legacy systems were designed before object-oriented development was used 2) Rather than being organised as a set of interacting objects, these systems have been designed using a function-oriented design strategy 3) Several methods and CASE tools are available to support function oriented design and the approach is still used for many business applications

=Legacy system assessment= 1) Organisations that rely on legacy systems must choose a strategy for evolving these systems --Scrap the system completely and modify business processes so that it is no longer required --Continue maintaining the system --Transform the system by re-engineering to improve its maintainability --Replace the system with a new system 2) The strategy chosen should depend on the system quality and its business value

Legacy system categories 1) Low quality, low business value. --These systems should be scrapped 2) Low-quality, high-business value --These make an important business contribution but are expensive to maintain. Should be re-engineered or replaced if a suitable system is available 3) High-quality, low-business value --Replace with COTS, scrap completely or maintain 4) High-quality, high business value --Continue in operation using normal system maintenance

=Options for Improving Legacy Systems=

1. Restructure the System
[g1-3494]

Restructuring can be defined as follows:

"Restructuring is the transformation from one representation form to another at the same relative abstraction level, while preserving the subject system's external behavior (functionality and semantics)."

Therefore, restructuring is something that you do while remaining at the same phase of software engineering life cycle. It's example can be the Normalization of the database at the design phase, i.e. taking the database design from 1st Normal Form to 2nd Normal Form to 3rd Normal Form and then from there to BNF (if necessary). So this is what you are doing while remaining at the same phase of Software Engineering, i.e. the Design phase. You have transformed a crude design into a more structured design. You are just restructuring the information that you have during the design phase, in another form that is more structured, clearer and less ambiguous. So you are achieving some benefit with the help of restructuring. Similarly, during the Implementation phase, if you are replacing your "bubble sort" algorithm with a "quick sort" algorithm in order to enhance the performance of the system, then this is also called restructuring but at a different level of abstraction.

2. Reengineer the System
[g1-3494]

The application of technology and management science to the modification of existing systems, organizations, processes, and products in order to make them more effective, efficient, and responsive.

Responsiveness is a critical need for organizations in industry and elsewhere. It involves providing products and services of demonstrable value to customers, and thereby to those individuals who have a stake in the success of the organization. Re-engineering can be carried out at the level of the organization, at the level of organizational processes, or at the level of the products and services that support an organization's activities.

The entity to be reengineered can be systems management, process, product, or some combination. In each case, reengineering involves a basic three-phase systems-engineering life cycle comprising definition, development, and deployment of the entity to be re-engineered.

__**Reverse Engineering**__ Reverse engineering is the general process of analyzing a technology specifically to ascertain how it was designed or how it operates. This kind of inquiry engages individuals in a constructive learning process about the operation of systems and products. Reverse engineering as a method is not confined to any particular purpose, but is often an important part of the scientific method and technological development. The process of taking something apart and revealing the way in which it works is often an effective way to learn how to build a technology or make improvements to it.

Through reverse engineering, a researcher gathers the technical data necessary for the documentation of the operation of a technology or component of a system. In "black box" reverse engineering, systems are observed without examining internal structure, while in "white box" reverse engineering the inner workings of the system are inspected.

When reverse engineering software, researchers are able to examine the strength of systems and identify their weaknesses in terms of performance, security, and interoperability. The reverse engineering process allows researchers to understand both how a program works and also what aspects of the program contribute to its not working. Independent manufacturers can participate in a competitive market that rewards the improvements made on dominant products. For example, security audits, which allow users of software to better protect their systems and networks by revealing security flaws, require reverse engineering. The creation of better designs and the interoperability of existing products often begin with reverse engineering.

Forward engineering is the traditional process of moving from high-level abstractions and logical designs to the physical implementation of a system. In some situations, there may be a physical part without any technical details, such as drawings, bills-of-material, or without engineering data, such as thermal and electrical properties.
 * __Forward Engineering__**

__**Reverse Engineering VS Forward Engineering**__

The most traditional method of the development of a technology is referred to as "forward engineering." In the construction of a technology, manufacturers develop a product by implementing engineering concepts and abstractions. By contrast, reverse engineering begins with final product, and works backward to recreate the engineering concepts by analyzing the design of the system and the interrelationships of its components.

Ref: http://en.wikipedia.org/wiki/Reengineering_(software) http://users.ecs.soton.ac.uk/harnad/Hypermail/Explaining.Mind96/0104.html

[ g1-5006 ] =Options for Improving Legacy Systems [ con't ]=

Following are reasons for reverse engineering a part or product:
 * Reverse engineering which is common in different areas as software engineering, entertainment, automotive, consumer products, microchips, chemicals, electronics, and mechanical designs. For example, when a new product is produced, other manufacturers may purchase the product and explore the product to learn how it was built and how it works. A chemical company may use reverse engineering to defeat a patent on a competitor's manufacturing process. In civil engineering, bridge and building designs are copied from past successes therefore, the chance of failure would be greatly reduce. In software engineering, good source code is often a variation of other good source code.**
 * 1) The original manufacturer of a product will not be manufacture or production. There is inadequate documentation to explore the old design of product
 * 2) The original manufacturer no longer exists, but the products still have market.
 * 3) The original design documentation has been lost or never existed
 * 4) Some bad features of a product need to be designed out. For example, excessive wear might indicate where a product should be improved
 * 5) To strengthen the good features of a product based on long-term usage of the product
 * 6) To analyze the good and bad features of competitors' product
 * 7) To explore new avenues to improve product performance and features
 * 8) To gain competitive benchmarking methods to understand competitor's products and develop better products
 * 9) The original CAD model is not sufficient to support modifications or current manufacturing methods
 * 10) The original supplier is unable or unwilling to provide additional parts
 * 11) The original equipment manufacturers are either unwilling or unable to supply replacement parts, or demand inflated costs for sole-source parts
 * 12) To update obsolete materials or antiquated manufacturing processes with more current, less-expensive technologies

=Options for improving a legacy system (cont.) 2=

[g1-4808] e.g. enhancing the usefulness by replacing furniture, landscaping in the house. Refurbish the system mean if the old system is maintainable and causing no major problems. It may be refurbished by adding "extensions". Supply input in a new manner; make new uses of input or allow the programs to deal more comprehensively with the data. Occurring quite a bit these days with the 『web', old system an 『untouchable' black box surrounded by new systems.
 * Refurbish the system:**

e.g. adding new functions in the house, each as new room, pool.etc. Rejuvenate the system mean adding new functions to a re-engineered system to make it more valuable. Phases of rejuvenation process include recognize a system's potential, clean up the system, make the system more efficient and give the system more strategic role. feed a data warehouse of become back-end system accessible via web. e.g. rethinking the use of space by perhaps gutting a major portion of the house and remodeling it by combining kitchen and dinning room. Rearchitect mean to the increasing complexity of enterprise systems, the advent of inter-enterprise systems, and the independence of interlinked systems in supply chains, CTOs are designing enterprise IT architecture.Where possible CTOs work hard to migrate their enterprise to that desired to-be architecture, generally one system at a time. e.g. the house no longer works for you, move to another house. it is like to move an old application to a new operating environment. centralized to distributed. e.g. knock down and build a new one in the same location. System is too far gone to rescue, obsolete technology; beware of true cost and risk failure.
 * Rejuvenate the system:**
 * Rearchitect the System:**
 * Replace with a Package or Service:**
 * Rewrite the System:**

[g1-2644] =Simplified options for improving a legacy system=

There are four approaches for preserving and extending applications, ranging from the quick and simple to the sophisticated and flexible.

First, you can maintain the system, as is -- pure preservation.

The second is to preserve the system, but also to make minor enhancements such as adding a few fields to a database or creating some new reports.

A third approach is to begin extending and modernizing the application. You might replace the green-screen terminal with a new graphical user interface or a Web browser, for example.

The last option is the most sophisticated and provides the highest degree of flexibility -- moving toward a service-oriented architecture (SOA) by extending legacy and other applications as Web services. Adopting an SOA will have profound implications not only on the ease with which your IT organization can create new and modify existing applications, but also on how your company does business with partners and customers well into the future.

By providing a library of services that can be called upon to deliver features and perform tasks, SOAs enable companies to roll out products faster and adapt applications to meet evolving customer and business demands. And because it's based on open standards and widely supported across most vendor environments, as well as across a company's own infrastructure, an SOA won't lock a company into an architecture that could prove difficult to support in the future.

However, Not all legacy systems are good candidates for the same level and sophistication of extension, or even preservation. Twenty-five years ago, a company typically had only one automated system, whereas today it's common to have as many as 100. Each system should be evaluated with respect to its value to the business and its place in the application life-cycle management process. In short, what you need is not a "one size fits all" strategy, but the power to adapt valuable legacy assets to the environment you are in today -- as well as to future.

=The Problems Encountering of Modernize legacy systems=

[g1-8900]
 * Intergration of the legacy system with new applications
 * Migration of legacy system into Web-enabled environments
 * Platform transformation involves migrating monolithic legacy systems into modern platforms.
 * Componentization focuses on the extraction of reusable components from the legacy systems. These components contain the evolving business logic and functionality of the legacy ststem.

Ref: [Managing corporate information systems evolution and maintenance] /Khaled M. Khan, Yan Zhang

[g1-0167] =**Capital Budgeting **= It is a planning for determining how to using firm's capital such as buying a new machine, replacement machinery, new plants etc. There are numbers of formal methods used in capital budgeting, including the techniques such as:

<span style="font-family: 'Times New Roman','serif';"> <span style="font-family: 'Times New Roman',Times,serif;"><span style="font-family: 'Times New Roman','serif';">Now, we are going to discuss these techniques.
 * <span style="font-family: 'Times New Roman',Times,serif;">Accounting rate of return
 * <span style="font-family: 'Times New Roman',Times,serif;">Net present value
 * <span style="font-family: 'Times New Roman',Times,serif;">Profitability index
 * <span style="font-family: 'Times New Roman',Times,serif;">Internal rate of return
 * <span style="font-family: 'Times New Roman',Times,serif;">Modified internal rate of return
 * <span style="font-family: 'Times New Roman','serif';">Equivalent annuity

<span style="font-family: 'Times New Roman','serif';">It is used for providing a fast estimate the project's worth over its useful life. APR is derived by finding profits before taxes and interest
 * <span style="font-family: 'Times New Roman','serif';">Accounting Rate of Return **

<span style="font-family: 'Times New Roman','serif';">The difference between the present value (PV) of cash inflows and the present value of cash outflows. NPV is used in capital budgeting to analyze the profitability of an investment or project
 * <span style="font-family: 'Times New Roman','serif';">Net Present Value **

**<span style="font-family: 'Times New Roman','serif';">Profitability index ** <span style="font-family: 'Times New Roman','serif'; font-size: 12pt;">It is an index which attempts to identify the relationship between the costs and benefits of a proposed project.

<span style="font-family: 'Times New Roman','serif';">The discount rate often used in capital budgeting that makes the net present value of all cash flows from a particular project equal to zero.
 * <span style="font-family: 'Times New Roman','serif';">Internal Rate of Return **

<span style="font-family: 'Times New Roman','serif'; font-size: 12pt;">**Modified internal rate of return**

Information systems can play 3 roles
[g1-3494]

__**Support business process/operations**__ Information System can help employee to conduct their daily work with the use of software, hardware or both. For example, by using the barcode, the product information is saved in database, the product information can be get by using the barcode reader.

Information System can provide information such as which product to deliver in which country by analyzing the collected data. Enterprise can strengthen their advantage and reduce their failing.
 * __Business strategy__**

__**Product or Service**__ Information System get data as input and process them to information. Entreprise can use the information to prvide product or services. For example, 70% of cake customers want to have different taste of cake, entreprise can use this information to make a new product.

**Measuring the value of IS**
It is hard to measure the value of IS, however, there are two type of benefits of it.

1. Tangible benefits The value of IS is tangible which can be quantified. For example, the operation cost and cash flow. A good project management and IS can be lower the operation cost and increasing the cash flow.

2. Intangible benefits The value of IS is intangible which can not be quantified. For example, the staff are more efficient update the information and publish to customer, this is improved the customer service.

Return on investment (ROI) is one of measure method of IS value. This is the ratio of earned money to the invested money. Manager can be easy check the value of IS by ROI ratio.

However, it is difficult to measure in some cases. For example, it is hard to calculate the ROI of e-commerce system and measure the value of DSS or data warehouse.

<span style="font-family: 'Arial','sans-serif';"> =<span style="font-family: 'Arial','sans-serif';">Easy two steps to measure the value of IS =
 * <span style="font-family: 'Arial','sans-serif';">1. Find the roles of system **<span style="font-family: 'Arial','sans-serif';">

First, we should find the roles of system. Then we can measure the value from those roles or functions. For example, the system is used for customer support, so we can measure the performance on it. Also we can measure the business value of customer support purpose. At last, we can measure customer support as a business venture <span style="font-family: 'Arial','sans-serif';"> Identify all important issue to determine corporate performance. Provide a questionnaire to measure some intangible value and study some report to measure tangible one. For example, we can measure the satisfaction of customer support by questionnaire and the feedback
 * <span style="font-family: 'Arial','sans-serif';">2. Using a standard to measure **

g1-2594

Basic Steps of Capital Budgeting
[g1-4939]

Step1 Estimate the cash flows Step2 Assess the riskiness of the cash flows. Step3 Determine the appropriate discount rate. Step4 Find the PV of the expected cash flows. Step5 Accept the project if --PV of inflows > costs --IRR > Hurdle Rate --payback < policy

=Payback Method= The number of years required to recover a project's cost(How long does it take to get our money back?). Calculated by adding project's cash inflows to its cost until the cumulative cash flow for the project turns positive. Payback period = Expected number of years required to recover a project's cost.

Payback L = 2 + $30/$80 years= 2.4 years. Payback S = 1.6 years.
 * __Example 1__**
 * || Project L Expected Net Cash Flow ||
 * Year || Project L ||  || Project S ||
 * 0 || ($100) ||  || ($100) ||
 * 1 || 10 ||  || (90) ||
 * 2 || 60 ||  || (30) ||
 * 3 || 80 ||  || 50 ||
 * __Calculation__**

ABC company needs a new machine. The company is considering two machines which are machine A and machine B. Machine A costs $15,000 and will reduce operating cost by $5,000 per year. Machine B costs only $12,000 but will also reduce operating costs by $5,000 per year. Machine A payback period = $15,000 / $5,000 = 3.0 years Machine B payback period = $12,000 / $5,000 = 2.4 years According to payback calculations, ABC company should purchase machine B, since it has a shorter payback period than machine A.
 * __Example 2__**
 * __Calculation__**

1) Provides an indication of a project's risk and liquidity. 2) Easy to calculate and understand. 1) Ignores the time value of money. 2) Ignores cash flows(CFs) occurring after the payback period.
 * __Strengths of Payback__**
 * __Weaknesses of Payback__**

=Net Present Value(NPV)= The difference between the present value of cash inflows and the present value of cash outflows. NPV is used in capital budgeting to analyze the profitability of an investment or project.

1) NPV > 0 The project will be successful it means that the project is profitable and worth the risk. 2) NPV < 0 The project isn't worth the risk. In other words, you'll pass on it.
 * How NPV helps you decide??**

Suppose we'd like to make 10% profit on a 3 year project that will initially cost us $10,000. In the first year, we expect to make $3000. In the second year, we expect to make $4300. In the third year, we expect to make $5800 The project is going to cost us $10,000. So we won't be making any money until at least a year from now. We need to calculate the present value of each of those 3 cash flows we'll be getting over the next three years. In the example, we would like to make a 10% profit. This is important because it's the bare minimum we'll need to make in order to say yes to this project. In corporate finance, we call this rate our required rate of return (ROR). 1) You'll go over to 10% and down to 1 in the time period column to get your interest factor. It'll be something like 0.9091. Multiply this factor by the $3000 we'll be getting in the first year, and it gives us a present value of $2727.27. 2) We'll be getting $4300 in the second year. This time, you'll go over to 10% and down to 2 in the time period column to get your interest factor. That'll be 0.8264. Multiply this by the $4300 to get a present value of $3,553.72 3) We'll be getting $5800 in the third year. This time, you'll go over to 10% and down to 3 in the time period column to get your interest factor. That'll be 0.7513. Multiply this by the $5800 to get a present value of $4,357.63 Adding $2,727.27 + $3,553.72 + $4,357.63 gives us $10,638.62. Doing this gives us $10,638.62 - $10,000= $638.62. This is our NPV! NPV($638.62) is greater than 0, then the project will be successful.
 * __Example 1__**
 * Step 1**
 * Step 2**
 * Step 3**
 * Step 4**
 * Step 5**

For example, if a retail clothing business wants to purchase an existing store, it would first estimate the future cash flows that store would generate, and then discount those cash flows into one lump-sum present value amount, say $565,000. If the owner of the store was willing to sell his business for less than $565,000, the purchasing company would likely accept the offer as it presents a positive NPV investment. Conversely, if the owner would not sell for less than $565,000, the purchaser would not buy the store, as the investment would present a negative NPV at that time and would, therefore, reduce the overall value of the clothing company.
 * __Example 2__**

1) Consider the entire cash flow of the project. 2) Can choose only one project from all projects 1) It is difficult to determine the 「discount rate」
 * __Strengths of NPV__**
 * __Weaknesses of NPV__**

Return On Investment (ROI)
[g1-9851]

ROI is the ratio of money gained or lost (whether realized or unrealized) on an investment relative to the amount of money invested. Also is used to measures how effectively the firm uses its capital to generate profit; the higher the ROI, the better. This is a very popular metric because of its versatility and simplicity. Thus, it's important for investors ask how a company's ROI compares to those of its competitors and to the industry average.

When someone asks about ROI, they are really asking:

// What do I get back ('return') for the money I'm being asked to spend ('investment')? What is it really worth (the "ROI")? //

ROI Example and Case Study: => []

[g1-0000]


 * Effective for the Project Management**

The project manager or requirements analyst gathers initial requirements from the client. A lot needs to be arranged before the start of a project and also during execution. There are advantages in having processes present to guide the development and execution activities in a structured manner. Everyone knows that, “Knowledge is spread by giving” but we are not inclined to pursue the same. Risk management is a balancing act. It involves the cost calculation for various risks, prioritisation of risks, taking appropriate steps and efforts to minimize the risks. Neither lavish nor meager budgets work. People management is a vital feature to achieve sure success in project management. Good candidates should be motivated through increase in salaries, promotion, recognition, providing more challenges and backing the right cause. The project manager cannot wait for the team member to come to him and pronounce that, he or she is not satisfied. The ideal project manager will value the contribution of employees in many dimensions e.g. a candidate providing training to other team members, establishing superb relations with client, motivating others, taking the lead and bringing results, introducing and practicing the right procedures and ways of working, showing the way to others. A well-defined plan with facts and practical aspect to it is the key to success. This should be undertaken in the same spirit as you handle clients. Missing deadlines is a failure of planning and execution. Effective communication is saying “Yes” to opportunities and “No” if there is no chance of delivery but suggesting an alternative “Win-Win” situation. Successful teams are generally led by bright, dynamic and mature leaders. The author is currently working as a Project Manager in a company known as, Case Consulting Group in Mumbai.
 * Requirement Analysis**
 * Resource Management**
 * Process & Methodologies**
 * Knowledge Management**
 * Risk Management**
 * Budget**
 * People Management**
 * Motivation for the Right Candidates**
 * Tracking People’s satisfaction**
 * Accessing People’s Delivery in Terms of Benefits brought to the Project**
 * Planning**
 * Sub-contract Management**
 * Deadlines**
 * Client Communication**
 * Successful Team**
 * About the Author**

[g1-5726]

What is IRR?

IRR is internal rate of return, it is a rate when let Net Present Value (NPV) is 0. When we want to be an investment, to assess the investment is worthwhile to do; there has two of the simplest way: NPV and IRR

For example:

There is an investment plan; we can buy a machine with $10,000. The machine can produce the product for five years each year can let we have $2,500, and then the machine will be reimbursed, if we without considering the risks, what is the return Investment rate? It is a very simple calculation, investment capital in $10,000 to recover the 2500 * 5 = 12500, so make a (12500-10000) / 10000 = 25%, so, for five years investment, total gaining 25% return of Investment.

However, if we concern time is money, we need to know that the investment capital is $10,000. Five years later, this $10,000 will become more then now. Therefore, in these five years, we will receive $2,500 each year, but the present value of $2,500 in one or two to five later is not equal to now. If we concern time factor, what is the return of Investment?

First, we can draw the table to represent the outcome and income In this table: -10,000 is outcome for first year and 2500 is an income for five years.
 * Year || 0 || 1 || 2 || 3 || 4 || 5 ||
 * Outcome/ Income || -10,000 || 2,500 || 2,500 || 2,500 || 2,500 || 2,500 ||

Second, we assume the discount rate; this rate is used to let us know one year later when we receive $2,500, what is the present value in now. Also it can let us know the present value after two to five year. We can try to use the one-year bank fixed deposit interest rates to calculate. Suppose now one-year bank fixed deposit interest rate is 2%.

That mean for fist year, if we deposit $2,451.0 to the bank and the interest rate is 2%, one year later, we can get $2,500 from the bank. The same situation can apply to 2 two to five year.
 * Year || 0 || 1 || 2 || 3 || 4 || 5 ||
 * Outcome/ Income || -10,000 || 2,500 || 2,500 || 2,500 || 2,500 || 2,500 ||
 * (1+rate)^n || 1 || 1.0200 || 1.0404 || 1.0612 || 1.0824 || 1.1041 ||
 * Present Value || -10,000 || 2451.0 || 2402.9 || 2355.8 || 2309.7 || 2264.3 ||

Sum of present value of five years: -10000+2451.0+2402.9+2355.8+2309.7+2264.3, we can get the Net Present Value 1783.7

Now, if suppose the one-year bank fixed deposit interest rate is 9%.
 * Year || 0 || 1 || 2 || 3 || 4 || 5 ||
 * Outcome/ Income || -10,000 || 2,500 || 2,500 || 2,500 || 2,500 || 2,500 ||
 * (1+rate)^n || 1 || 1.0900 || 1.1881 || 1.2950 || 1.4416 || 1.5386 ||
 * Present Value || -10,000 || 2293.6 || 2104.2 || 1930.5 || 1734.2 || 1624.9 ||

Sum of present value of five years: -10000+2293.6+2104.2+1930.5+1734.2+1624.9, now, we can get the Net Present Value -312.7

So, what is the internal rate of return? It is a discount rate of the value, under this discount rate, the sum of present value include the present and the future investment is 0 (it means Net Present Value is 0).

In this example, we can see that when the discount rate is 2%, the Net Present Value 1783.7 and the discount rate is 9%, the Net Present Value -312.7. Therefore, the IRR must between 2% to 9%. We can try different value (resolution is integer) to find the exact value of IRR, for example 8%, as this rate, we can see that the Net Present Value is very close to 0, it mean 8% is our internal rate of return (IRR) that we want.

__ [g1-4171] <span style="color: #333333; font-family: 'Arial','sans-serif';">Project management is designed to help business teams cost effectively complete a project on time. It features scheduling, tracking, reporting and calendar functions that are always accessible to the entire work team, regardless of the geographic dispersion of team members. Keeping a project on track throughout its life cycle can help save money by eliminating the chance for a missed deadline.
 * The advantage of Project Management**

The success of any company depends on repeat business. And because project management excellence helps ensure that a company can meet the terms of its agreements with clients, the discipline can also help generate satisfied customers who become regulars.

For project management to become an integral component of a business operation, however, a company needs a committed executive at the top. Smaller companies have an edge because their high-level executives “walk the talk” and support the value of project management. __

[g1-9513]


 * PMLC use for IT Project management**

The past 20 year’s business to adapt rapidly to the changing environment by providing more offerings, cheaper and faster than before. This rate of change has forced businesses to transform their operational processes into project-based initiatives. This transformation has not been without its risks, as a large percentage of projects (estimated by the Standish Group as more than 70 per cent) fail to deliver on time, on budget and to the level of  quality expected. It because poor project sponsorship, undefined requirements and miscommunication. lack of adoption of a formal project methodology  poor beginning in project scope and objectives  no structured processes  for undertaking project tasks, and so they fail to effectively manage time, cost,  quality, risks, issues and changes within the project. To cause projects suffer from scope creep, milestone delays, poor deliverable quality and a lack of  customer satisfaction.

• Aset of // skills. // Specialist knowledge, skills and experience are required to reduce the level of risk within a project and thereby enhance its likelihood of success. • Asuite of // tools. // Various types of tools are used by project managers to improve their chances of success. Examples include document templates, registers, planning software, modeling software, audit checklists and review forms. • A series of // processes. // Various processes and techniques are required to monitor and control time, cost, quality and scope on projects. Examples include time management, cost management, quality management, change management, risk management and issue management. Project life cycle planning information must be documented, the objectives and scope have been defined, the project team has been appointed and a formal project office environment established. It is now time to undertake detailed planning to ensure that the activities performed during the execution phase of the project are properly sequenced, resourced, executed and controlled. The activities shown in Figure 1.4 are undertaken. Some planning activities can effective reduce the risk produce in the project Project planning

Risk In projects, a risk can be almost any uncertain event associated with the work. There are many ways to characterize risk. One of the simplest, from the insurance industry, is: “Loss” multiplied by “Likelihood” Risk is the product of these two factors: the expected // consequences // of the event and the // probability // that the event might occur. All risks have these two related, but distinctly different, components. Employing this concept, risk may be characterized in aggregate for a large population of events (“macro-risk”), or it may be considered on an eventby event basis (“micro-risk”). The literature of risk management for these fields (which is extensive) tends to focus on large-scale risk management, with secondary treatment for managing single-event risks.

Precise definition for the project was unclear, even years into the work. Planning was not thorough, and changes in the work were frequent and managed informally. Reporting on the project was sporadic and generally inaccurate (or even dishonest). Risks were not identified effectively or were ignored, and the primary risk management strategy seems to  have been “hoping for the best.” So setting a more appropriate initial objective, or at least modifying it sooner, would have improved the likelihood of success. Honest, more frequent communication—the foundation of well-run projects— would almost certainly have either forced these changes or led to earlier abandonment of the work, saving thousands of lives and a great deal of money.

The Project Risk Management Process One example Development by Method 123 company // Guide to the Project Management Body of Knowledge // (or // PMBOK //// R //// Guide // ). This guide from the Project Management Institute (PMI) is widely used as a comprehensive summary of project management processes and principles, and it is the foundation for PMI certification. The // PMBOK //// R //// Guide // has nine Project Management Knowledge Areas: 1. Project Integration Management 2. Project Scope Management 3. Project Time Management 4. Project Cost Management 5. Project Quality Management 6. Project Human Resource Management 7. Project Communications Management 8. Project Risk Management 9. Project Procurement Management

**Step of Risk analysis in project process**
1. ** Planning for Risk Management ** A. Project Selection – Too many project competing for scarce resources to affects the project risk B. Overall Project Planning Processes – Above the project level, Project management Methodology C. Defining Risk Management for the Project – Stakeholder Risk Tolerance, Planning Data and Templates and Metrics D. Form PERIL Database – provides a step in the management experience, Measuring impact, provide risk causes 2. ** Identifying Project Scope Risk ** A. Sources of Scope Risk – Easy handle the change of Risk, defect integration, hardware and software risks B. Defining Deliverables – Deliverable Definition Process and Straw-man definition Document, Evolutionary Methodologies C. High-Level Risk Assessment Tools i.  Risk framework A. Technology (work) B. Marketing (user) C. Manufacturing (the production and delivery) ii. Risk complexity index A. Index = (Technology + Architecture + System) x Scale iii. Risk assessment grid D. Work Breakdown Structure (WBS) – starts at the scope or objective statement and proceeds to carve the project into small parts, working “top down” from the whole project concept. Decomposition of work that is well understood is straightforward and quickly done. Whenever it is confusing or difficult to decompose project work into smaller, more manageable pieces, there is scope risk. E. Documenting the Risks 3. ** Identifying Project Schedule Risk ** A. Delay Risk – Impact from delays had the lowest average of any other subcategory in the database include parts, information, hardware and decisions. B. Estimating Risks – relate to learning curves, judgment and imposed deadlines. C. Dependency Risks – infrastructure factors and legal issues. Estimating requires many inputs, starting with a comprehensive list of project activities. Another is a resource plan, information about the people and other resources available to the project. You need to know the owners for activities at the lowest level of the project WBS. The activity owner is generally responsible for initial activity duration estimates. Whether the owner is the only contributor, or leads a team, or serves as a liaison to another group where the work will be done, the estimate s ultimately the owner’s responsibility. Accurate estimates require clear, specific information about each activity. Document the constraints on activity durations or project assumptions that might affect the estimates. Activities with more than one deliverable may be easier to manage and have less risk if they are broken down further, creating new, smaller activities for each deliverable. Acceptance criteria and unambiguous, measurable requirements also contribute to accurate estimates. If specifications are unclear, clarify them or note the Project risks. There are three types of project estimates: • Duration estimates, measured in active work time (usually workdays) • Effort estimates, measured using a combination of people and time (person-days or something similar) • Calendar estimates, measured in elapsed time (calendar days)
 * Estimating Process **

Estimating Techniques Highest estimating risk is found in the worst case, lower right quadrant: no experience // and // no data. This case is far from unusual; on  technical projects, it may be true for a number of activities you need to estimate. The most frequently used estimating methods involve guessing, sometimes with arcane rules, and in this situation a guess may be your best option. You can also consider alternatives such as getting someone who does have experience to consult on your project or even replanning the work to use an approach where your team does have experience.

Critical Path Methodology (CPM) analysis combines duration estimates with dependency information and calculates the minimum project duration based on this data. For larger projects, the analysis is best done using a computer scheduling tool. Once all your activities, duration estimates, and dependencies are entered into the database of a scheduling tool, the software automatically analyzes the project network. The set (or sets) of activities that make up the longest sequence is the project // critical // // path //, which is generally highlighted using an appropriately scary red color. Each of the red activities carries schedule risk

4. ** Identifying Project Resource Risk ** A. People Risks i.  // Loss // : Permanent staff member loss to the project due to resignation, promotion, reassignment, health, or other reasons ii. // Temporary loss // : Short-term staff loss due to illness, hot site, support priorities, or other reasons iii. // Queuing // : Slip due to other commitments for needed resources or expertise iv. // Late start // : Staff not available at project start; often because of late finish of previous projects v.  // Motivation // : Loss of team cohesion and interest; typical of long projects B. Outsourcing Risks Nearly three-quarters of the outsourcing risks involved receiving a late or unsatisfactory deliverable from an external supplier, and the average impact for these incidents was nearly eight weeks. These delays result from many of the same root 104 I DEN TI F YI NG AND M ANAG ING P RO J E C T R I SK causes as other people risks—turnover, queuing problems, staff availability, and other issues—but often a precise cause is not known. Receiving anything the project needs late is a risk, but these cases are compounded by the added element of surprise; the problem may be invisible until the day of the default (after weeks of reports saying,  “Things are going just fine . . .”), when it is too late to do much about it.

C. Money Risks The average impact was the highest for any subcategory, at over thirteen weeks. Insufficient funding can significantly stretch out the duration of a project, and it is a contributing root cause in many other subcategories (people turnover due to layoffs and outsourcing  of work primarily for cost reasons, as examples). Cost Estimating and Cost Budgeting Project cost estimates are generally dominated by staffing and outsourcing costs, but also include expenses for equipment, services, travel, communications, and other project needs. 1. ** Staffing and Outsourcing Costs ** 2. ** Equipment and Software Costs ** 3. ** Travel ** 4. ** Other Costs ** 5. ** Cost Budgeting ** 5. ** Managing Project Constraints and ** ** Documenting Risks ** Analyzing Constraints - Your primary goal in managing project constraints is to remove, or at least minimize, the differences between the project objective and your project plan, in terms of scope, schedule, and resources. The standard triangle diagram for examining project trade-offs is one way to show these differences, as in Figure 6-1. The plan, represented by the triangle with the dashed-line edges, is quite a bit larger than the objective, shown as the solid-edged triangle. A slightly more sophisticated analysis rests on prioritizing the triple constraint. Rank-ordering scope, schedule, and resources shows which of the three is most important for your project. A simple three-by three grid is often used for this, as in Figure 6-2. For the example in Figure 6-1, the initial plan failed to meet the deadline and also was over budget. Doing some “what if” analysis, you may discover a way to use a top-notch group of consultants (with a credible track record) to perform more work in parallel, shortening the overall project. This approach will not be inexpensive; it makes the budget problem even bigger, and results in the shift shown in Figure 6-3. In this figure, the schedule has been compressed, bringing it in line with the objective, but the resources required for the project, which already exceeded the objective, are // even farther // out of line with the project expectations. For projects where resources are the lowest priority, this tactic may be a good alternative. For projects with the priorities in Figure 6-2, however, this is not likely to be the best plan. It may be better to reevaluate the specifications and propose a plan that achieves its deadline within budget but falls slightly short on scope. Some projects may find some of the requested requirements are not actually needed. Other projects may propose delivering the most valuable functionality on time, and delivering the rest in a follow-on project somewhat later. The analysis for such a scope reduction might result in a shift similar to Figure 6-4. In this case, changes proposed to the initial plan affect all three of the project parameters, with the most significant difference between the objective and the plan being a small reduction in the feature set for the deliverable. The overall objective of the plan review and “what if” analysis is to discover the options available as alternatives to the initial plan, and to see whether it might be desirable, or even necessary, to revisit the project objective and change the project definition. This triangle model can be thought of as a representation of projects in a two-dimensional state space, and the exploration of plan alternatives will reveal where in this space you can find realistic, feasible projects. For particularly ill-conceived projects,

6. ** Quantifying and Analyzing Activity Risks ** Qualitative impact assessment assigns each risk to one of two or more no overlapping options that include all the possible risk consequences. A two-option version uses categories such as “low severity” and “high severity,” with suitable definitions of these terms related to attaining the project objective. As with probability analysis, the usefulness of only two categories is limited. There will be better discrimination using three ranges, where each risk is assigned a value of high, medium, or low. The definitions for these categories vary, but commonly they relate to the project objective and plan as follows: • High: Project objective is at risk (mandatory change to one or more of scope, schedule, or resources). • Medium: Project objectives can be met, but significant replanning is required. • Low: No major plan changes; the risk is an inconvenience or it will be handled through overtime or other minor adjustments. These three levels of project impact are not difficult to assess for most risks and provide useful data for sequencing risks according to severity. Form a Risk Assessment Table to categorization of both probability and impact provides greater insight into the // absolute // risk severity. A risk assessment table or spreadsheet where risks are listed with category assignments for both probability and impact After listing each risk, assign a qualitative rating (such as High/Moderate/Low) for both probability and impact. Consider all potential impact, not just that which is easily measured, and be skeptical about probabilities. Fill in the last column, “Overall Risk,” based on “loss times likelihood.” Although any number of rating categories may be used, the quickest method that results in a meaningful sort uses three categories (defined as in the earlier discussions of probability and impact) and assigns either combinations of the categories or weights such as 1, 3, and 9 for low, moderate, and high, respectively. After then work on Risk Assessment Matrices The farther up and to the right a risk is assessed to be, the higher its overall assessment. Risks are selected for management based on whether the cell in the matrix represents a risk above some predetermined level of severity. An organization’s risk tolerance (or appetite) is generally bounded by one of the sets of lighter gray cells in the matrix. It may also be used to assess // uncertain // project opportunities. Some of the opportunities discussed

in Chapter 6 relate to scoping choices and planning decisions, where the only uncertainty is whether an opportunity is adopted as part of the project or not. Other opportunities, like most risks, hinge on circumstances that might or might not happen. For these opportunities assessment is based on likelihood and (instead of loss) gain. An example of this type of opportunity might be buying something needed by the project that occasionally goes on sale. Once the opportunity to purchase the item at a reduced price is recognized, managing this “risk” might involve delaying the purchase to potentially take advantage of a better price. For most projects, there are far fewer opportunities of this sort than there are risks. For analysis of uncertain opportunities, the definition of probability is unchanged. The impact is also similar, but for opportunities the categories relate to beneficial variances, not harmful ones. Using the same matrix, you can assess potentially positive events to determine those that deserve further attention—again by focusing near the corner representing the combination of highest impact and probability. Another variant on this matrix technique joins together the threat matrix and a mirror-image opportunity matrix into a single matrix (for this case, five cells high and ten cells wide). You find the highest impact in the middle using the combined matrix, so the uncertain events most deserving your attention will be those in the cells near the top and center of the matrix.

7. ** Managing Activity Risks ** A. Categories of Risk – More popular use of Fishbone diagram to Prevention and Recovery impact to the risk activity. The process for cause-and-effect analysis is not a difficult one. For risk analysis, it begins with the listed risks and their descriptions. The next step is to brainstorm possible sources for the risk. Any brainstorming process will be effective as long as it is successful in determining conditions or events that may lead to the risk. You can begin with major cause categories (such as scope, schedule, and resource) or simply think about specific factors that may lead to the risk. However you begin the analysis, complete it by organizing the information into categories of root cause. Some redundancy between items listed in the categories is common. Dealing with the causes of project threats involves risk prevention— eliminating the risk ( // avoidance // ), lowering its probability or potential impact ( // mitigation // ), or making it someone else’s problem ( // transfer // ). Avoidance of risks requires changing the project plan or approach to remove the root cause of the risk from your project. One way to avoid falling off a cliff is to avoid cliffs. Mitigating actions do not remove a risk completely, but they do serve to reduce it. Some mitigating actions reduce the probability of a risk event, such as inspecting your automobile tires before a long trip. Other mitigations reduce the risk consequences, such as wearing a seat belt to minimize injury. Neither of these actions prevents the problem, but they do serve to reduce the overall risk by lowering the “loss” or the “likelihood.” B. Risk Transfer - Transfer is a third option for risk prevention, along with avoidance and mitigation. It is most effective for risks where the impact is primarily financial. The best-known form of transfer is insurance; for a fee, someone else will bear the financial consequences of your risk. Transfer works to benefit both parties, because the purchaser of the insurance avoids the risk of a potentially catastrophic monetary loss in exchange for paying a small (by comparison) premium, and the seller of the insurance benefits by aggregating the fees collected to manage the risk for a large population of insurance buyers, who may be expected to have a stable and predictable “average” risk, and include only a small percentage who will generate claims. In technical projects, this sort of transfer is not extremely common, but it is used. Unlike other strategies for mitigation, transfer does not actually do anything to lower the probability or dimin- 196 I DEN TI F YI NG AND M ANAG ING P RO J E C T R I SK  ish the nonfinancial impact of the risk. With transfer, the risk is accepted, and it either happens or it does not. However, any budgetary impact will be borne outside the project, limiting the resource impact. Transfer of scope and technical risk is often the justification for outsourcing, and in some cases this might work. If the project team lacks a needed skill, hiring an expert or consultant to do the work transfers the activities to people who may be in a better position to get it done. Unfortunately, though, the risk does not actually transfer to the third party; the project still belongs to you, so any risk of nonperformance is ultimately still yours. Should things not go well, the fact that a bill for services will not need to be paid will be of small consolation. Even the possibility of eventual legal action is unlikely to help the project. Using outsourcing as a risk transfer strategy is very much a judgment call. In some cases the risks accepted may significantly exceed the risks managed, no matter how well you write the contract. 8. ** Quantifying and Analyzing Project Risk ** A. Leveling the Project Risk – base on following factor i.   Unrealistic deadlines: High-tech projects often have inappropriately aggressive schedules ii. No or few metrics: Measures used for estimates and risk assessment are inaccurate guesswork iii. “Accidental” project leaders: Projects are led by team members skilled in technical work but with no project management training. iv. Inadequate requirements and scope creep: Poor initial definition and insufficient specification change control are far too common. v.   Project size: Project risk increases with scale; the larger the project, the more likely it is to fail. 9. ** Managing Project Risk ** A. ** Project Documentation Requirements – ** T e chnical projects come in all sizes, shapes, durations, and complexities, the requirements for project documentation—the written descriptions for project deliverables, plans, and other relevant information—vary a great deal. Project Documentation Requirements • Project Start-Up • Selecting and Implementing Project Metrics • Management Reserve • Project Baseline B. Negotiation • Project Plan Validation • Specification Change Management 10. ** Monitoring and Controlling Risky Projects ** Applying the Plan • Project Monitoring • Collecting Project Status • Metrics and Trend Analysis • Responding to Issues • Communication • Project Archive • Project Reviews and Risk Reassessment • Taking Over a  Troubled Project Project Metrics Before deciding what to measure, carefully define the behavior you want and determine what measurements will be most likely to encourage that behavior. Next, establish a baseline by collecting enough data to determine current performance for what you plan to measure. Going forward, you can use metrics to detect changes, trigger process improvements, evaluate process modifications, and make performance and progress visible. The process begins with defining the results or behavior you desire. For metrics in support of better project risk management, a typical goal might be “Reduce unanticipated project effort” or “Improve the accuracy of project estimates.” Consider what you might be able to measure that relates to the desired outcome. For unanticipated project effort, you might measure “Total effort actually consumed by the project versus effort planned.” For estimation accuracy, a possible metric might be “Cumulative difference between project estimates and project results, as measured at  the project conclusion.” Metrics are of three basic types: // predictive //, // diagnostic // , and // retrospective //. An effective system of metrics will generally include measures of more than one type, providing for good balance. // Predictive metrics // use current information to provide insight into future conditions. Because predictive metrics are based on speculative rather than empirical data, they are typically the least reliable of the three types. Predictive metrics include the initial assessment of project “return on investment,” the output from the quantitative risk management tools, and most other measurements based on planning data. // Diagnostic metrics // are designed to provide current information about a system. Based on the latest data, they assess the state of a running process and may detect anomalies or forecast future problems. The unanticipated effort metric suggested before is based on earned value, a project metric discussed below. // Retrospective metrics // report after the fact on how the process worked. Backward-looking metrics report on the overall health of the process and are useful in tracking trends. Retrospective metrics can be used to calibrate and improve the accuracy of corresponding predictive metrics for subsequent projects. A number of diagnostic project metrics relate to the concept of earned value management (EVM). These metrics are listed with resource metrics below and described following this list of typical diagnostic project metrics: l ** Scope Risk ** n  Results of tests, inspections, reviews, and walkthroughs n  Number and magnitude of approved scope changes l ** Schedule Risk ** n Key milestones missed n Critical path activity slippage n Cumulative project slippage n Number of added activities n Early activity completions n Activity closure index: the ratio of activities closed in the project so far to the number expected l ** Resource Risk ** n Excess consumption of effort or funds n Amount of unplanned overtime n Earned value (EV): a running accumulation of the costs that were planned for every project activity that is currently complete n Actual cost (AC): a running accumulation of the actual costs for every project activity that is currently complete n Planned value (PV): a running accumulation of the planned costs for every project activity that was expected to be complete up to the current time n Cost performance index (CPI): the ratio of earned value to actual cost n Schedule performance index (SPI): the ratio of earned value to planned value n Cost variance (CV): the difference between earned value and actual cost, a measurement of how much the project is over or under budget n Schedule variance (SV): the difference between earned value and planned value l ** Overall Risk ** n Risks added after project baseline setting n Issues opened and closed n Communication metrics, such as volumes of e-mail and voicemail n The number of unanticipated project meetings n Impact on other projects n Risk closure index (ratio of risks closed in a project divided by an expected number based on history) Exceptions include the EVM metrics—EV, AC, PV, CV, SV, CPI, SPI, and the rest of the EVM alphabet soup. The definitions make them seem complex, but they really are not that complicated. EVM is about determining whether the project is progressing as planned, and it begins with allocating a portion of the project budget to each planned project activity. The sum of all these allocated bits of funding must exactly equal 100 percent of the project staffing budget. As the project executes, EVM collects data on actual costs and actual timing for all completed activities so that the various metrics, ratios, and differences may be calculated. The definitions for these diagnostic metrics are all stated in financial terms here, but mathematics of EVM are identical for equivalent metrics that are based on effort data, and a parallel set of metrics defined this may be substituted. The terminology for EVM has changed periodically, but the basic concepts have not. The basic principle of EVM is that every project has two budgets and two schedules. It starts with one of each, making up the baseline plan. As the project executes, another schedule and another budget emerge from actual project progress data. The combination of planned funding and timing may be graphed as a curve starting at zero and meandering up and to the right until it reaches the data point that represents the scheduled end of the project and the cumulative funding for the project. (The metric for the cumulative budget is Budget at Completion, marked as BAC in Figure 9-8.) The expected funding consumption curve describes the PV metric, also called the budgeted cost of work scheduled (BCWS). The combination of actual spending and actual activity completion may be plotted on the same graph as the AC metric, also called the actual cost of work performed (ACWP). These two metrics may be calculated at any point in the project, and if the project is exactly on schedule they may be expected to match. If they do not, something is off track. Because PV and AC are based on different schedules and budgets, you cannot really tell whether there is a timing problem, a spending problem, or some combination. To unravel this, we can use EV, also known as the budgeted cost of work performed (BCWP). As project work is completed, EV accumulates the cost estimates associated with the work, and it may also be plotted on the graph in Figure 9-8. These three basic EVM metrics are presented in the following table. **Financial Metrics (Capital Budgeting)**
 * Establishing Metrics **
 * Measuring Projects **

Project risk extends beyond the normal limits of project management, and project teams must consider and do what they can to manage risks that are not strictly “project management.” There are a number of methods and principles used to develop predictive metrics that relate to the broad concept of ROI, and an understanding of these is essential to many types of technical projects. As discussed in Chapter 3 with market risks, ROI analysis falls only partially within project management’s traditional boundaries. Each of the several ways to measure ROI comes with benefits, drawbacks, and challenges.

** The time value of money ** The foundation of most ROI metrics is the concept of the time value of money. This is the idea that a quantity of money today is worth more than the same quantity of money at some time in the future. How much more depends on a rate of interest (or discount rate) and the amount of time. The formula for this is: PV = FV/(1 + i) n, where PV is present value FV is future value i is the periodic interest rate n is the number of periods

n ** Payback analysis **

Even armed with the time value of money formula, it is rarely easy to determine the worth of any complex investment with precision, and this is especially true for investments in projects. Project analysis involves many (perhaps hundreds) of parameters and values, multiple periods, and possibly several interest rates. Estimating all of this data, particularly the value of the project deliverable after the completion of the project, can be very difficult. Once an appropriate interest rate is selected, each of the expense and revenue estimates can be discounted back to an equivalent present value before it is summed. The discounted payback or break-even point again occurs when the sum, in this case the cumulative present value, reaches zero. For a nonzero interest rate, the amount of time required for payback will be significantly longer than with the simple analysis, since the farther in the future the revenues are generated, the less they contribute because of the time value of money. Discounted payback analysis is still relatively easy to evaluate, and it is more suitable for comparing projects that have different durations. Payback analysis, with and without consideration of the time value of money, is often criticized for being too short-term. These metrics determine only the time required to recover the initial investment. They do not consider any benefits that might occur following the break-even point, so a project that breaks even quickly and then generates no further benefits would rank higher than a project that takes longer to return the investment but represents a much longer, larger stream of subsequent revenues or benefits.

n ** Net present value ** Total net present value (NPV) is another method to measure project ROI. NPV follows the same process as the discounted payback analysis, but it does not stop at the break-even point. NPV includes all the costs and all the anticipated benefits throughout the expected life of the project deliverable. Once all the project costs and returns have been estimated and discounted to the present, the sum represents the total present value for the project. This total NPV can be used to compare possible projects, even projects with very different financial profiles and time scales, based on all expected project benefits. Total NPV effectively determines the overall expected return for a project, but it tends to favor large projects over smaller ones, without regard to other factors. A related idea for comparing projects normalizes their financial magnitudes by calculating a profitability index (PI). The PI is a ratio, the sum of all the discounted revenues divided by the sum of all the discounted costs. PI is always greater than one for projects that have a positive NPV, and the higher the PI is above one, the more profitable the project is expected to be. Even though these metrics require additional data—estimates of the revenues or benefits throughout the useful life of the deliverable— they are still relatively easy to evaluate. n ** Internal rate of return ** Another way to contrast projects of different sizes is to calculate an internal rate of return (IRR). IRR uses the same estimates for costs and returns required to calculate total net present value, but instead of assuming an interest rate and calculating the present value for the project, IRR sets the present value equal to zero and then solves for the required interest rate. Mathematically, IRR is the most complex ROI metric, as it must be determined using iteration and “trial and error.” For sufficiently complicated cash flows, there may even be several values possible for IRR (this occurs only if there are several reversals of sign in the cash flows, so it rarely happens in project analysis). These days, using a computer (or even a financial calculator) makes determining IRR fairly straightforward, if good estimates for costs and revenues are available. For each project, the interest rate you calculate shows how effective the project is expected to be as an investment. n ** ROI estimates ** All of these ROI methods are attempts to determine the “goodness” of financial investments, in this case, projects. Theoretically, any of these methods is an effective way to select a few promising projects out of many possibilities, or to compare projects with other investment opportunities. Because of their differing assumptions, these methods may generate inconsistent ranking results for a list of potential projects, but this is rarely the biggest issue with ROI metrics. In most cases the more fundamental problem is with input data. Each of these methods generates a precise numeric result for a given project, based on the input data. For many projects, this information comes from two sources that are historically not very reliable: project planning data and sales forecasts. Project planning data can be made more accurate over time using metrics and adjustments for risk, at least in theory. Unfortunately, project ROI calculations are generally made before much planning is done, when the project cost data is still based on vague information or guesswork, or the estimates come from top-down budget goals that are not correlated with planning at all. Estimates of financial return are an even larger problem. These estimates are not only usually very uncertain (based on sales projections or other speculative forecasts), they are also much larger numbers, so they are more significant in the calculations. For product development projects, in many cases revenue estimates are higher than costs by an order of magnitude or more, so even small estimating errors can result in large ROI variances. ROI metrics can be very accurate and useful when calculated retrospectively using historical data, long after projects have completed. The predictive value of ROI measures calculated in advance of projects can never be any more trustworthy than the input data, so a great deal of variation can occur. Ref:

1, Identifying and Managing Project Risk, Essential Tools for Failure-Proofing Your Project, Tom Kendrick, PMP, AMACOM 2, The project management life cycle, Jason Westland

added by g1-4909, reference from : [] =Project planning, monitoring and control=

The purpose of project planning is to identify the scope of the project, [|estimate] the work involved, and create a [|project schedule]. Project planning begins with [|requirements] that define the software to be developed. The project plan is then developed to describe the tasks that will lead to completion. The purpose of project monitoring and control is to keep the team and management up to date on the project's progress. If the project deviates from the plan, then the project manager can take action to correct the problem. Project monitoring and control involves status meetings to gather status from the team. When changes need to be made, [|change control] is used to keep the products up to date. = Issue =

In computing, the term **issue** is a unit of work to accomplish an improvement in a system. An issue could be a bug, a requested feature, task, missing [|documentation], and so forth. The word "issue" is popularly misused in lieu of "[|problem]." This usage is probably related. For example, [|OpenOffice.org] used to call their modified version of [|BugZilla] IssueZilla. As of August 2006, they call their system Issue Tracker. Issues occur from time to time and fixing them in a timely fashion is essential to achieve correctness of a system and avoid delayed deliveries of products.

Severity levels
Issues are often categorized in terms of **severity levels**. Different companies have different definitions of severities, but some of the most common ones are:
 * Critical
 * High - The bug or issue affects a crucial part of a system, and must be fixed in order for it to resume normal operation.
 * Medium - The bug or issue affects a minor part of a system, but has some impact on its operation. This severity level is assigned when a non-central requirement of a system is affected.
 * Low - The bug or issue affects a minor part of a system, and has very little impact on its operation. This severity level is assigned when a non-central requirement of a system (and with lower importance) is affected.
 * Cosmetic - The system works correctly, but the appearance does not match the expected one. For example: wrong colours, too much or too little spacing between contents, incorrect font sizes, typos, etc. This is the lowest priority issue.

In many software companies, issues are often investigated by [|Quality Assurance Analysts] when they verify a system for correctness, and then assigned to the developer(s) that are responsible for producing them. They can also be assigned by system users during the [|User Acceptance Testing (UAT)] phrase. Issues are commonly communicated using [|Issue] or Defect Tracking Systems. In some other cases, emails or instant messengers are used.

**IT project management**

Information technology is always changing, adapting and challenging business as we know it, so managing an IT project is a very complicate task nowadays. IT project management is complicated by shifting business needs and demanding stakeholders, and good IT project management is difficult to execute. Therefore, the IT project success rates are relatively low. Typically there are several individuals with different skill sets to be included in an IT project, but basically there will be a project sponsor to sponsor the project that will act as a champion for the project and provide organizational resources and direction when needed, they may be the client, customer, or organizational manager. Also there will be a Project Manager, who is responsible for ensuring that all of the project management and technical development processes are in place and are being carried out within a set of specific requirements, defined processes, and quality standards.

All IT projects move through five phases in the project management lifecycle: initiating, planning, executing, monitoring and controlling, and closing. Each phase contains processes that move the project from idea to implementation. Also, all projects have an element of risk, and some projects entail more risk than others. Risk can arise from many sources, both internal and external to the project team.

Also, all projects are constrained by three factors: time, cost and scope. For a successful project, these three constraints (please see below) must be in equilibrium. If any constraint is out of balance, the project will often. **ref:** []

= Improving the Management of Project Risk = [g1-5101] Even the perfect project must carry potential risk through uncertainty. Project manager should evaluate the possible uncertainties, spot the impact in the project lifecycle and to embed the risk management into the mainstream of project lifecycle.

The reality of Projects and risk
The Project manager should review project risk management regularly and proactively throughout the project lifecycle. Ideally, project manager should assign a dedicated professional into the role. Many people always have the misconception; think that risk management should be carried out in the interim of the project lifecycle or even the final stage. In fact, risk management should be carried out in the planning stage, for example, increase of project cost or delay of project schedule would bring consequent issues to the project. Particularly in corporate perspective as the project scale is large, the projects should be demonstrated with a disciplined approach in risk management at the start of the projects.

Improving Risk Identification and Capture
Few project teams have comprehensive risk management plans, or a clear account of the risks that face their projects. This is partly cultural, partly ‘mechanical'. Both can be addressed. Improving the management of risk involves improving a project's ability to identify risks early, via productive methods linked to the project's strategic decision-making lifecycle, along with effective methods of presenting and using this data. Many risk databases hold poor quality, partially complete or limited data. Often this results in a limited understanding of project risk and little attention or resource being dedicated to the management of risk. It also makes risk data of lesser use to others (e.g. stakeholders), and can foster a false sense of security relating to the delivery of a project. It is imperative and to employ innovative and effective methods to:
 * significantly improve the identification of risk and the capture and presentation of risk data
 * integrate risk management into the definition of the project, and
 * improve the quality of risk management information substantially and its communication to others

Improving the Assessment and Understanding of Risk
In all the literature on risk, much has been written on modelling its impact (e.g. statistical analysis). This has its place and value when major project decisions are being taken, however, many organsaitions believe that far greater benefit is achieved by ensuring that mitigation activities are carried out with discipline in a timely manner (relative to the schedule) on projects. As a minimum, all risks should be assessed to decide:
 * the probability of its occurrence (against a relatively simple scale expressing the likelihood of occurrence, e.g. low / medium or high)
 * the impact of the risk should it occur (again either in simple overall terms, or perhaps impact on schedule, budget or quality)

When presenting risk data to stakeholders and decision makers it is often very productive to include the impact of the risk, especially when engaged in decision making around committing to mitigation strategies or fall-back plans.

Improving the Management of Individual Risks
The strategies and actions to manage risks that pose a real threat to a project must be built into the baseline project plan, from the outset. Risk mitigation must never be treated outside the mainstream project management processes, yet in many projects today, this is exactly how it occurs. Teams need to understand the difference between mitigation and contingency planning, and when each needs to be applied:
 * Mitigation strategies are proactive actions that reduce either: a) the probability of a risk occurring or b) the impact of the risk if it still does.
 * Fall back (also called contingency) plans are the alternative plans that will be executed if the occurrence of a risk gives rise to the need.

Moreover, teams also need to know how to integrate risk management data with the mainstream technical, management and performance measurement processes (e.g. Earned Value Management).

Once a project starts to approach the task in this way, risk management can turn into a controlled, productive process that systematically reduces project risk, thereby enabling projects minimise its impact on the project.

Managing the Overall Process
As with any process, project risk management must itself be controlled. There should be periodic reviews and events scheduled into the mainstream project plan to address risk. These reviews must be managed with enormous discipline, as they are not brainstorming or analysis sessions - they should review the status of risk mitigation strategies, and assign actions as appropriate. In addition, there are simple but very powerful metrics that can be employed, at the project and business levels, to monitor the application of the risk management process and the status of health of projects.

Improving Opportunity Management
While projects need to manage risks, they will similarly have opportunities, which in many way are the exact opposite of risk. Many organisations now use the same core process for managing both together, where opportunities have a positive impact on the project. There can be some merits to this, perhaps the most important of which is to raise the focus on opportunity management and to offer a realistic balance to the overall picture during significant project decisions.

[g1-2895] =Internal Rate of Return= The **internal rate of return** (**IRR**) is the return rate that used to count the profit rate of the investments.

Definition
the internal rate of return on an investment or potential investment is the //annualized effective compounded return rate// that can be earned on the invested capital. In more familiar terms, the IRR of an investment is the interest at which the costs of the investment lead to the benefits of the investment. This means that all gains from the investment are inherent to the time value of the money and that the investment has a zero net present value at this interest rate.