Value-Driven Delivery

This is the third lesson of the ACP tutorial, which is part of the PMI-ACP Certification course offered by Simplilearn. We will learn a value-driven approach to project management in this tutorial.

Objectives

After completing this tutorial, you will be able to:

Explain the concept of Time Value of Money
Take project decisions based on NPV, IRR, ROI, and payback period of a project
Describe customer-value prioritization
Discuss the various prioritization techniques
Explain risk-adjusted product backlog

Value

Value is a measure of benefit created through the delivery of goods or services. Value is not always related to monetary benefits, a significant increase in customer satisfaction also delivers value to the organization.

An organization can choose different measures to gauge the value delivered. Some of them are

Revenue per Employee
Innovation Rate
Customer Satisfaction
Employee Satisfaction
Customer Usage
Customer Retention
Repeat Customers
Revenue per Employee

Forecasting Value

All projects require forecasting such as cost, schedule, budget, resource requirements, and technology trends. Even the agilest organizations require forecasts. Forecasting is relevant in Agile projects as most of the details emerge only as the project progresses.

Forecasting the value of a project helps organizations decide whether the project is beneficial to proceed or to stop the project or Fail Fast The Product Owner is responsible for maximizing the project value; however, inputs can be provided by the entire project team.

Time Value of Money

Time Value of Money is a key concept to be considered while forecasting the expected value return of the project.

This concept implies the following:

The money available in the present is worth more in the future
The potential to earn more money through interest is capitalized, if the money is available today, against the same quantum of money made available in the future.

Time Value of Money - Terminologies

The terminologies used while determining the Time Value of Money are:

Present Value: An amount of money in the present or the current value of a future cash flow.
Future Value: An amount of money at some future time period.
Period: A length of time, often a year, but can be a month, week, day, or hour, for which the money has been invested.
The Rate of Interest: The compensation paid to a lender or saver for the use of funds, expressed as a percentage for a period which is normally expressed as an annual rate.

Financial Feasibility of Projects

Generally, projects are undertaken for two primary purposes, to increase the revenue and reduce the operating cost by automating some workflows. However, at times projects are also undertaken for regulatory compliance and performance improvement purposes.

The financial feasibility study is performed by Product Owners to determine how profitable the project would be and the Project Sponsors review the analysis.

To forecast the financial feasibility of a project, the following metrics are widely used:

Return on Investment or ROI
Net Present Value or NPV
Internal Rate of Return or IRR
Payback Period.

Each of these metrics is discussed in detail in this lesson.

Return on Investment

Return on Investment or ROI is a performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments. Many organizations have a required rate of return or minimum acceptable rate of return for projects. The mathematical formula for calculating the ROI is given below for your reference. Note that the higher ROI yields better results for an organization.

Net Present Value

Net Present Value or NPV is a method of calculating the expected net monetary gain or loss from a project by discounting all the expected future cash inflows and outflows to the present value. Some of the key points to remember about NPV are as follows:

NPV is a measure of the amount of money the project is expected to earn in today’s value.
NPV is used to compare and prioritize projects.
The decision rule of NPV is, ‘If the NPV is positive, accept the project.’
A positive NPV means that the project is expected to add value to the firm and will, therefore, increase the wealth of the owners.
NPV is a direct measure of how well the project meets the goal. The formula to calculate NPV is given below, for your reference.

Net Present Value - Example

The details of Project 1 and Project 2 along with their cash flow for a period of five years, at an interest rate of 10%, is given in the table. The cash flow for each year is computed by subtracting Cost from Revenue.

The resultant value is then used to compute the NPV. Note that the cash flow of both projects are the same which is $5,000, but NPVs are different. Higher the NPV, better the project. On that premise, Project 2 must be selected over Project 1, as it has a higher NPV.

Internal Rate of Return

Internal Rate of Return or IRR shows the interest rate at which the NPV becomes zero. It is a measure of the rate at which money invested in the project will increase in value. The IRR is expressed as a percentage per year. A Compant establishes the IRR as the minimum threshold a project must exceed to be considered viable.

Usually, this threshold is the point at which equity holders would receive a higher return than if they allowed the investment to merely collect interest. Take a look at the formula to calculate the IRR shown here. IRR is considered a refined measure because it takes into consideration the Time Value of Money.

Higher the IRR, the better it is, because a higher IRR indicates that the value will grow faster. Note that organizations prefer projects with the higher internal rate of return.

Internal Rate of Return - Example

The following is an example for calculating the Internal Rate of Return: Project A has an investment of $200,000 and generates an IRR of 27%. Project B has an initial investment of $100,000 and an IRR of 43%. Which is the best project to choose from?

The IRRs of Projects A and B are 27% and 43%, respectively. Project B must be selected, as it has a higher Internal Rate of Return than Project A.

Payback Period

Payback period is the amount of time taken to regain the net amount invested in a project, in the form of net cash inflows. Payback period indicates how soon the project will recover its initial investment. The primary advantage of the payback period as a measure is that it is very simple and straightforward to calculate and interpret.

Also, the payback period measures the amount and duration of financial risk taken by the organization. Note that many organizations want IT projects to have a short payback period.

NPV, ROI and Payback Period - Example

The summary of a project’s financial measures for a period of five years is given in the table. Using this data, determine the NPV, ROI and Payback Period of the project. Using the discount factor, determine the present value of cost for each year.

Similarly, determine the discounted benefit for each year. The total cost over the period of five years is $9,000. However, when the cost is reduced to its present value by using the discount factor, it is $7,426. Similarly, the total benefits over the period of five years are $14,000. However, when the total benefits are reduced to its present value by using the discount factor, it comes to $9,744.

Based on the data, Net Present Value equals $2,318, which is the difference between $9,744 and $7,426. Return on Investment is determined by dividing the difference between the projected savings or benefits and costs with the costs.

Based on the data, Return on Investment is 31%. Based on the data, the cumulative benefit including the cost becomes positive in the 5th year. Therefore, the payback period will tentatively be after the 4th year.

Prioritization

The key purpose of prioritization is to identify the high-value features and get them delivered on priority. This helps organizations provide maximum benefits to the customer. Prioritization also helps to decide the order of requirements for the team to work on. It also adjusts the scope to meet budget or timeline objectives while retaining a useful set of functionality or Minimum Marketable Release.

It also helps in deciding the release planning, iteration planning, and insertion of new requirements, Prioritization also determines the low priority or non-value adding tasks to avoid working on them.

Factors in Prioritization

The factors to be considered while prioritizing requirements are as follows:

The financial value delivery by the features, that is, the value could be expressed as new revenue, incremental revenue or more revenue from existing customers, or operational efficiency or cost reduction.
The cost of developing the features, that is, value and cost together indicate the return on investment for the features.
Amount and significance of learning and new knowledge that the team gains while working on the features.
Amount of risk removed by developing the features, that is, the risk incurred by introducing the new features.

Agile Customer - Value Prioritization

The product owner should continuously assess the product backlog and prioritize the requirement based on their customer-value. Determining customer-value involves activities such as collaborating with customers, creating focus groups, and reducing technical debt, which addresses quality and improves delivery throughout.

The following aspects must be factored while focusing on the customer-value prioritization:

Focus on innovation means; focus starts with the innovation and moves to efficiency and optimization. Innovation usually offers the highest levels of value creation in a company’s project portfolio.
Focus on execution means, project leaders focus on delivery and add value to projects. However, when they focus on planning and control, they add value to the overhead.
Lean thinking means, systematic elimination of waste. Teams should focus on the value addition and minimize the waste.

Prioritization Techniques

The product owner, business stakeholders, and the team must have a clear understanding of the techniques to be implemented and the rationale associated with each priority. Also, care needs to be taken to ensure that the definition of priorities does not change or get diluted over the course of the project. There are three prioritization techniques that can be applied to Agile:

MoSCoW
Kano Model
Relative Weighting Note that the process of continuously prioritizing the backlog is known as ‘Pruning the Backlog.’

MoSCoW Prioritization

Dynamic Systems Development Method or DSDM is an Agile Methodology that recommends prioritization of requirements using the MoSCoW technique. Under this technique, the requirements are prioritized based on the following:

Must
Should
Could
Won’t

While planning the requirements within any given timebox, we must first try to put in a few MUSTs, then, optionally add on a few SHOULDs and COULDs. Due to reality checks, it may transpire that the team cannot complete all the requirements within the timebox.

However, the team must organize their work so that the requirements which move from one timebox to the other are the COULDs and possibly the SHOULDs, but ideally never the MUSTs. M stands for MUST, that is, these requirements are mandatory.

S stands for SHOULD, that is, these requirements are highly desirable, though not mandatory. C stands for COULD, that is, these requirements are nice to have. W stands for won't, that is, one should not work on these requirements at this point in time.

Before the start of the next timebox, there may be a new set of MUSTs that come in. These could be the new requirements or existing requirements that have been prioritized and transformed as MUSTs.

MoSCoW Prioritization Technique - Example

Nutri Worldwide Inc. wants to launch a new website where orders for consumer durables can be placed online. Tom, the Product Owner, is facing the challenge of prioritizing the requirements listed below. If Tom has to use the MoSCoW prioritization technique, which of these requirements will fall under the categories of Must Have and Should or Could Have?

Tom can prioritize the requirements using the MoSCoW technique as follows: The ‘Must Have’ requirements are non-negotiable and directly impact the success of the project. The requirements such as hardware setup, search options on the website, order placement, and capture shipping details given in the example are necessary to launch and run the website.

They directly impact customers’ website visit, which increases online orders of consumer durables. The ‘Should or Could Have’ requirements are less important or ‘nice to have’ features. Their difference is determined by the level of pain or loss of business value created by not implementing a feature.

These requirements usually have an available workaround option. Customer registration and login are not a mandate as orders can be placed without logging in. Likewise, Online Payment is a desirable feature but the customers can pay through cheques, Demand Drafts, and Cash on Delivery, hence a workaround is available.

Prioritization Techniques - Kano Model

The second technique used for Prioritization is the Kano Model, which was developed by Professor Noriaki Kano. This model strives to fulfill requirements and ensure customer satisfaction. Under this technique, the requirements are prioritized based on the following:

Basic Needs
Performance Needs
Excitement Needs

Two factors impact the satisfaction level here and therefore have a bearing on prioritization decisions, as shown in the image, existence of the features and degree of the implementation.

Some features have a linear relationship with the satisfaction level – the more you implement, higher the satisfaction. Other features have an exponential relationship, that is, as you keep implementing those features, the satisfaction level climbs up exponentially.

Kano Model - Categories

The four categories of the Kano Model are as follows:

Thresholds or Must Have: These features must be present in the product for it to be successful.
Linear or Performance requirements: These features are linearly correlated to the customer satisfaction. The larger number of features leads to higher customer satisfaction.
Exciters and Delighters: These features provide great satisfaction, often adding a premium price to the product. Lack of these features will not decrease customer satisfaction below neutral. These features could be called “differentiators” because they have the potential to delight or excite the customer, and the product can become a premium or niche product.
Indifferent: These features are least important to the customer. They will return or add no business value.

Kano Model - Example

A big mobile handset company is planning to launch a new version of their mobile. Jefferson, the Product Owner, has come up with a list of features which need to be developed and included in the mobile. If Jeff chooses to use KANO analysis for prioritizing the requirements, which of these requirements will fall into different categories?

The requirements can be differentiated using Kano Analysis as follows:

Phonebook, calling, messaging, call logs, and time is a threshold or dissatisfier features. The presence of these features does not result in increased customer satisfaction.
Camera, Bluetooth, and Infrared transfer are linear features. The customer satisfaction improves in a linear manner, as the numbers of features increase.
Instant file transfer is an Exciter and Delighter feature. These features bring immense customer satisfaction. They are time-consuming and costly to develop.

Prioritization Techniques - Relative Weighting

Karl Wiegers created relative Weighting technique. This technique is based on the premise that the features that provide the highest benefits after adjustment for costs, risks, and penalties, should have the highest priority. Relative Weighting helps you to arrive at an unbiased numerical value.

The key aspects of this technique are as follows:

A feature priority is directly proportional to the value it provides, and inversely proportional to its cost and the technical risk associated with its implementation.
Each category uses a scale of one to nine.
Benefits reflect the value a feature will provide, while penalties reflect the negative effect a customer will experience if the feature is not included.
Further, risks reflect the challenges of implementing the feature, and costs reflect the actual costs of implementing the feature.

Relative Weighting - Example

Let us look at an example of Relative Weighting. Each feature is prioritized based on its Relative Weighting for Benefits, Penalties, Costs, and Risks. Each feature uses a relative scale of one to nine to determine its rating.

First, the weight in terms of percentage and the relative rating for each feature across the value, cost, and risk is decided by the Product Owner. Second, the final priority for the feature is computed by using the formula, ‘Priority equals Value divided by Cost plus Risk.’ In the example given, the priority of feature 1 is 0.73, that is, 27 percent divided by 37 percent.

Finally, this value is compared with other values to prioritize the feature that should be used for the immediate Sprint.

Want to learn more about Value driven delivery for your business? Click here!

Risk Management in Agile

Risks are proactively managed in Agile projects by computing the Expected Monetary Value, or EMV, of the negative risks, and ensuring that the response strategy for risks with higher EMV are prioritized early in the project’s iterations.

The goal of each iteration should be to progressively ‘de-risk’ the project. EMV can be calculated using the following formula given below.

Risk-Adjusted Product Backlog

The risk involved with a feature is an important factor in prioritizing the product backlog. The product backlog is continually reviewed and adjusted. The customer, along with an analyst, and other team members, prune the backlog. While pruning, impact or risk analysis is the key. Further:

items are broken down
analyzed for their interdependencies
shifted up or down in priority
re-estimated
removed
reallocated to iterations or releases.

This process is a constant process in Agile teams – typically repeating at least once a week. Analyzing the impact of changing requirements should be a routine among successful Agile teams. Product backlog, being a living artifact, proves that the Agile processes automatically take risk factor into consideration and make necessary adjustments continuously.

Risk-Adjusted Product Backlog - Example

Let us look at an example of Risk-Adjusted Prioritized Product Backlog. There are two key risks identified by the project team, And, their EMVs are given below. Notice that the EVM of Risk 1 is greater than Requirement 2 but less than Requirement 1.

Hence, risks should be addressed at the beginning of the project lifecycle, by including the risk responses in the product backlog. By doing so, you can derive the Risk-Adjusted Prioritized Product Backlog, which helps in maximizing the total value proposition over time.

Non - Functional Requirements

Non-functional requirements define how well the system should perform. Product Owners should ensure non-functional requirements are also considered and prioritized in-line with the functional requirements.

Some of the non-functional requirements are security, scalability, performance, robustness, portability, maintainability, reliability, safety, usability, response time, stability, and fault-tolerance. Note that some of the non-functional requirements are global in nature and can be applied across all the requirements, while some are specific to individual requirements.

Prioritization of Non-Functional Requirements

Non-functional requirements should also be prioritized in-line with other functional requirements, as shown in the diagram. Some key points to remember are as follows:

Proactively addressing the non-functional requirement helps in minimizing the probability of project failure.
Non-functional requirements also undergo progressive elaboration and emerge throughout the project lifecycle.
Some of the non-functional requirements are evident at the beginning of the project, however, they need to be actively sought out as the project progresses.
Addressing these requirements helps improve the quality and value of deliverables.
If these requirements are missed or discovered later, it becomes difficult to address them.

Note that the Product Owner needs to ensure that the specialists in these fields are involved while envisioning the product and capturing requirements.

Summary

Let us summarize the topics covered in this lesson:

Present value is the amount of money today, or the current value of a future cash flow. Future value is the amount of money at some future time period.
The thumb rule for decisions is to select the project with higher ROI, IRR, NPV, but lower payback period.
Factors to be considered for prioritization are the financial value of the features, cost of developing the new features, amount and significance of learning and new knowledge gained while developing the features, and amount of risk removed by developing the features.
While planning for an iteration, ‘Must’ requirements should be prioritized followed by the ‘Should’ and ‘Could’ requirements or MoSCoW.
Requirements falling in the Threshold category should be picked up while following the Kano Model.
Risks in Agile projects are managed by associating user stories with risks and ensuring that risks are prioritized early in the project’s iterations.
Non-functional requirements should be actively identified and prioritized to avoid project failures.

Source: https://www.simplilearn.com/value-driven-delivery-part-1-tutorial