IT Project Management Individual Assignment

Tubekbay001

Lesson20OverallRevision2.pptx

Home >Computer Science homework help >IT Project Management Individual Assignment

IT Project Management

version 1.0

Diploma in Information Technology

Lesson 20 : Overall Revision – Part 2

IT Project Management

version 1.0

Diploma in Information Technology

Lesson 11: Project Cost management

11.1.2 What is cost management?

Project cost management includes the processes required to ensure that the project is completed within an approved budget.

Project managers must make sure their projects are well defined, have accurate time and cost estimates and have a realistic budget that they were involved in approving.

Direct costs are costs that can be directly related to producing the products and services of the project.

Example: Salaries, cost of hardware and software purchased specifically for the project

Indirect costs are costs that are not directly related to the creating of products or services of the project, but are directly related to performing the project.

Example: Cost of electricity, paper towels

11.1.3 Basic principles of Cost management

Sunk cost is money that has been spent in the past; when deciding what projects to invest in or continue, we should not include sunk costs.

To continue funding a failed project because a great deal of money has already been spent on it is not a valid way to decide on which projects to fund.

Sunk costs should be forgotten.

11.1.3 Basic principles of Cost management

11.1.3 Reasons why cost overruns

Not emphasising the importance of realistic project cost estimates from the outset.

Many of the original cost estimates for IT projects are low to begin with and based on very unclear project requirements.

Many IT professionals think preparing cost estimates is a job for accountants when in fact it is a very demanding and important skill that project managers need to acquire.

Many IT projects involve new technology or business processes which involve untested products and inherent risks.

11.1.3 Reasons why cost overruns

11.2 Cost management processes

There are 3 project cost management processes:

Cost estimating: developing an approximation or estimate of the costs of the resources needed to complete a project

Cost budgeting: allocating the overall cost estimate to individual work items to establish a baseline for measuring performance

Cost control: controlling changes to the project budget

11.2 Cost management processes

11.3 Costs estimating

After developing a good resource requirements list, PMs and their teams must develop several estimates of the costs for these resources

PMs must take cost estimates seriously if they want to complete projects within budget constraints

It’s important to know the types of cost estimates, how to prepare cost estimates, and typical problems associated with IT cost estimates

11.3.1 Rough Order of Magnitude

A rough order of magnitude (ROM) estimate provides an estimate of what a project will cost.

Also referred to as a ballpark estimate, a guesstimate or a broad gauge.

Done very early in a project, often three or more years prior to project completion, or even before a project is officially started to help PMs make project selection decisions.

11.3.2 Budgetary Estimate

Many organisations develop budgets at least two years into the future. Budgetary estimate is used to allocate money into an organisation’s budget.

Budgetary estimates are made 1 to 2 years prior to project completion.

Its’ accuracy is typically (-10% to +25%)

For example: A budgetary estimate that actually costs $100,000 would range between $90,000 to $125,000.

11.3.3 Definitive Estimate

A definitive estimate provides an accurate estimate of project costs (most accurate of the three types).

Definitive estimates are used for making many purchasing decisions for which accurate estimates are required and for estimating final project costs.

11.3.4 Comparisons of the 3 estimates

IT Project Management

version 1.0

Diploma in Information Technology

Lesson 12: Project Resource Management

12.3.1 Maslow’s Hierarchy of Needs

12.3.2 Herzberg’s Motivational & Hygiene Factors

12.3.3 David McClelland – 3 Needs Theory

12.3.4 McGregor’s Theory X & Y

12.3.5 Thamhain & Wilemon on influencing workers

12.3.6 Stephen Covey 7 Habits

Project managers can apply Covey’s 7 habits to improve effectiveness on projects:

12.3.6 Stephen Covey 7 Habits

No	Habit	Means
1	Be proactive	Take initiative
2	Begin with the end in mind	Focus on goals
3	Put first things first	Set priorities
4	Always think Win/Win	We win only when others win
5	Seek first to understand, then to be understood	Communicate
6	Always synergise	Cooperate
7	Sharpen the saw	Reflect on and repair the deficiencies

12.4 Tuckman’s Stages of Group Development

12.6.3 Responsibility Assignment Matrix

A responsibility assignment matrix (RAM) is a matrix that maps the work of the project as described in the work breakdown structure (WBS) to the people responsible for performing the work

For smaller projects, it is best to assign WBS activities to individuals; for larger projects, it is more effective to assign the work to organisational units or teams

RACI charts are a type of RAM that show:

Responsibility (who does the task),

Accountability (who signs off on the task or has authority for it),

Consultation (who has information necessary to complete the task),

Informed (who needs to be notified of task status/results) roles for project stakeholders

12.6.3 Responsibility Assignment Matrix

Sample RACI Chart

Tasks	Kristin	Jamie	Mohamed	Supplier A
Needs assessment	A	R	C	I
Research of existing training	I	R, A	C	I
Partnerships	R, A	I	I	C
Course development	A	C	C	R
Course administration	I	A	R
Course evaluation	I	A	R	I
Stakeholder communications	R, A	C	C	C

12.6.3 Responsibility Assignment Matrix

12.6.4 Resource Histogram

A resource histogram is a column chart that shows the number of resources required for or assigned to a project over time

In planning project staffing needs, senior managers often create a resource histogram in which columns represent the number of people needed in each skill category. By stacking the columns, the total number of people needed each month can be seen

After resources are assigned to a project, the resource histogram for each person can be seen on how his/her time has been allocated

12.6.4 Resource Histogram

PM 1 2 3 4 5 6 7 8 9 10 11 12 0.75 0.75 0.75 0.75 0.75 0.75 0.75 0.75 0.75 0.75 0.75 0.75 HR 1 2 3 4 5 6 7 8 9 10 11 12 1 1 1 1 1 1 1 1 1 1 1 1 SM 1 2 3 4 5 6 7 8 9 10 11 12 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 IT 1 2 3 4 5 6 7 8 9 10 11 12 0.25 0.5 0.5 0.5 0.25 0.25 0.25 0.25 0.25 0.25 0.25 0.25 Contracting 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0.25 0.25 0.25 0.25 0.2 5 0.25 0.25 0.25 0.25 0.25 PMO 1 2 3 4 5 6 7 8 9 10 11 12 0 0.5 0.5 0.5 0.5 0 0 0 0 0 0 0 Miscellaneous 1 2 3 4 5 6 7 8 9 10 11 12 0.25 0.25 0.25 0.25 0.25 0.5 0.5 0.5 0.5 0.25 0.25 0.25

Month

Number of People

IT Project Management

version 1.0

Diploma in Information Technology

Lesson 13: Project Stakeholder Management

13.2 Project Stakeholder Management Processes

Identifying stakeholders: Identifying everyone involved in the project or affected by it and determining the best ways to manage relationships with them.

Planning stakeholder management: Determining strategies to effectively engage the stakeholders

Managing stakeholder engagement: Communicating and working with project stakeholders to satisfy their needs and expectations, resolving issues, and fostering engagement in project decisions and activities

Controlling stakeholder engagement: Monitoring stakeholder relationships and adjusting plans and strategies for engaging stakeholders as needed

13.2 Project Stakeholder Management Processes

Power / Interest Grid

13.3.2 Classifying Stakeholders

13.3.4 Stakeholder Engagement Levels

Unaware: Unaware of the project and its potential impacts on them

Resistant: Aware of the project yet

resistant to change

Neutral: Aware of the project yet neither supportive nor resistant

Supportive: Aware of the project and supportive of change

Leading: Aware of the project

13.4 Planning Stakeholder Management

After identifying and analysing stakeholders, project teams should develop a plan for management them

The stakeholder management plan (SMP) can include:

Current and desired engagement levels

Inter-relationships between stakeholders

Communication requirements

Potential management strategies for each stakeholder

Methods for updating the SMP

13.4.1 Sensitive Information

Stakeholder management plan (SMP) often includes sensitive information, it should not be part of the official project documents, which are normally available for all stakeholders to review

Often, only project managers and a few other team members should prepare the SMP

Parts of the SMP are not written down, and if they are, distribution is strictly limited

13.5 Managing Stakeholder Engagement

Expectations Management Matrix

13.5 Managing Stakeholder Engagement

Suggestions for handling these situations include the following:

Be clear from the start

Explain the consequences

Have a contingency plan

Avoid surprises

Take a stand

13.5 Managing Stakeholder Engagement

13.8 Social Media for Project Managers

Elizabeth Harrin, author of Social Media for Project Managers provides advice for when to use social media and when not to use it

As the saying goes, “A fool with a tool is still just a fool.” A lot of stakeholder engagement requires old-fashioned techniques like talking to someone!

IT Project Management

version 1.0

Diploma in Information Technology

Lesson 14: Agile with Scrum

14.1 What is Agile Project Management?

Agile Project Management (APM) is the process of breaking a project down into manageable steps with an emphasis on responsiveness and customer collaboration.

This new and flexible style of project management is being adopted by many businesses.

Faster products delivery can be achieved the implementation of APM.

14.1.1 Core Values of Agile Project Management

Individuals and interactions over processes and tools

APM dictates that human interaction takes precedence over everything else. Check in with team members and the customer frequently to make sure everyone understands the project and is happy with the direction.

14.1.1 Core Values of Agile Project Management

2. Working software over comprehensive documentation

Traditional project management requires extensive documentation in the form of written technical documents. APM values documentation but recommends the use of software to keep the necessary documents and records efficiently.

14.1.1 Core Values of Agile Project Management

3. Customer collaboration over contract negotiation

The customers are included in the process of design and production. Their input throughout the project, rather than at the start and conclusion, will ensure that every action taken by the team is in the right direction.

14.1.1 Core Values of Agile Project Management

4. Responding to change over following a plan

Be prepared and willing to adapt as the project demands. Use data to decide on the next action.

Use formative assessments along the way to shift the process to create the best product, rather than to follow a predetermined set of steps to a conclusion and then assess the outcome.

14.1.2 Principles of Agile Project Management

12 Principles:

The highest priority is to satisfy the customer through early and continuous delivery of valuable software (or whatever the product or output is).

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver projects frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

14.1.2 Principles of Agile Project Management

Coordinating team members must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

Face-to-face conversation is the most efficient and effective method of conveying information to and within different teams.

14.1.2 Principles of Agile Project Management

The final product is the primary measure of progress.

Agile processes promote sustainable development. All stakeholders should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

14.1.2 Principles of Agile Project Management

Simplicity - the art of maximising the amount of work not done - is essential.

The best architectures, requirements and designs emerge from self-organising teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

14.2.1 Traditional vs Agile PM

Traditional PM	Agile PM
Project team would set a specific goal, create a series of steps to reach that goal and then implement the process.	Breaks a project down into small goals, or sprints, and utilises frequent assessments to reshape the steps and even possibly the end goal.
Linear - Each step must be completed before the next can begin.	Iterative - Steps can be worked on simultaneously and assessed at the same time.

14.3 Agile PM Methodologies

Agile project management has 6 steps.

1. Project planning

The team determine the project's end goal which should be relatively broad, to account for revisions and improvements throughout the process.

2. Creating the project roadmap

The roadmap is made up of all the features included in the final product. This is not a list of steps, but instead a list of elements that can be completed somewhat simultaneously.

14.3 Agile PM Methodologies

3. Release planning

A release plan is a calendar of when prototypes or product elements will be delivered to the customer for review. The expectation is that individual pieces of the total project will be reviewed frequently, and the overall project updated as needed.

4. Sprint planning

Sprints are short-cycle design times that end with a product release. Sprint planning should be detailed. Every team member should know what they are expected to accomplish during every day of the sprint.

14.3 Agile PM Methodologies

5. Daily meetings

Start each workday during a sprint with a meeting.

Team members will share successes and challenges from the previous day.

Confirm tasks and goals for that workday.

14.3 Agile PM Methodologies

6. Sprint reviews and retrospective

Sprint review :

Presentation of the product element to the customer.

The team will receive feedback and prepare to revise the element or adjust the long-term goal as directed by the customer.

Sprint retrospect:

The team will meet separately from the client and reflect on the sprint issues (workload imbalance, deadlines & communication) to be addressed and improved for the next sprint.

2-4 weeks

14.4 Scrum Framework

14.4.1 Sprint in Scrum

A Sprint is usually limited to one calendar month (or 4 weeks). When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase.

A new Sprint starts immediately after the conclusion of the previous Sprint.

14.5 Roles & Responsibilities in Scrum

These are the roles in a Scrum project:

Communicate

14.5 Roles & Responsibilities in Scrum

14.5.1 The Product Owner

The product owner is the one in charge of the business side of the project and is held accountable when processes do not follow the right order.

Being a primary stakeholder in the project, it is the Product Owner’s responsibility to have a vision for what he or she hopes to see.

The ability to communicate that vision to the entire team also falls squarely on his/her shoulders.

14.5.2 The Scrum Master

Scrum Master ensures team coordination and supports the progress of the project between individual team members. He/She takes the instructions from the Product Owner and ensure that the tasks are performed accordingly.

He/She acts as a teacher and coach, verifying certain team members adhere to the theory and practices of Scrum.

14.5.3 Development Members

Members of the Scrum team are expected to report their daily progress, along with any successes and challenges to the Scrum team during daily stand-up meetings.

The scrum team usually consists of Professionals:

Self organising

Communicates with Product owner

IT Project Management

version 1.0

Diploma in Information Technology

Lesson 15: Project Quality Management - 1

15.1 What Is Quality?

Dimension	Description
Performance	Will the product perform its intended function?
Special Features	Additional function to the product
Perceived Quality	What is the reputation of the company or its product?
Conformance	Is the product made exactly to the designer or customer requirements/specifications?
Aesthetics	How does the product look like?
Reliability	The probability that the product can function under stated condition without failure for a given period of time.
Durability	What is the lifetime of the product?
Serviceability	How easy is it to repair the product?

Garvin (1987) proposed the following 8 dimensions of product quality

15.1.1 IT Projects Quality Dimensions

Dimension	Description
Functionality	The degree to which a system performs its intended function
Features	The system’s special characteristics that appeal to user
Performance	How well a product or service performs the customer’s intended use
Reliability	The ability of a product or service to perform as expected under normal conditions
System outputs	The screens and reports the system generates
Maintainability	The ease of performing maintenance on a product

15.2.2 Total Quality Management

Total Quality Management (TQM) refers to a quality emphasis that encompasses the entire organisation, from supplier to customer.

TQM stresses a commitment by management to have a continuous companywide drive toward excellence in all aspects of products and services that are important to the customer.

Plan-Do-Check-Act (PDCA) Cycle

15.2.3 Continuous Improvement

15.3 How Quality Relates to IT Project

Many IT project managers face pressures to deliver systems and technologies which meet the customer’s ever-changing needs that quality suffers.

Many of the problems occur due to the complexity of technology and the rapid pace of change.

These dynamic conditions are not likely to abate; in fact, they're accelerating at an alarming rate.

15.3 How Quality Relates to IT Project

However, performance can be greatly improved by ensuring that tactical decisions in IT project focus on the quality aspects.

Quality improvements in IT project delivery can be achieved by considering user satisfaction, integration and flexibility in the early stage of decision process and reinforcing them throughout the review process.

15.3 How Quality Relates to IT Project

Although there are no perfect solutions, quality management helps to ensure standards are rigorously enforced and embedded into the thinking of the entire IT project team.

One of the challenges for IT project is to tap on the past quality experiences and valuable lessons.

15.5 Project Quality Management

A good quality management plan starts with a clear definition of the goal of the project.

These following questions help to identify and define quality requirements, allowing the project team to discuss the approach and plans needed to achieve those goals.

15.6 Quality Planning (QP)

15.6.1 Project Metrics

15.6.3 Project Dashboard

15.7 Quality Assurance (QA)

Quality assurance is the planned and systemic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled.

Use quality assurance to make sure the processes are in fact working towards making the project deliverables meet quality requirements.

15.8 Quality Control (QC)

QC involves operational techniques meant to ensure quality standards. This includes identifying, analysing, and correcting problems.

While QA occurs before a problem is identified, QC is reactionary and occurs after a problem has been identified and suggests methods of improvement.

IT Project Management

version 1.0

Diploma in Information Technology

Lesson 16: Project Quality Management 2

16.1.1 Check Sheet

It is used to easily collect data. Decision-making and actions are taken from the data.

16.1.2 Scatter Diagram

It is a graphical tool that plots many data points and shows a pattern of correlation between two variables.

16.1.3 Cause-and-Effect Diagram

It is used to figure out any possible causes of a problem. After the major causes are known, we can solve the problem accurately

16.1.4 Pareto Chart

It is used to define problems, to set their priority, to illustrate the problems detected, and determine their frequency in the process.

16.1.5 Flow Chart

It shows the process step by step.

16.1.6 Histogram

It shows a bar chart of accumulated data and provides the easiest way to evaluate the distribution of data.

It provides control limits which are generally three standard deviations above and below average, whether or not a process is in control.

Upper control limit

Average value

Lower control limit

Time

3

16.1.7 Statistical Process Control Chart

Control charts attempt to distinguish between two types of process variation:

Common cause variation: which is intrinsic to the process and will always be present.

Special cause variation: which stems from external sources and indicates that the process is out of statistical control.

16.1.7 Statistical Process Control Chart

The above process is in control, all data points are within the control limits.

16.1.7 Statistical Process Control Chart

The 2 points marked by “X” are out of control.

16.1.7 Statistical Process Control Chart

16.2 Six Sigma

16.3 Testing of IT software

A unit test is done to test each individual component (often a program) to ensure that it is as defect-free as possible. Unit tests are performed before moving onto the integration test.

Integration testing occurs between unit and system testing to test functionally grouped components. It ensures a subset(s) of the entire system works together.

System testing tests the entire system as one entity. It focuses on the big picture to ensure that the entire system is working properly.

User acceptance testing is an independent test performed by end users prior to accepting the delivered system. It focuses on the business fit of the system to the organisation, rather than technical issues.

16.3 Testing of IT software

16.4.2 Cost of Quality

Cost of conformance

Prevention cost – Cost of planning and executing a project so it is error-free or within an acceptable error range. Example: training, quality planning, process studies etc.

Appraisal cost – Cost of evaluating processes and their outputs to ensure quality. Example: testing, destructive testing loss and inspections.

16.4.2 Cost of Quality

Cost of non-conformance

Internal failure cost – Cost incurred to correct an identified defect before the customer receives the product. Example: rework and scrap, corrective actions etc.

External failure cost – Cost that relates to all defects and problems after the customer has received the product. Example: Returned goods, customer complaint, warranty etc.

15.9 Using Software to Assist in Project Quality Management

Bug tracking software: A software where bugs are reported, tracked, and then resolved.

Automated testing software: While there is no substitute to human testing to ensure a very stable end product, automated testing can weed out the most common bugs and will make the human testing less stressful.

15.9 Using Software to Assist in Project Quality Management

Collaboration software:

The project manager and team members use to exchange information about the project.

Team members can ask for help from other team members when facing challenges on their tasks.

Team members building upon code that is written by other team members can inform the latter about errors in their codes.

Testers can inform developers about their bugs.

IT Project Management

version 1.0

Diploma in Information Technology

Lesson 17: Project Communication Plan

17.2 Processes in Project Communications Management

There are five (5) main processes:

Identifying stakeholders

Planning communications

Distributing information

Managing stakeholders

Reporting performance

100

What must the communication plan include:

The purpose or goals of the communication plan

Information about stakeholders and their roles

The types of information that needed to be shared with stakeholders

The methods used to communicate

The frequency that each stakeholder would like to receive information

17.3 Plan Communication

101

17.3 Plan Communication

An illustration of the Communication Plan

102

17.4 Distributing Information

Advantages	Disadvantages
Suitable for group or individual meetings. Can be either formal or informal. Allows for instant feedback.	Can be costly if participants have to be brought in from overseas or other places. Need time & resources to facilitate such meetings. Need a staff to ensure minutes are taken & distributed to all participants.

1. Face-to-Face Communications

103

17.4 Distributing Information

Advantages	Disadvantages
Paper-less. Easy access to the Internet, computers & mobile devices. Communication via the Internet is faster, cheaper & easier to retain for record purposes. Can also maintain a project portal or intranet site to share project data.	Risk of data loss or unauthorised access to confidential project information by hackers.

2. Digital Communications

104

17.4 Distributing Information

Advantages	Disadvantages
They are visual & textual, can be edited & revised several times to shape them for maximum effect before being distributed. Provide a permanent record of the communication which can be archived for later retrieval.	Need storage space. Need paper, which can be cumbersome to file and store in large quantities. Aging documents are susceptible to loss or damage can lead to difficulties in managing project records.

3. Hard Copy Communications

105

17.4 Distributing Information

Advantages	Disadvantages
Can be used to pull a large group together. Allow for real-time video collaboration. Most video conferencing tools provide white boards & other options for document sharing and editing.	Time zones - can be difficult to get everyone scheduled in a session depending on where they are in the world. Personal aspect of a conversation is taken away. Conferencing etiquette may not be observed by some users (e.g. late, not paying attention.

4. Conferencing

106

17.4.1 Number of Communications Channels

There is a simple formula for determining the number of communications channels as the number of people involved in a project increases.

We can calculate the number of communications channels as follows:

107

17.4.1 Number of Communications Channels

108

17.7.1 Managing Conflicts

Blake and Mouton (1964) delineated five (5) basic modes for handling conflicts: Each mode can be rated as high, medium, or low on two dimensions: importance of Task (T), and importance of Relationship (R) between the people having the conflict.

109

Confrontation or problem‐solving: Directly face a conflict (High T/High R)

Compromise: Use a give‐and‐take approach (Medium T/Medium R)

Smoothing: De‐emphasise areas of differences and emphasise areas of agreement (Low T/High R)

Forcing: The win‐lose approach (High T/Low R)

Withdrawal: Retreat or withdraw from an actual/potential disagreement (Low T/Low R)

17.7.1 Managing Conflicts

110

Confrontation or problem‐solving

Compromise

Smoothing

Forcing

Withdrawal

17.7.1 Managing Conflicts

111

Sadly, not many people know how to run meetings effectively and end up wasting time and not achieving much.

If done properly, meetings can yield great results keeping everyone informed about progress and bottlenecks in a project.

To conduct productive meetings, include an agenda, updated status reports, and the next course of action followed by a quick summary.

Encourage others to voice their ideas and opinions in meetings to have a two-way dialogue and effective communication.

17.7.2 Running Effective Meetings

112

Face-to-face communication is nice, but not always possible, especially in the case of distributed teams (e.g. work from home)

Online communication tools like Skype and Zoom give you the opportunity to bring a group of people together for a discussion in a more personalised way than that which is allowed by e-mail.

17.7.3 Use Online Communication Tools

113

IT Project Management

version 1.0

Diploma in Information Technology

Lesson 18: Project Risk Management

114

The main planning processes are:

Planning risk management,

Identifying risks,

Performing qualitative risk analysis,

Performing quantitative risk analysis,

Planning risk responses.

18.2 Risk Planning Processes

115

18.2 Risk Planning Processes

116

Risk events refer to specific, uncertain events that may occur to the detriment or enhancement of the project.

Negative risk events include the performance failure of a product produced as part of a project, delays in completing work as scheduled, increases in estimated costs, supply shortages, litigation against the company, and strikes (+ political turmoil, natural disasters).

18.4 Identifying Risks

117

Positive risk events include completing work sooner than planned or at an unexpectedly reduced cost, collaborating with suppliers to produce better products, and obtaining good publicity from the project.

We can chart the probability and impact of risk events on a matrix.

18.4 Identifying Risks

118

Mid-project change in scope.

Changes in scope are frequent in IT projects.

Suggestions for radical change can arise after the project implementation has started.

Very unpleasant when it happens in the middle of the project.

Choices are either to reject the changes or to trash the work done up to that point and implement the new requests.

18.4.1 Risks in IT Project

119

Going behind schedule due to unforeseen complications.

Unforeseen technical complications can turn the project upside down.

Surprises are still possible despite knowing the technologies well.

Unfortunately, little can be done to avoid this common IT project risk but pray that it doesn’t happen to you.

18.4.1 Risks in IT Project

120

3. Technical inability for a given feature to be implemented.

Technical complications lead to project delays and can affect the scope.

If a given functionality can’t be implemented due to technical inability, the easiest solution is to skip this functionality but when other components depend on it, then it is not wise to do so.

Having experienced technical people can lower the risk of unforeseen technical limitations but this risk is always present.

18.4.1 Risks in IT Project

121

4. No problems are reported.

When everything is blissfully calm and no problems are reported, this should be worrying.

It could mean that there are no problems to report, which is extremely rare, or that problems exist but nobody dares to report.

Sometimes even brave guys and gals are cautious to be the messenger to report a severe problem as they know the “shoot the messenger” approach by the upper management.

18.4.1 Risks in IT Project

122

5. A key employee leaves.

When a key employee quits, it can really shatter a project.

Employees quit due to various reasons and generally they do serve a notice period.

When a key employee is leaving soon, there is a need to rearrange the team.

If there is no suitable person to take over the tasks of the leaving person, this can have serious disruptions.

18.4.1 Risks in IT Project

123

It includes:

An identification number for each risk event

A rank for each risk event (usually high, medium, or low)

The name of the risk event

A description of the risk event

The category under which the risk event falls

The root cause: The real or underlying reason a problem occurs

Triggers: Indicators or symptoms of actual risk events

Potential responses to each risk event

The risk owner, or person who will own or take responsibility

The probability of the risk event occurring

The impact to the project if the risk event occurs

The status of the risk event

18.4.2 Risk Register

124

18.4.3 Risk Register Template

125

18.5 Performing Qualitative Risk Analysis

Results in prioritising risks as High, Medium, or Low.

A probability and impact matrix is a good technique to help decide which risks are most important on a project.

126

Probability and Impact Matrix.

18.5 Performing Qualitative Risk Analysis

127

The formula for EMV of a risk is this:

Expected Monetary Value (EMV)

= Probability of the Risk (P) * Impact of the Risk (I)

or simply,

EMV = P * I

18.6.1 Decision Tree Analysis

128

EMV calculates the average outcome when the future includes uncertain scenarios — positive (opportunities) or negative (threats).

Opportunities are expressed as positive (+) values, while threats have negative (-) values.

Both the values will be considered by adding them together.

18.6.1 Decision Tree Analysis

129

Example:

For a work package, the negative risk (or threat) has a 10% probability with an estimated loss of $50,000, while the positive risk (opportunity) has a 15% probability with a potential return of $30,000. Should you execute the work package?

Answer:

EMV for the threat = P * I = 10% * (-$50,000) = -$5000

EMV for the opportunity = P * I = 15% * (+$30,000) = $4,500

Now, the EMV = – $5,000 + $4,500 = -$500

18.6.1 Decision Tree Analysis

130

18.6.1 Decision Tree Analysis

Legend:

131

18.6.1 Decision Tree Analysis

EMV for Chance Node 1, (the 1st circle):

The net path value for the prototype with 70% success = Payoff – Cost:

= +$500,000 – $100,000

= +$400,000

The net path value, for the prototype with a 30% failure = Payoff – Cost:

= -$50,000 – $100,000

= -$150,000

EMV of chance node 1 = [70% * (+$400,000)] + (30% * (-$150,000)]

= +$280,000 – $45,000

= +$235,000

132

18.6.1 Decision Tree Analysis

EMV for Chance Node 2 (the 2nd circle):

The net path value for the prototype with a 20% success = Payoff – Cost:

= +$500,000 – $0

= +$500,000

The net path value for the prototype with 80% failure = Payoff – Cost:

= -$250,000 – $0

= -$250,000

EMV of chance node 2 = [20% * (+$500,000)] + (80% * (-$250,000)]

= +$100,000 – $200,000

= -$100,000

133

18.6.1 Decision Tree Analysis

134

18.7 Planning Risk Responses

Negative risk responses	Description
Risk acceptance	Passive acceptance: No action, and deal with the risks as they occur Active acceptance: Establish a contingency reserve to deal with the risk
Risk avoidance	Eliminate the threat entirely; Remove the causes that are creating risks
Risk transference	Shift some or all ownership of a threat to 3rd party who can better manage & control it
Risk mitigation	Reduce the impact and/or probability of threat

135

18.7 Planning Risk Responses

Positive risk responses	Description
Risk acceptance	Not actively pursuing, but willing to take the opportunity when it occur
Risk exploitation	Eliminate the uncertainties to ensure or increase the cause for the opportunity to happen
Risk enhancement	Increasing the probability and/or impact of the opportunity
Risk sharing	Allocate some or all the ownership of the opportunity to a 3rd party who can capture and take advantage of it

136

Questions?

137