Agile Finance for Project Success
•Download as PPTX, PDF•
0 likes•212 views
Agile frameworks (Scrum, Kanban) do not effectively address the specifics of how financial targets are set and achieved. This presentation proposes a specific set of activities to address these gaps and improve the effectiveness of business agility efforts.
Recommended
Recommended
More Related Content
Similar to Agile Finance for Project Success
Similar to Agile Finance for Project Success (20)
Recently uploaded
Recently uploaded (20)
Agile Finance for Project Success
- 1. Agile Financial Operations Stephen Milligan CPA PMP CSP
- 3. Where do these functions currently reside in Agile environments? Finance Department Project Managers/PMO Line Management
- 4. Impacts Continuation of Command and Control environment Higher Costs Mixed messages to teams?
- 5. Agile Financial Hierarchy Establish and Align Organizational Objectives and Key Results Define Deliverables/Targets Establish Delivery Team and Preliminary Budget Build Prioritized Product Backlog Model Value Stream(s) Create Forecasting Models Develop Release Plan Agile Delivery
- 6. Establish and Align Organizational Objectives and Key Results (OKR) OKR (Objectives and Key Results) is a goal system used by Google and others. OKRs are frequently set, tracked, and re- evaluated – usually quarterly. OKRs target bold, ambitious goals enabling teams to set challenging goals. A proper goal has to describe both what you will achieve and how you are going to measure its achievement.
- 7. OKRS Objective: Increase user base Key Results: •Increase per day views to 1,000 •Total monthly unique views 45,000 Objective: Get validation that software is useful from users Key Results: ● Increase upgrade conversion rate to 10% ● 70% of newly acquired users answer survey questions Objective: Improve infrastructure Key Results: ● Automate builds using Jenkins functionality O Reduce time to deploy by 50%
- 8. Identify Deliverables/Targets • Work Breakdown Structure – defines what must be created • WBS Dictionary – documents the detailed definition of done for deliverables • Options should be documented if possible • RACI information should be recorded for each deliverable
- 9. RACI • Who is Responsible for this deliverable? • Who is Accountable for this deliverable? • Who should be consulted regarding this deliverable? • Who should be informed regarding this deliverable?
- 10. Work Breakdown for Web Project Deliverable Feature Value Acceptance Criteria RACI Need By Date Product Backlog Code Registration Page 100,000.00$ Create User ID and Password A1 Facebook Option A2 Google Option A3 Accept Payments 200,000.00$ Visa, Master Card, AMEX B1 PCI Compliance B2 Secure storage B3 Support scanners for attendance 50,000.00$ Physical scanner C1 Cell phone QR scanner C2 WBS Dictionary
- 11. Set Team and Initial Budget Determine which team member roles will be needed to create deliverables. 01 Understand team run rate (how much the team will cost per unit of time) 02 Associate funding with activity levels 03 Conduct interim reviews and adjust accordingly 04
- 12. Element Data Project name: Project name Project#: xxxxx Year: 2013 Expense Capital Requested 0 0 Approved 0 0 Name Function Rate Resource 1: Name 1 Function 100 Resource 2: Name 2 Function 100 Resource 3: Name 3 Function 100 Resource 4: Name 4 Function 100 Resource 5: Name 5 Function 100 Resource 6: Name 6 Function 100 Resource 7: Name 7 Function 100 Resource 8: Name 8 Function 100 Resource 9: Name 9 Function 100 Resource 10: Name 10 Function 100 Resource 11: Name 11 Function 100 Sample blank team budget spreadsheet
- 13. Establish Prioritized Product Backlog Execution teams lead backlog creation Backlog items are keyed to deliverables Compliance functions are engaged! PO plays traditional role in prioritization
- 14. The World We Live In V - volatile U - uncertain C - complex A – ambiguous
- 15. Model Value Stream and Create Forecasts Create a Business Process Model 1 Document value stream(s) 2 Identify where variation may occur 3 Use this model to forecast dates and costs 4
- 16. Process Model Based Forecast Examples Purchase Price + Sales Price Net Profit Fixed 0.60$ 0.03$ 1.00$ 0.37$ Variable 0.691$ 0.044$ 0.982$ 0.247$ Price Range .55 to .70 .02 to .045 .92 to 1.05 Monte Carlo 0.646$ 0.033$ 1.037$ 0.358$ Mean 0.345$ 0.653$ 0.040$ 1.041$ 0.348$ 0.690$ 0.040$ 1.011$ 0.281$ St Dev 0.049 0.567$ 0.030$ 0.994$ 0.397$ 0.632$ 0.044$ 0.938$ 0.262$ Min 0.262$ 0.575$ 0.042$ 1.031$ 0.413$ 0.634$ 0.030$ 0.982$ 0.318$ Max 0.433$ 0.568$ 0.038$ 1.038$ 0.433$ 0.681$ 0.042$ 1.037$ 0.314$ 0.654$ 0.028$ 0.992$ 0.310$ 0.625$ 0.022$ 1.009$ 0.362$ 0.626$ 0.033$ 1.004$ 0.345$ Buy Apples Sell Apples Profit Transportation Cost Statistics $- $0.050 $0.100 $0.150 $0.200 $0.250 $0.300 $0.350 $0.400 $0.450 $0.500 0 2 4 6 8 10 12 14 Scatter Chart
- 17. Value Stream BA prep user story Refine with team Select for Sprint backlog Develop story Test story Bug freq Bug fix Deploy and Integrate Bug fix Deploy and Release working day Total elapsed time Range .2 to .5 days 0.0312 to 0.0625 1 to 5 days 1 to 5 days 1 to 2 days 20 to 50% .5 to 1 day .2 to .3 .5 to 1 day .1 to .25 5 to 7 hours Estimate 0.45 0.04 2.17 1.33 1.86 0.31 0.94 0.24 0.87 0.11 5.79 10.15 Min 6.90 0.29 0.05 1.18 2.55 1.53 0.24 0.81 0.23 0.67 0.13 6.15 8.87 Max 16.66 0.32 0.05 2.60 1.19 1.37 0.22 0.72 0.23 0.84 0.25 5.50 10.19 Mean 12.36 0.41 0.06 3.04 2.06 1.60 0.41 0.71 0.28 0.63 0.13 6.21 10.95 Std dev 2.54 0.24 0.03 2.70 4.36 1.82 0.43 0.54 0.26 0.62 0.19 6.06 13.81 0.24 0.03 4.06 3.86 1.57 0.23 0.65 0.28 0.53 0.14 6.11 14.21 0.48 0.06 2.54 1.69 1.45 0.21 0.71 0.27 0.86 0.18 5.59 10.98 0.42 0.04 2.50 3.30 1.36 0.39 0.74 0.21 0.61 0.24 5.81 12.38 0.31 0.04 2.55 4.17 1.81 0.21 0.85 0.20 0.99 0.24 5.69 14.77 0.42 0.04 4.68 4.85 1.64 0.23 0.71 0.27 0.92 0.14 6.49 16.18 0.44 0.04 1.50 2.93 1.84 0.23 0.82 0.29 0.67 0.22 5.34 12.16 0.28 0.06 1.77 4.46 1.01 0.21 0.64 0.22 0.64 0.17 5.81 12.05 0.41 0.03 2.26 1.03 1.02 0.26 0.68 0.21 0.65 0.15 6.88 6.90 0.48 0.05 3.73 4.95 1.27 0.45 0.94 0.23 0.89 0.19 6.26 15.60 0.50 0.03 3.76 3.58 1.92 0.42 0.98 0.25 0.77 0.21 5.49 16.66 0.40 0.06 3.13 3.15 1.01 0.45 0.54 0.28 0.69 0.21 6.25 11.74 0.20 0.05 3.71 4.43 1.31 0.40 0.89 0.26 0.86 0.23 6.75 13.51 0.30 0.05 2.06 2.17 1.24 0.42 0.57 0.25 0.61 0.11 5.22 10.77 0.28 0.05 1.69 1.85 1.92 0.47 0.75 0.24 0.77 0.16 6.49 9.01 0.42 0.04 1.08 4.99 1.40 0.47 0.54 0.25 0.74 0.18 5.58 13.42 0.29 0.03 3.40 4.64 1.75 0.31 0.52 0.21 0.56 0.19 5.91 15.22 Forecast without Dev Ops
- 18. 0 1 2 3 4 5 6 7 8 7.9 to 8.9 9 to 9.99 10 to 10.99 11 to 11.99 12 to 12.99 13 to 13.99 14 to 14.99 15 to 15.99 16 to 16.99 17 to 17.99 18 to 18.99 Story Completion Forecast How Many Days Will It Take to Complete Each User story (per FTE)
- 19. Plans based on averages are wrong on average Value stream mapping is a lean management tool that helps visualize the steps needed to take from product creation to delivering it to the end-customer. Schedule management activities should focus on identifying and removing lean waste (over- processing, overproduction, waiting, inventory, rework, movement and transportation) Plans should be based on the probable range of outcomes.
- 20. Good Reference
- 21. Develop Release Plan Use prioritized product backlog and forecast results to create a realistic release plan.
- 22. Agile Delivery Team creates estimates Definition of done includes compliance Agile EVM used to track results
- 23. Agile EVM • Agile Earned Value management • Analysis combines Deliverables (WBS), Product Backlog and, Release Plan • Release plan documents the order in which deliverables are expected and thereby Planned Value • Value is earned when Deliverables/Features are completed according to the definition of done. • The Release burn down/up is used to identify potential schedule variance
- 24. Sprint Completed Earned Value Number of Sprints x Run Rate (AC) Cost Variance Schedule Variance Deliverable Feature Value Acceptance Criteria RACI Need By Date Product Backlog Code Registration Page 100,000.00$ 5/1/2019 Create User ID and Password 50000 A1 4 50,000$ 44,000$ 6,000$ Facebook Option 30000 A2 6 30,000$ 22,000$ 8,000$ Google Option 20000 A3 8 20,000$ 22,000$ (2,000)$ Accept Payments 200,000.00$ 7/1/2019 Visa, Master Card, AMEX 100000 B1 14 100,000$ 110,400$ (10,400)$ PCI Compliance 55000 B2 17 55,000$ 55,200$ (200)$ Secure storage 45000 B3 Support scanners for attendance 50,000.00$ 9/30/2019 Physical scanner 25000 C1 Cell phone QR scanner 25000 C2 Team run rate per 2 week Sprint 11,000$ 4 Members are added to team after Sprint 8 18,400$ 255,000$ 1,400$ WBS Dictionary Earned Value Analysis for Web Project
- 25. Important Required Changes • Agile team participation begins in the budget process • PO participates in project/product inception phase • Deliverables identified and documented up front • Forecasts are based on business process models • Compliance is engaged early in the process • Agile EVM is used to track/report on project
Editor's Notes
- Agile delivery frameworks often do not address business case development, project initiation, performance monitoring and external reporting or, internal controls. This presentation will suggest a framework that would bridge these gaps and improve the effectiveness of your business agility efforts.
- What goals or outcomes are important to an organization and which units should be involved in their delivery? What specific deliverables need to be created to achieve organizational goals? Where does the funding for agile teams come from and who decides how much is allocated to each team? How do we measure and report the results of operations in a manner acceptable to all stakeholders?
- These players oversee agile delivery teams in many organizations and there is no simple option to do without them or simply absorb them into agile teams.
- As a result, many agile teams are faced with a continued command and control environment (imposed by governance), higher costs due to vertical infrastructure and stress (usually between project/program management and agile teams).
- This hierarchy is proposed as a way forward that will build bridges between agile teams and critical supporting business functions.
- The first stage involves the establishment of high level organizational objectives along with specific measurements that will be used to determine if they have been met. It is also important that these objectives be aligned across the organization to ensure that no conflicting objectives are pursued.
- These are example objectives and associated key results. Can you suggest any ways they could be improved?
- The next stage involves clearly identifying what needs to be created, what acceptance criteria must be met for each deliverable, what value is associated with each deliverable by the organization. Note: the value to the organization is the sum of all future benefits expected to be realized by the organization as a result of this deliverable’s creation. It is not the amount of budget allocated to the creation of this product. In addition, who is to be responsible, accountable, consulted or informed should also be defined and documented for each deliverable.
- In agile environments, each team is usually responsible for the deliverables they create. But who takes the lead if the work of multiple teams must be integrated into a single product or deliverable? Who is ultimately accountable for the success or failure of an initiative?
- Here is a simple work breakdown structure for a web application. Value assessments can be maintained at the summary level (shown) or broken down to lower levels of detail as required. All acceptance criteria may not be known initially but should be added to the WBS after the product backlog has been created and before work begins on a feature. Need by dates are supplied by the customer and are independent of other estimates or forecasts.
- Now that what must be built has been identified, it is time to identify the team(s) that will create the deliverables, estimate how much they will cost per unit of time (run rate) and, what percentage of their time will be devoted to the creation of deliverables (ideally 100%).
- Here is an example spreadsheet that could be used to identify roles and establish a preliminary team budget. Note: this exercise is focused only on people related costs because they usually make up the most significant portion of development costs and drive the team run-rate.
- Once the team has been established they can work with the product owner and other contributors to develop a product backlog. The product backlog is a prioritized depiction of what must be done to deliver the product. Backlog items will likely have a many to one relationship with WBS deliverables and should be cross referenced in a way that allows all parties to understand when a deliverable has been completed.
- If we are not careful, this is where we can get into trouble. Some would divide the backlog by some measure of velocity and forecast release dates and other milestones. We live in the VUCA world, so we need to take some additional steps to have the best chance of success in our endevours.
- The next thing we need to do is model our existing business process. This is not the process we hope to have – one push updates, seamless DevOps, but whatever we are doing at the moment. We then review how each value stream flows through the process, identifying where variation may occur. From this analysis, we build a forecasting model which will generate a range of time and expense estimates for our project/product.
- Example 1 is a simple model consisting of three variable nodes. Random numbers are used to vary each measure within it’s assumed range. The plan assuming no variation yielded a forecast of 37 cents per apple profit. The model based on multiple instances of variation based on ranges indicated the 80% of the time, our per apple revenue would be 35 cents plus or minus 5 cents.
- This is a somewhat more involved model for the completion of a user story in an organization that has not implemented Dev Ops. In this model, user stories take more than 12 days on average to complete. If the team is using Scrum and two week sprints (10 working days) they are almost certain to carry over incomplete work from sprint to sprint. Have you seen anything like this in your organization?
- This is the output from a run of the preceding model expressed as a set of bar graphs. Sometimes stories are completed in less than the average time required but sometime they take significantly longer. What can be done to make time to complete more consistent?
- Value stream mapping and lean waste elimination could help. The teams delivery process should be analyzed to determine where improvements can be made.
- This book was written by some of our colleges and is an excellent guide to using lean principles to improve business processes and the flow of work.
- After performing and initial round of process improvement, the prioritized backlog and team velocity can be used to develop a release plan with milestones for significant deliverables. This plan would be reviewed at the end of each development iteration and action taken via retrospective to ensure velocity targets are met (and improved if possible)
- The teams follow standard agile frameworks to complete user stories and tasks. Care should be taken to ensure that all compliance requirements are included in the definition of done. At the end of each iteration the team will used agile earned value measurement to track and report progress outside the team.
- Agile EVM uses the output of the preceding stages to track and report results.
- This project kicked off the second week of January. Two features were completed before May 1 at a cost $14,000 less than budget (value = budget in this case). The project still have a favorable cost variance of $12,000 when the Google Option was completed, however, the schedule variance was switched to red because the deliverable was not completed timely. A decision was made to increase the size of the team to improve schedule performance. The result was a narrowing of the favorable cost variance to $1,400 and still behind schedule. Can you predict how the project will finish? What changes would you have made?
- To recap some of the changes that are included in this presentation.
- Thanks for your participation! If you have questions or want to learn more – reach out to me at steve@agilious.com or call me at +1 301-526-6436.