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


[20091103] Please don't direct copy from the web and try to use your own words to describe!!! | Table of Content | 10 musts for Earned value of project management | Nine Knowledge for Project Management | Project Management | Five Phases of Project Management | Projects and Programs | | The benefits of risk management | Risk Assessment | Project Risk Management Plan | Legacy Systems | Legacy system replacement | Legacy system change | The legacy dilemma | Legacy system structures | Legacy system design | Legacy system assessment | Options for Improving Legacy Systems | Options for Improving Legacy Systems [ con't ] | Options for improving a legacy system (cont.) 2 | Simplified options for improving a legacy system | The Problems Encountering of Modernize legacy systems | Capital Budgeting | Easy two steps to measure the value of IS<span style="mso-spacerun: yes;"> | Payback Method | Net Present Value(NPV) | Project planning, monitoring and control | Issue | Improving the Management of Project Risk | Internal Rate of Return


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.

Project Management


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.


Project Management consist of three core components:
  • 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.
Reference: The Project Management Life Cycle, A complete step-by-step

Nine Knowledge for Project 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




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


Project Management

  • IT and business unit managers
  • enforce a project plan which includes
    • job responsibilities
    • time lines for major stages of development
    • financial budgets

Five Phases of Project Management

  • 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


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.


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

Project Manager's Role and Responsibilities


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.

Process Responsibilities
Once the project starts, the project manager must successfully manage and control the work, including:

  • 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.


IT-enabled Business Change: An Approach to Understanding and Managing Risk


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.

[[http://web.njit.edu/~egan/CIS455/McNurlin_10.ppt#412,13,Project Management The Job of a Project Manager]]


Mainly 3 Project Elements:


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.


  • 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


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.

Risk Management - Business Risk


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
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.

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%).


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.


Advantage of using Risk Management


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:


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

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.



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

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:
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


Project risk management addresses the following questions:
  • 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?
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.
[Leading IT projects : the IT manager's guide] / Keyes, Jessica

Risk Exposure


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.


「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

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

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
3) Several methods and CASE tools are available to support function oriented
design and the approach is still used for many business

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


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


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
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.

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.


[ g1-5006 ]

Options for Improving Legacy Systems [ con't ]

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.
Following are reasons for reverse engineering a part or product:
  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

Refurbish the system:
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.

Rejuvenate 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.
Rearchitect the System:
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.
Replace with a Package or Service:
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.
Rewrite the System:
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.


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

  • 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.

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


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:

  • Accounting rate of return
  • Net present value
  • Profitability index
  • Internal rate of return
  • Modified internal rate of return
  • Equivalent annuity

Now, we are going to discuss these techniques.

Accounting Rate of Return
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

Net Present Value
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

Profitability index
It is an index which attempts to identify the relationship between the costs and benefits of a proposed project.

Internal Rate of Return
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.

Modified internal rate of return

Information systems can play 3 roles


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.

Business strategy
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.

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.

Easy two steps to measure the value of IS

1. Find the roles of system

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

2. Using a standard to measure

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


Basic Steps of Capital Budgeting


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.

Example 1

Project L Expected Net Cash Flow
Project L

Project S




Payback L = 2 + $30/$80 years= 2.4 years.
Payback S = 1.6 years.

Example 2
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.

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

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.

How NPV helps you decide??
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.

Example 1
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
Step 1
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.
Step 2
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).
Step 3
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
Step 4
Adding $2,727.27 + $3,553.72 + $4,357.63 gives us $10,638.62.
Step 5
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 2
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.

Strengths of NPV
1) Consider the entire cash flow of the project.
2) Can choose only one project from all projects
Weaknesses of NPV
1) It is difficult to determine the 「discount rate」

Return On Investment (ROI)


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")?

external image roi_investreturn.gif

ROI Example and Case Study:
=> http://www.growmyrestaurant.com/pdf/caseStudies.pdf


Effective for the Project Management

Requirement Analysis
The project manager or requirements analyst gathers initial requirements from the client.
Resource Management
A lot needs to be arranged before the start of a project and also during execution.
Process & Methodologies
There are advantages in having processes present to guide the development and execution activities in a structured manner.
Knowledge Management
Everyone knows that, “Knowledge is spread by giving” but we are not inclined to pursue the same.
Risk Management
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
People management is a vital feature to achieve sure success in project management.
Motivation for the Right Candidates
Good candidates should be motivated through increase in salaries, promotion, recognition, providing more challenges and backing the right cause.
Tracking People’s satisfaction
The project manager cannot wait for the team member to come to him and pronounce that, he or she is not satisfied.
Accessing People’s Delivery in Terms of Benefits brought to the Project
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.
Sub-contract Management
This should be undertaken in the same spirit as you handle clients.
Missing deadlines is a failure of planning and execution.
Client Communication
Effective communication is saying “Yes” to opportunities and “No” if there is no chance of delivery but suggesting an alternative “Win-Win” situation.
Successful Team
Successful teams are generally led by bright, dynamic and mature leaders.
About the Author
The author is currently working as a Project Manager in a company known as, Case Consulting Group in Mumbai.


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

Outcome/ Income

In this table: -10,000 is outcome for first year and 2500 is an income for five years.

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%.

Outcome/ Income
Present Value

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.

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%.

Outcome/ Income
Present Value

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.

The advantage of Project Management

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 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.


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

Some planning activities can effective reduce the risk produce in the project
Project planning

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

The Project Risk Management Process
One example Development by Method 123 company

Guide to the Project Management Body of Knowledge (or PMBOKR 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 PMBOKR 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
Sources of Scope Risk – Easy handle the change of Risk, defect integration, hardware and software risks
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
Delay Risk – Impact from delays had the lowest average of any other subcategory in the database include parts, information, hardware and decisions.
Estimating Risks – relate to learning curves, judgment and imposed deadlines.
Dependency Risks – infrastructure factors and legal issues.
Estimating Process
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 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
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

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
Equipment and Software Costs
Other Costs
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

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

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

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.
Quantifying and Analyzing Project Risk
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.
Managing Project Risk
Project Documentation Requirements – Technical 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
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

Establishing 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.

Measuring 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)

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.

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.

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.


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 : http://en.wikipedia.org/wiki/Software_project_management

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.


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.
edw.JPGref: http://www.pm-kbase.com/books/0471392030.pdf

Improving the Management of Project Risk

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.
external image risk-management-process.gif

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.
external image risk-assessment.gif

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.


Internal Rate of Return

The internal rate of return (IRR) is the return rate that used to count the profit rate of the investments.


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.