# Initiation, Planning, and Risk management

###### tags: `SPM`

[SPM5] - 2 (focus on the concepts, not the formulas), 3, 6, 7 (very important until exercise 7.4)
Nerur, Sridhar, RadhaKanta Mahapatra, and George Mangalaraj. "Challenges of migrating to agile methodologies." Communications of the ACM 48, no. 5 (2005): 72-78.

## SPM chapter 2: Project evaluation and programme management

Software project needed a business case.
- may be presented for several potential projects.
- managers decide which projects to select. (part of portfolio management)

### A business case
organisations may have different titles s.a feasibility study or a project justification for what we call a buisnees case.

Businees Case document:
1. Introduction and background to the proposal
3. The proposed project
4. The market
5. Organizational and operational infrastructure
6. The benefits
7. Outline implementation plan
8. Costs
9. The financial case
10. Risks
11. Management plan

### Project portfolio management
provides an overview of all the projects that an organization is undertaking or is considering.

The concerns of project portfolio management incude:
- identifying which project are worth implementation
- assessing the amount of risk of failure that a potential project has
- decisiding how to share limited resureces, including staff time and finance, between projects.
- being aware of the depedencies between projects.
- ensuring that project do not duplicate work
- ensuring that necessary developments has not been inadvertently been missed.

Key terms:
1. Project portfolio definition

An organization should record every single repo details of all current projects.
Decisions will be needed about whether projects of all types are to be included.

2. Project portfolio management
Once a portfolio has been established, more detailed costing of project can be recorded.
The value that managers hope will be generated by each project can also be recorded.

Performance of projects can be tracked.

3. project portfolio optimization
Performance can be tracked by high-level managers on a regular basis.

Some projects could potentially be very profitable but cloud also be risky.

### Evaluation of individual projects

1. **Technical assesssment**

evaluating whether the required functionality can be achieved with current affoable technologies.

2. **cost-benefit analysis**

Any project aiming at a return on investment must, as a minimum, provide a greater benefit than putting that investment in, say a bank.

2 steps:
1: Identifyring all of the costs and benefits of carrying out the project and operating the delievered application.
2: Expressing these costs and benefits in common units.

3. **cash flow forecasting**

important as estimating the overall costs and benefits of a project is producing a cash flow forecast which indicates when expenditure and income will take place.

Typically products generate a negative cash flow during their development followed by a positive cash flow over their operating life.

When estimating future cash flow, it is usual to ignore the effects of inflation.
Forecats of inflation rates tend to be uncertain.

### Risk evaluation

Every project envolves risks.

Business risk: the delievered products are not profitable.
focus on business risk.

**Risk identification and ranking**
identify the risks and quantify their effects.
Construct a project risk matrix utilizing a checklist of possible risks and classifying risks according to their relative importance and likelihood.

The project risk matrix may be used as a way of evaluating projects or as means of identifying and ranking the risks for a specific project.

### Programme management

I will read the rest of the chapter later on..
A lot about a business

Missing 10 pages.

### Key pointers from chapter

- projects must be evaluated on strategic, technical and economic grounds
- many projects are not justifiable on their own, but are as a part of a broader programmme of projects that implement an organization's strategy.
- Not all benefits can be precisely quantified in financial values.
- economic assessment involves the identification of all costs and income over the lifetime of the system, including its development and operation and checking that the total value of benefits exceeds total expenditure.
- Money recived in the future is worth less than the same amount of money in hand now, which may be invested to earn interest.
- the uncertainty surrounding estimates of future returns lowers their real value measured now.
- Discounted cash flows techniques may be used to evaluate the present value of future cash flows taking account of interest rates and uncertainty.
- cost-benefits analysis techniques and decisions trees provide tools for evaluating expected outcomes and choosing between alternatives strategies.

## SPM chapter 3: An overview of project planning

### 3.1 Intro to Step Wise project planning
describes a framework of basic steps in project planning.
different techniques can be used in project planning.
Overview of the points at which thse thchniques can be applied during project planning.

The framework == Step Wise method

An overview of Step Wise.

### 3.2 Step 0: select project
Read chapter 2 of the books for more information.
There need to be a business case for the project.

### 3.3 Step 1: Identify project scope and objectives
this step ensures that all parties to the project agree on the objectives and all committed to the success of the project.

**Step 1.1: Identify objectives and practical measures of the effectiveness in meeting those objectives**

**Step 1.2: Establish a project authority**
a single overall project authority needs to be established.

**Step 1.3: Stakeholder analysis - identify all stakeholders in the project and their interests**
All parties who have an interest in the project need to be identified.

**Step 1.4: Modify objectives in the light of stakeholder analysis**

In order to gain the full cooperation of all concerned, it might be necessary to modify the project objectives.

Be carefull here -- increase in system size and the orginal obsured.

**Step 1.5: Establish methods of communication with all parties**

### 3.4 Step 2: Identify project infrastructure
projects are never carried out in vaccum.

**Step 2.1: Identify relationships between the project and strategic planning**

these technical strategic decisions should be documented as part of an enterprise architechture process.

**Step 2.2: Identify installation standards and procedures**
define development procedures.

**Step 2.3: Identify project team organization**

### 3.5 Step 3: Analyse project characteristics
the general purpose of this part of the planning operation is to ensure that the appropriate methods are used for the project.

**step 3.1: distinguish the project as either objective or product driven**
As development of a system advances it tends to become more product-driven.
although underlying objectives always remain and must be respected.

**step 3.2: Analyse other project characteristics**
e.g. an information system is being developed.
will the system be safety critical, where human life could be threatened by a malfunction?

**step 3.3: Identify high-level project risks**
consideration must be given to the risks that threaten the successful outcome of the project.

**step 3.4: Take into account user requirements concering implementation**
The client may have their own procedural requirements.

**step 3.5: Select development methodology and life-cycle approach**
The development methodology and project life cycle to be used for the project will be influenced by the issues raised above.

**step 3.6: review overall resource estimates**
Once major risks have been identified and a broad project approach has been decided upon, this would be a good point at which to re-estimate the effort and other resources

### 3.4 Step 4: Identify project products and activities

more detailed planning of the individual activities now take place.

**Step 4.1: Identify and describe project products**

### 3.12 Conclustion
any planning approach should have the following elements

- the establishment of project objectives
- the analysis of the characteristics of the project
- the establisment of an infrastructure consisting of an appropritate organization and set of standards, methods, and tools
- the identification of the products of the project and the activities needed to generate those products.
- the allocation of resources to activities
- the establishment of quality controls.

Project planning is an iterative process.
As the time approaches for particular activities to be carried out they should be replanned in more detail.

## SPM chapter 6: Activity planning

see notes here
https://hackmd.io/BvwU0Y6-T7Kjl3ZL5bK8QQ

## SPM chapter 7: risk management

### Risk
PM-BOK (Project Management Body of Knowledge) defines a rsik as
> "an uncertain event or condition that, if it occurs has a positive or negative effect on a project's objectives"

The key elements of a risk:
- it relates to the future. The future is inherently uncertain. Some things which seem obvious when a project is over.
- It involves **cause** and **effect**

The boundary between rick management and "normal" software project management is hazy.

Rcik management is not a self-contained topic within project management.

A key role of risk management is consindering uncertainty remaining after a plan has been fomulated.

Every plan is based on assumptions and risk management tries to plan for and control the situations where those assumptions become incorrect.

### Categories of risk

sociotechnical model of risk: a diagramme representation. 
'actors' refers to all the people involved in the development
'technology' encompasses both the technology used to implement and embedded in the delievered products.
'structure' describes the management structure and systems, including those affecting planning and control
'tasks' relates to the work planned.

### A framework for dealing with risk
Planning for risk includes these steps
1. risk identification
2. risk analysis and prioritization
3. rick planning
4. risk monitoring

**Risk identification**
two main approaches to identification of risks are the use of checklists and brainstroming

Checklist: simply lists of risks that have been found to occur regularly in software development projects.

project management methodologies often recommend that on completion of a project a review identifies any problems during the project and steps that were taken to resolve or aviod them.

**Brainstoming**
representatives of the main stakeholders should be brought together once some kind of preliminary plan has been drafted.

### Risk assessment
A common problem with risk identification is that a list of risks if potentioally endless.

A way is needed of distingguishing the damaging and likely risks.

It can be done by estimating the risk exposure for each risk the formular:
> risk exposure = (potential damage) x (probability of occurrence)

The calculation of risk exposure above assumes that the amount of damage sustained will always be the same.
that is usually the case that the amount of damage vary.

With some risks there could be not only damage but also gains.

Most managers resist very precise estimates of loss or of the probability of something occuring.


The term *risk proximity* is used to describe this attribute of risk.

### Risk planning
having identified the major risks and allocated priorities.
The task is to decide how to deal with them
- risk acceptance
- risk avoidance
- risk reduction and mitigation
- risk transfer

**risk acceptance**
A do-nothing option.
the risk prioritization process have decided to ignore some risks in order to concentrate on the more likely or damaging.

**risk aviodance**
some activities may be prone to accident that is best to aviod them altogether.

**Risk reduction**
Decide to go ahead with a course of action despite the risks.

It must be appreciated that each risk reduction action is likely to involve some cost.

Risk mitigation can sometimes be distinguished from risk reduction.
risk reduction attempts to reduce the likelihood of the risk occuring.

Risk mitigation is action taken to ensure that the impact of the risk us lessened when it occurs.

**Risk transfer**

the risk is transferred to another person or organization.

what effectively happens when you buy insurance.

### Risk management

**Contingency**
Risk reduction activities would appear to have only small impact on reducing the probability of some risks.

There may be some things that have to be done in order for the contingengt action to be feasible.

**Deciding on the risk actions**
For each actual risk a specific actions have to be planned.

**Creating and maintaining the risk register**

record risks in risk register.
The content of a risk register is shown in book p. 175

### Conclusion
Risk management is concerned with assessing and prioritizing risks and drawing up plans for addressing those risks before they become problems.

described techniques for estimating the effect of risk on the project's activity network and schedule.

Many risks affecting software projects can be reduced by allocating more experienced staff to those activities that are affected.

## Challenges of migrating to agile methodologies.

Software development methodologies are constantly evolving due to changing technologies and new demands from users.

organizations continuously adapt their structures, strategies, and policies to suot the new enviroment.

Changing requirements - but the traditional, plan-driven software development methodologies lack the flexibility to dynamically adjust the development process.

OO approaches provide a viable method to incrementally develop information systems.

New methods called agile development:
- methodologies, lightweight methodologies clain to go a step further in overcoming the limitations of traditional plan-driven.

>organizations must carefully evolve toward the best balance of agile and plan-driven methods that fits their situation

Most organizations cannot ignore the agile wave, but for those steeped in traditional systems development, adoption of agile methodologies will likely pose several challenges.

Software development is a complex activity characterized by tasks and requirements that exhibit a high degree of variability.

The changing nature and sophistication of tools may also exacerbate development problems.

The traditional software development approach is process-centric.
- guided by a life cycle model such as the waterfall model.

Traditional vs agile software development.

Agile methodologies deal with unpredictability by relying on people and their creativity rather than on processes.
- characterized by short iterative cycles of development driven by product features, periods of reflection and introspections, collaborative decisions making.

Agile methodologies favor a leadership-and-collaboration style of management where the project manager role is that of a facilitator or coordinator.

Agile development is characterized by social inquiry in which extensive collaboration and communication provide the basis for collective action.

Key issues in migrating to agile.

While the opportunities and benefits that agile methodologies afford make them attractive, organizations should be circumspect in embracing them or in intergrating them with existing practices.