PMI-ACP Exam Prep (Part 2 of7): Value-Driven Delivery19 minreadSam Vaghefi

Listen to this post:

This is part 2 of 7 posts on PMI-ACP Exam Prep (link to part 1). In this post,my focus will be on maximizing business value, including prioritization,incremental delivery, testing, and validation.

The reason projects are undertaken is to generate business value, be it toproduce a benefit or improve a service. Delivering business value is a corecomponent of agile methods and it’s embedded in agile values: “workingsoftware over comprehensive documentation.” And agile principles: “Deliverworking software frequently” and “working software is the primary measureof progress.”

There are 2 reasons we need to deliver value early:

1. The longer a project runs, the longer the horizon becomes for risks thatcan reduce value such as failure, decrease benefits, erosion ofopportunities, and so on.

2. Stakeholder satisfaction plays a huge role in project success.

In short, value-driven delivery means making decisions that prioritize thevalue-adding activities and risk-reducing efforts for the project and thenexecuting based on these priorities.

Minimize WasteWasteful activities reduce value. There are 7 wastes to keep in mind andeliminate them when you come across them:

1. Partially done work2. Extra processes3. Extra features4. Task switching5. Waiting6. Motion7. Defects

Assessing Value via Financial MetricsFor business projects, value is commonly estimated using financial metricssuch as ROI, IRR, and NPV. For the purpose of the PMI-ACP exam, you don’tneed to know how to calculate these but you do need to understand what theyare and what they represent and how they differ from one another.

Return on Investment (ROI)

Definition: The ratio of the benefits received from an investment to themoney invested in it, expressed as a percentage.

ROI is used to evaluate the money gained or lost in relation to the moneyinvested in a project. ROI is also often referred to as gain/loss, profit/loss, ornet income/loss. A Project Manager can use the ROI of one or more projectsto determine which project is the better investment. For example, if Project Ahas an ROI of 27%, Project B has an ROI of 25%, and Project C has an ROI of30%; Project C would be the better investment since it has the largest ROI.

Net Present Value (NPV)

Definition: The present value of a revenue stream (income minus costs) overa series of time periods.

Generally, any project that has a positive NPV is a good investment. NPV isused as a capital project financial metric to analyze the profitability of aninvestment at the time of review. It looks at the present values of cash inflowsand the present values of cash outflows resulting in an NPV value. A ProjectManager can compare the NPV value of one or more projects to determinewhich project is a more profitable investment. For example, Project A has anNPV of $2.3M, Project B has an NPV of $2M, and Project C has an NPV of$2.1M. Project A has the greater NPV and is the best investment for theorganization.

The drawback of calculating NPVs is that you have to estimate what inflationand interest rates will be in the future – and those guesses may not turn outto be correct.

Internal Rate of Return (IRR)

IRR is used as a capital project budgeting metric to determine if aninvestment should be made. It looks at the present value of the cash flows ascompared to the initial investment which results in an IRR value. Forexample, if as a Project Manager you need to compare two or more projects todetermine which one would be the better investment for your organizationyou can use IRR to do this. If you are given the IRR for three projects; ProjectA IRR =25%, Project B IRR = 30%, and Project C IRR = 12% you candetermine that Project B is the better investment for the organization becauseit has the largest IRR value.

Earned Value Management

One tool commonly used to track project spending is an S-curve. Theadvantage is that they are simple to interpret and can quickly tell us whetherour project is over or under budget. However, S-curves don’t provide info onthe schedule. Gantt charts can help with figuring out if a project is onschedule or not but there is still a gap and there needs to be a way to combinethe two. Earned value management was created to address this gap. Thisapproach combines spending and schedule data to produce a comprehensiveset of project metrics, including planned value (PV), earned value (EV),schedule variance (SV), cost variance (CV), schedule performance index(SPI), and performance index (CPI).

Pros and Cons of Using EVM for Agile Projects

Earned value compares actual project performance to planned performanceat a particular point in time. The quality of the baseline plan is a critical

success factor in using this approach.

Another caution regarding earned value is that it doesn’t truly indicatewhether the project is successfully delivering value. We may be on budget andon schedule but building a horrible product that the customer does not needor want to use. Simply looking the budget and schedule doesn’t paint theentire picture.

Having said this, one of the key benefits of earned value metrics is that theyare a leading indicator. EVM looks forward, trying to predict completiondates and final costs.

Cost Variance (CV)

CV is the Earned Value minus the Actual Cost (CV=EV-AC) of a project. Thisformula measures the cost performance of a project and looks at whether theproject is on budget or not. In order to calculate CV you need two pieces ofinformation, the earned value and the actual cost of the project. If a CV resultis a negative number the project is over budget, which is bad. If a CV result isa positive number the project is under budget, which is good. If CV is zero,then the project is exactly on budget. For example project A has an earnedvalue of $75.1M and an actual cost of $75.3M. The CV calculation would looklike: CV= $75.1M – $75.3M; resulting in a CV of -$0.2M; this project is overbudget. Another example would be Project B has an earned value of $15Mand an actual cost of $14.5M. The CV calculation would look like: CV=$15M –$14.5M; resulting in a CV of $0.5M; this project is under budget.

Cost Performance Index (CPI)

CPI is Earned Value divided by Actual Cost (CPI=EV / AC). CPI measures thecost performance of a project; is the project budget being spent as planned?In order to calculate CPI you need two pieces of information, the earned valueand the actual cost of the project. There are three possible results when

calculating this: CPI = 1 is good and means funds are being used as planned;CPI >1 is also good and means the funds are being used more efficiently thanplanned; and CPI <1 is bad and means the funds are being overspent.

Schedule Variance (SV)

SV is the Earned Value minus the Planned Value (SV=EV-PV) of a project.This formula measures the schedule performance of a project and looks atwhether the project is behind schedule or ahead of schedule. In order tocalculate SV you need two pieces of information, the earned value and theplanned value of the project. If an SV result is a negative number then theproject is behind schedule, which is bad. If an SV result is a positive numberthen the project is ahead of schedule, which is good. If SV is zero, then theproject is exactly on schedule. For example project A has an earned value of$75.1M and an actual cost of $74.2M. The SV calculation would look like: SV=$75.1M – $74.2M; resulting in a SV of $0.9M; this project is ahead ofschedule.

Schedule Performance Index (SPI)

SPI is Earned Value divided by Planned Value (SPI=EV / PV). This formulameasures the schedule performance of a project, is the project performing asplanned? In order to calculate SPI you need two pieces of information, theearned value and the planned value of the project. There are three possibleresults when using this formula: SPI = 1 is good and shows the project isprogressing as planned; SPI >1 is also good and shows the project isprogressing at a faster rate than planned; and SPI <1 is bad and shows theproject is progressing at a slower rate than planned.

Although for the purpose of the PMI-ACP exam you don’t need to do anycalculations or create S-curves and EVMs, here is a link to a great video onhow to go about it in a project: https://www.youtube.com/watch?v=yDEku2w-2WY

Earned Value Management using an example (agile project)

Key Performance Indicators (KPIs)Rate of progress: How many user stories are you getting completed andaccepted by the product owner per week or month? Agile teams usuallyestimate their work items in story points. So a simple piece of workmight be sized 1 story point and a large work may be sized 8 story pointsand the project’s rate of progress KPI will be expressed as 20 points perweek.Remaining work: How much work is left in the backlog? This is again instory point units. e.g. 400 story points remaining.Likely completion date: We look at how much work there is left to do anddivide it by our current rate of progress. e.g. we are getting 20 storypoints done per week and we have 500 story points in our backlog, ourlikely completion date will be 500/20=25 weeks. Assuming no change inscope or breaks in the schedule (vacations, etc.)Likely costs remaining: This is our burn rate multiplied by the remainingweeks left. Things to consider in burn rate: salary, licenses, training cost,equipment, etc.

Managing RiskTo maximize value, we much minimize risk. The primary tools that agileteams use to manage risk are the risk-adjusted backlog and risk burndowncharts. More on this to come in later posts but basically, these tools allow usto seamlessly integrate and prioritize our risk response actions into ourbacklog of development work.

Prioritizing Valueprioritization is a fundamental agile process. if you recall in my previous postI mentioned that agile teams must welcome changing requirements, even latein the game. You may say this sounds great but how do you manage it? Well,you need to keep the customer in the loop every step of the way. If at the endof each iteration or sprint you sit with the customer and review the work thathas been done and look at the backlog and reconfirm prioritization of workand user stories then new requirements shouldn’t affect you much as therequirements will come at the right time. Asking questions such as “hasanything changed?” and “do we still want to move forward with feature Bnext?”

MoSCoWThe MoSCoW prioritization scheme, which was popularized by DSDM,derives its name from the first letter of the following labels:

Must have: Requirements and features that are fundamental to thesystem. Without them, the system will not work or have no value.Should have: These features are important and needed for the system towork correctly. If they are not there, then the workaround will likely becostly or cumbersome.Could have: Features that are useful net additions that add tangiblevalue.

Would like to have, but not this time: These are features that are dulynoted but will most likely not make the cut.

Monopoly Money

In this approach, you give the stakeholders Monopoly money equal to theamount of the project budget and ask them to distribute the funds amongstthe system features. This approach is useful for identifying the generalpriority of system requirements. This technique is most effective when it’slimited to prioritizing business features.

100-Point Method

Stakeholders are given 100 points each to distribute to product features andthey can distribute it any way they like. e.g. 30 points here, 15 points there or100pointst to a single feature that’s the only priority they have.

Dot Voting or Multi-Voting

Similar to Monopoly Money method shared above but with a small difference.Each stakeholder is given a predetermined number of dots or stars orcheckmarks to distribute between the risk identified or features that need tobe prioritized. Say you do a brainstorming exercise and come up with 40different risks or features. You would typically give out 20% of the numberfeatures identified as points to each stakeholder (40×20%=8) and have thestakeholders distribute the point/dots/stars among the features or risksidentified.

Kano Analysis

Kano says that a product or service is about much more than justfunctionality. It is also about customers’ emotions. For example, allcustomers who buy a new car expect it to stop when they hit the brakes, butmany will be delighted by its voice-activated parking-assist system.

The model encourages you to think about how your products relate to yourcustomers’ needs while moving from a “more is always better” approachto product development to a “less is more” approach.

Constantly introducing new features to a product can be expensive and mayjust add to its complexity without boosting customer satisfaction. On theother hand, adding one particularly attractive feature could delight customersand increase sales without costing significantly more.

For more on how Kano works have a look at thisarticle: https://www.mindtools.com/pages/article/newCT_97.htm

Delivering IncrementallyIncremental delivery is another way that agile methods optimize the deliveryof value. Incremental delivery reduces the amount of rework by finding issuesearlier and thereby contributing to the delivery of value on the project. Anexample of incremental delivery is having the plain vanilla version onproduction and the team working on features and once each feature is done,it sent to the test environment for verification before it’s past to production.You can also bypass testing and send the new features to production but thecost associated with fixing bugs before testing and in production is usuallyhigher than fixing them in the test environment.

Minimal Viable Product (MVP)MVP refers to a package of functionality that is complete enough to be usefulto the end user or the market, yet still small enough that does not representthe entire project. Keep in mind that the functionalities included need to becomplete. e.g. in case of an MVP for a phone, making calls may be the onlyfeature we decide to have. This feature needs to be working properly andcompletely. MVP is more of a process. The goal is to receive feedback andadd/remove more feature as you go along.

Cumulative Flow Diagrams (CFDs)CFDs are valuable tools for tracking and forecasting the delivery of value. Youcan gain insight into project issues, cycle times and likely completion dates.Basically, they are stacked area graphs that depict the features that are inprogress, remaining, and completed over time. The video below is a goodtutorial on how you can create and readCFDs: https://youtu.be/_SnFCIZTs1k

PMI-ACP : Cumulative Flow Diagram : Lean : Lesson 10

Here is another great article that can help you understandCFDs: http://brodzinski.com/2013/07/cumulative-flow-diagram.html

What’s important is that you need to know that the bottleneck is the activitythat lies below the widening band. The widening band is the feeding activity,not the problem activity. Once you know where the problem is, you can startaddressing the issue by applying the 5 focusing steps of Goldratt’s Theory ofConstraints:

1. Identify the constraint

2. Exploit the constraint3. Subordinate all other processes to exploit the constraint4. If after step 2 and 3 are done, more capacity is needed to meet demand,

elevate the constraint5. If the constraint has not moved, go back to step 1, but don’t let inertia

(complacency) become the system’s constraint

Agile ContractsThere are a few ways you can create contracts for your agile project.

DSDM Contract

This contract focuses on work being “fit for business purpose” and passingtest, rather than matching a specification. Usually used in the UK and someareas in Europe.

Money for Nothing and Change for Free

Money for nothing and Changes for free is a clause that is applied to astandard Fixed Price contract. As this type of contract foster collaborationbetween the supplier and the customer, and collaboration is the key tosuccess in agile over contract negotiations (Agile Manifesto). Where Risk isshared between two parties and it’s a win-win situation.

The contract needs to be set up in Fixed Price and add the “Money forNothing and Changes for Free” clause.

1. The customer may cancel the project after any Sprint by paying 20% ofthe remaining contract fee.

1. Supplier gets 20% for the work not done2. When the client met the ROI cut off they do not need to continue

with the project and have unnecessary features.2. The customer can add new User Stories, Story Points or Features during

any Sprint.3. The customer needs to agree on prioritizing the backlog in each iteration.4. The customer must agree that some work will not be done in case the

clause is used.5. Both the parties need to agree on the work items that are estimated,

sized.

When the Contract is reversed?

1. When the customer is not prioritizing the backlog appropriately2. The customer does not operate with the scrum rules

Mony for nothing allows the customer to terminate the project early whenthey feel there is no longer sufficient ROI in the backlog to warrant furtheriterations.

Graduated Fixed-Price Contract

With this kind of contract, both parties share some of the risk and rewardassociated with schedule variance. See table below:

Graduated Fixed-Price Contract

Fixed Price Work Packages

Fixed-price work packages mitigate the risk of underestimating oroverestimating a chunk of work by reducing the scope and cost involved inthe work being estimated. This also allows the customer to reprioritize the

remaining work based on evolving costs. And for the supplier to update theircosts as new details emerge, removing the need for the supplier to buildexcess contingency fund into the project cost.

Customized Contracts

Basically, you are creating a contract by combing all type of contractsdiscussed above to meet your need. On agile projects, procurement hasalways been particularly challenging since the details of the scope can’t befully defined early in the project. The success of the project ultimatelydepends on the level of collaboration between the seller and the customer.

Verifying and Validating Value

Verifying and Validating Value

What one person describes is often very different from how the listenerinterprets it. This semantic gap is called the “gulf of evaluation.” Onmanufacturing projects the work is visible, tangible, and familiar; and so thegulf is small and quickly crossed. in contrast on knowledge work projects, thework is often invisible, intangible, and new – this leads to a bigger gulf andmisunderstanding become more common. This is why agile uses frequent andregular testing, checkpoints, and reviews to address problems before they getbigger. This process is known as frequent verification and validation.

Frequent Verification and Validation

Exploratory and Usability Testing

Exploratory Testing: The purpose of this type of testing is to uncoverunexpected behaviors and discover issues. This is a complement to thescripted testing and not a replacement. The goal is to find systemboundaries and unanticipated behavior outside of the regular functionsthat could be tested.Usability Testing: This type of testing attempts to answer thequestion, “how will an end-user respond to the system under realisticconditions?” The goal is to diagnose how easy it is to use the system.typically involves observing users as they interact with the system for thefirst time. Data may be gathered using videotaping, eye-tracking tools,and performing post-test interviews.

Great article on functional and nonfunctionalrequirements: https://www.altexsoft.com/blog/business/functional-and-non-functional-requirements-specification-and-types/

Continuous Integration

Continuous integration is a practice used by software devs to frequentlyincorporate new and changed code into their project code repository. Thishelps minimize the integration problems that result from multiple peoplemaking incompatible changes to the same code base.

Pros and Cons of Continuous Integration

Pros:

The team receives an early warning of broken, conflicting, orincompatible code.Integration problems are fixed as they occur, rather than as the releasedate approaches.The team receives immediate feedback on the system-wide impacts ofthe code they are writing.The practice ensures frequent unit testing of the code – alerting the team

of issues sooner than later.If a problem is found the code can be reverted back.

Cons:

Setup time can be long.Cost could be high.Time is required to build a suite of automated, comprehensive tests thatrun whenever code is checked-in.

Test-Driven Development (TDD)

The philosophy behind TDD is that tests should be written before code iswritten. So with TDD, developers begin a cycle of writing code and runningthe test until the code passes all the tests. Then, if necessary, they clean upthe design to make it easier to understand and maintain without changing thecode’s behavior. This last process is called “refactoring.”

Pros and Cons of TDD

Pros:

Makes coders think of functionality first before implementationEnsures we at least have some tests in placeHelps us catch defects earlyHelps with writing systems in a small, modular, flexible, and extendableway

Cons:

The same coder writing the test would result in misinterpretation of therequirementsSome types of functionality, such as user interfaces, are difficult or time-consuming to reliably test via unit tests

As the project grows and changes, the sustainment load for test scriptsgoes upAs people see a higher number of passing test, they may get a false senseof security about the code quality

Acceptance Test-Driven Development (ATDD)

ATDD moves the testing focus from the code to the business requirements. Aswith TDD, the tests are created before work starts on the code, and these testsrepresent how the functionality is expected to behave at an acceptance testlevel. ATDD has 4 steps: Discuss, Distill, Develop, and Demo.

Acceptance Test-Driven Development (ATDD)

Discuss the requirements: During the planning meeting, we ask theproduct owner or the customer questions that are designed to gatheracceptance criteria.Distill tests in a framework-friendly format: We get the testsready to be entered in our acceptance test tool. Usually in a table format.

Develop the code and hood up the tests: During development, thetests are hooked up to the code and the acceptance test are run. initiallytest fail as they can’t find the code corresponding to the test item but ascoding is completed we should see successful tests run.Demo: The team does exploratory testing using the automatedacceptance testing scripts and demos the software.

When we combine the tasks of defining acceptance criteria and discussingrequirements, we are forced to come to a concrete agreement about the exactbehavior the software should exhibit. In a way, this approach enforces thediscussion of the “definition of done” at a very granular level for eachrequirement.