• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Kanban for Fixed Price Projects
 

Kanban for Fixed Price Projects

on

  • 474 views

This slidedeck explains how a Fixed Price Project that adopts Kanban can do Capacity Planning, assess Scope Changes and do Budget Tracking

This slidedeck explains how a Fixed Price Project that adopts Kanban can do Capacity Planning, assess Scope Changes and do Budget Tracking

Statistics

Views

Total Views
474
Views on SlideShare
326
Embed Views
148

Actions

Likes
1
Downloads
0
Comments
0

4 Embeds 148

http://present.agileindia.org 143
http://confengine.com 3
https://m.facebook.com&_=1394463224636 HTTP 1
https://www.facebook.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Kanban for Fixed Price Projects Kanban for Fixed Price Projects Presentation Transcript

    • ADAPTING KANBAN TO FIXED SIZE PROJECTS Sudipta Lahiri9/23/2013 1
    • Fixed price projects... 9/23/2013 2  They have been estimated, scheduled and planned with a certain in the pre-sales stage  Once you get the PO, you kick off the project with a defined scope, budget and timeline  Further, the eco-system is not always fully agile:  There is a need for:  “Dynamic” resource capacity planning  Budget tracking and monitoring  Keeping the Stakeholders aware of whether the overall scope is on track to be delivered in the committed timeline Presales to SOW • Waterfall Development to Delivery • Agile Delivery to Acceptance • Waterfall
    • The Kanban Method 9/23/2013 3 Visualization using a Project Board - Map your value stream - Show all work with different swim lanes Implement WIP to: -Induce Flow -Reduce multi-tasking Establish Pull -Uniform Cadence -Greater commitment Define explicit policies - DOD
    • CFDs 9/23/2013 4 Ref: http://brodzinski.com/2013/07/cumulative-flow-diagram.html The slope of this line gives you the Throughput; rate at which cards are getting completed.
    • Changing focus with Agile/Lean... Instead of asking... Ask... What resources are available? Which team is ready to pull this work into their backlog? For an enterprise view of my resources... For an enterprise view of my work execution, across projects What is our (enterprise) capacity in person months? What is our (enterprise) throughput/velocity in points? How many people does this project team need? Am I getting enough throughput? Incremental people != Incremental throughput Discouraging Scope Change Recognize scope change as an imperative and communicate with the customer on impact/timeline 5 9/23/2013
    • Agile systems 9/23/20136  Agile extrapolates past throughput to predict future  Inherently, they assume stable teams  They assume CFT teams  However, in service organizations, resource allocations keep changing (# of people, experience of people)  Solution: Applying EVM to Agile/Lean methods Traditional EVM Approach Agile Analytics Expanded Agile Analytics
    • Here is what we do... Define a resource plan for the MMF scope Use this as the basis for EVM Track velocity/ throughput information Re-calibrate capacity to delivery date Allow for scope changes to happen 7 9/23/2013 Planning Phase Activities Execution Phase Activities
    • Original budget 48.57 MM 1020 MD Original timeline 10 Original Wk1 Wk2 Wk3 Wk4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10 Productivity 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% Overall Development Resources 14 14 18.5 18.5 18.5 18.5 18.5 18.5 18.5 18.5 Overall ST Resources 3 3 3 3 3 3 3 3 3 3 Overall Development Resources 14 14 18.5 18.5 16.5 18.5 18.5 18.5 18.5 18.5 Overall ST Resources 3 3 3 3 3 3 3 3 3 3 Technical Requirement 1 2 2 4 4 2 2 MMF 1 User Story 1.1 2 2 4 1 1 User Story 1.2 2 2 2 2 2 User Story 1.3 1 1 1 1 1 ST Resources 1.5 1.5 1.5 1 1 MMF2 User Story 2.1 2 2 2 1 1 User Story 2.2 2 2 2 2 2 User Story 2.3 1 1 1.5 1.5 1.5 ST Resources 1.5 1.5 1.5 1 1 MMF3 User Story 3.1 2 2 2 2 2 2 2 ST Resources 1 1 1 1 MMF4 User Story 4.1 2 2 4 5 6 6 6 User Story 4.2 2 2 2 2 2 User Story 4.3 1.5 1.5 1.5 1.5 1.5 ST Resources 1 1 1.5 1.5 1.5 MMF5 User Story 5.1 2 2 4 5 6 6 6 User Story 5.2 2 2 2 2 2 User Story 5.3 1 1 1 1 1 ST Resources 1 1 1.5 1.5 1.5 Total (Current) 17 17 21.5 21.5 19.5 21.5 21.5 21.5 21.5 21.5 Planned value 85 85 107.5 107.5 97.5 107.5 107.5 107.5 107.5 107.5 Cumm. Original Plan Value 85 170 278 385 483 590 698 805 913 1020 Weeks You would do something like this...8 Original Wk1 Wk2 Wk3 Wk4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10 Overall Development Resources 14 14 18.5 18.5 16.5 18.5 18.5 18.5 18.5 18.5 Overall ST Resources 3 3 3 3 3 3 3 3 3 3 Total (Current) 17 17 21.5 21.5 19.5 21.5 21.5 21.5 21.5 21.5 Cumm. Original Plan Value 85 170 278 385 483 590 698 805 913 1020 0 200 400 600 800 1000 1200 ManDays Planned Value
    • Making it a little more practical...  Positive/negative factors on productivity:  Resource ramp-up, skill training, domain training, etc.  Team decides how to calibrate productivity across time  Benefits:  PV: Planned Value  PV reflects reality  S-curve in PV 0 200 400 600 800 1000 1200 ManDays Planned Value Original Wk1 Wk2 Wk3 Wk4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10 Productivity 25% 50% 75% 100% 125% 125% 125% 125% 112% 112% Development Res. 14 14 18.5 18.5 18.5 18.5 18.5 18.5 18.5 18.5 ST res. 3 3 3 3 3 3 3 3 3 3 Total (Current) 4.25 8.5 16.13 21.5 26.88 26.88 26.88 26.88 24.08 24.08 Cumm. Original Plan Value 21 64 144 252 386 521 655 789 910 1030 9 9/23/2013
    • Using AgileEVM for Planning 9/23/2013 10  AgileEVM approach  Defined by Tamara Suleiman and 2 others  An approach for EVM to Agile projects  Sound approach but we used a simpler template for the following reasons:  Planned Value uniformly spread across project duration  Accommodates scope change but does not accommodate for a schedule change in the middle of the project  Hard to read and interpret  Adoption is tentative  EVM modelling is available in some Agile tools today
    • A little more complexity... with an example  Estimated scope of 100mm; available capacity: 80mm  10 calendar months fixed timeline  Plan for initial ramp-up 11 9/23/2013
    •  Scenario I:  Dev Manager believes than he/she will deliver 100mm with 80mm of capacity  Total PV at proj completion (EAC) = 100mm  Planned value distribution based on resource allocation distribution  Summary:  SV measured on PV = 100mm  CV measured on PV = 80mm  Scenario II:  Dev Manager believes that he/she can deliver only 90mm of scope with 80mm of capacity  Total PV at project completion (EAC) = 90pm  Communicate to CDU for remaining10mm  Planned value distribution based on resource allocation distribution + uniform distribution of gap (10pm)  This is because you want to plan for 90pm though the resource allocation distribution is for 80mm  Summary:  SV measured on PV = 90mm  CV measured on PV = 80mm12 9/23/2013
    • Budget Tracking13 9/23/2013
    • The approach... 9/23/2013 14  On a weekly basis, EV is computed using AgileEVM approach and plotted against the PV  To track EV:  Most Kanban tools dump their Board data to an Excel  Gives card wise, stage wise breakup  Two alternatives:  You can give a certain % completion to each stage of the value stream completed on their estimated size  For example: Requirement done is 20% value earned, Design completed is 15% value earned.... OR  Stick to Agile emphasis on “working software” and give 100% value earned when a card is archived  Aggregate across the Board weekly and you will get the EV trend  To track Actual Cost, get a weekly resource allocation data
    • You will get a plot like this... 9/23/2013 15 20 40 95 149 204 258 313 418 523 628 733 919 1104 1290 1475 1546 1616 1686 1757 1827 0 0 0 50 80 100 150 200 308 350 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Planned Value Earned Value Actual Cost Schedule Variance Cost Variance
    • Accepting change is “key” to Agile thinking Challenge: In fixed projects, how done one handle timeline and budget? Impacting Scope Change16 9/23/2013
    • The Approach...  CFD Shows the project end date for revised scope @ current throughput  Reallocate capacity to match required throughput 17 9/23/2013
    • Let us understand this with an example...  Consider the following Board.... 18 9/23/2013 XXXXXXXXXXXXXXXXX XXXXXXXXXX XXX XXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX
    • Current throughput  Assume that the team is performing at the Required Burn-up rate 19 9/23/2013
    • Now, evaluate Scope change...  120md of work has been added and updated in the Backlog (highligted in red) 20 9/23/2013 XXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXX
    • Project the CFD again...  Required Throughput increases from 16.13/day to 18.09/day to meet the same timeline  An increase of 12% in addition 21 9/23/2013
    • An iterative process with stakeholders to evaluate options and converge  Option I:  Increase capacity by 12-15% to reach desired throughput  Factor in an increase in overhead as team size increases  Option II:  Keep the same capacity but push back the timeline by 12-15%  Option III  Reprioritize scope to keep the total scope largely unchanged but deliver to the revised timeline  Option IV  A combination of all of above for overall stakeholder agreement  Partial capacity increase + partial extension in timeline + reprioritizing scope  For each option, use CFD projection to evaluate the final result 22 9/23/2013
    • Step 3: Adjust PV for revised plan  For small changes in resource availability/scope, Planned Value need not change  Small: < 10% estimate variation  For significant changes, rework Planned Value as for modified Resource Plan 0 200 400 600 800 1000 1200 1400 Cumm. Original Plan Value Cumm. Revised Plan Value 23 Revised Wk1 Wk2 Wk3 Wk4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10 Wk11 Wk12 Productivity 25% 50% 75% 100% 125% 125% 125% 125% 112% 112% 112% 112% Development Res. 14 14 15 15 15 18 18 18 18 12 12 12 ST res. 3 3 3 3 4 4 4 4 4 4 4 4 Total (Current) 4.25 8.5 13.5 18 23.75 27.5 27.5 27.5 24.64 17.92 17.92 17.92 Scope Addition (in mm) 5 Cumm. Revised Plan Value 21.3 63.8 131.3 221.3 340 477.5 615 752.5 875.7 965.3 1054.9 1144.5 9/23/2013
    • A quick re-cap 9/23/2013 24  Fixed price projects have characteristics that need us to go beyond just Velocity/Throughput tracking  Use AgileEVM thinking to track variance between planned progress and actual  Use CFD to keep track of whether the team is delivering at the desired Throughput  When scope changes, evaluate multiple options using the Throughput and iterate with stakeholders  The same approach would apply to SCRUM projects also
    • Thank you for your time today...  For any questions or clarifications, you can reach me at:  @sudiptal  slahiri@digite.com  I share my experiences at:  http://www.swiftkanban.com/ blog/sudipta-lahiri  http://sudi- thoughts.blogspot.in/  Join Limited WIP Society Bangalore/Pune Chapters 9/23/2013 25