How one project fell down, got up and ultimately succeeded; a "real" case study.
“As a..I want..so I can...” these words are the basis of an Agile User story and were designed to facilitate communication leading to great software. This presentation will explore some advantages and limits to using the Agile approach to software development. We will see how the user stories for a Medical Billing and Payroll system changed over time and how these changes illustrate some of the underlying issues and challenges faced in many software development projects. Once identified; approaches to overcoming these challenges and issues will be examined for efficacy and limitation all within the framework of the Agile Methodology. Speaker : Josh Cowan has worked with companies in the for-profit, non-profit and public sectors throughout Canada and the U.S. With 14 years of experience with administrative software including; medical billing, accounting, payroll and budgeting systems. Josh has worked on the sales, purchasing, design, implementation, and modification of administrative software systems. In addition to software, Josh brings years of experience as a performer and writer with a commitment to making any presentation not only informative but also engaging and fun.
Recommended
More Related Content
Similar to How one project fell down, got up and ultimately succeeded; a "real" case study.
Similar to How one project fell down, got up and ultimately succeeded; a "real" case study. (20)
More from PMI-Montréal
More from PMI-Montréal (20)
Recently uploaded
Recently uploaded (20)
How one project fell down, got up and ultimately succeeded; a "real" case study.
- 1. 1 Falling down and getting back up How one project started to go off the rails but saved itself... for the most part.
- 2. What is PMG Pediatric Medical Group (PMG) Billing Group owned by 200 MCH MDs 5.5 FTE Billing Analysts (BAs) $32 Million in billing 400,000 billable acts/yr 2
- 3. Why PMG needed a new approach Manual data entry Inadequate software Inadequate communication with MDs Opaque business processes High MD and BA dissatisfaction 3
- 4. Typical approach to improvement 4
- 5. Tools used for Initial Analysis Vision and Scope Workflow and Risk analyses Business objectives and success criteria Scope Agreement and Budget Development Roadmap Market analysis and RFI 5
- 6. Billing Analysts’ Self-Assessed Core Competencies Accurate and fast data entry Power Users of MediRam software Knowledge of MCH and MDs 6
- 7. Key Factors in Deciding to Build Idiosyncratic Business Rules Estimates for modification >= building Pyxis Presentation 7
- 8. Why Pyxis? Leader in Agility Respect for each other when speaking Commitment to avoiding “us vs. them” Strong references 8
- 9. Agile at its core Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 9
- 10. Expected Workflow MD uses mobile device to enter billing PMG Reviews, Fixes, Bills Ins. and Pays MD MDs review all billing and pay info. 10
- 11. How it would work out! 11
- 12. When will heaven be here? Lack of interface with MUHC Data review ---> Data Entry BAs feel under siege! SMEs not so “E” Change management is ALWAYS hard 12
- 13. Heaven? What’s that? BAs won’t take ownership Users won’t test = bugs Users ignore rules engine = bad billing MDs see billing problems = complaints I don’t say “no” enough New functions over quality = bugs 13
- 14. The Frantic Angry Phone Call Demanding Immediate Attention and how Josh felt 14
- 15. My 2nd weirdest meeting ever Pyxis’s President’s approach: Things are going bad, so let’s talk about how we “feel” about the project. Josh’s thoughts: WTF! Bugs! Too many Bugs! What about the BUGS!!! 15
- 16. Why I trusted rather than screamed “There can be no friendship without confidence, and no confidence without integrity.” ---Samuel Johnson 16
- 17. How we got “past” blocking emotions Check ego… be present... REALLY listen How do they feel? Why do they feel that way? Check ego… put myself in their shoes Give them what they REALLY need See “Everything is Workable” by Diane Hamilton 17
- 18. Pyxis Team Building (weirdest meeting) Why aren’t we doing what we think we want to do? What do you think you want to do? What are you doing that stops you? What do you gain by NOT doing it? Big assumptions at the root of your actions? See “Immunity to Change” by Robert Kegan and Lisa Lahey 18
- 19. Now what? Transparency: Own our responsibility Inspection: Find and fix the problems Adaptation: Developer and PO are more present Pyxis pays to fix some bugs PO changes his approach 19
- 20. Key Lessons learned Be present Let anxiety be your guide not your master The conversations will happen, when should they happen? Ownership doesn’t just happen Agile blindspot?- PO needs things developers don’t 20
- 21. Tools that worked Team maintenance meetings Proving to Customer you get them User led Demos Taking responsibility minimizes blame game Ultimately...The software! 21
- 22. Not all peaches and cream Over budget Lack of full functionality Ver.2 = 25% of $ but 40% of total value Longer to complete than expected Time to market never key constraint 22
- 23. Software’s current status 6 month ROI to Partners (not partnership) Cost overruns = political problems Ver. 2 is coming? Billing transparency lowers MD confidence in BAs BAs own software 23
- 24. How the PMG is doing now BAs feel under siege & resistant to Ver. 2 2 new MD groups want to use software Support costs expected under budget Director of BAs believes system = “dramatic improvement!” 24
- 26. Josh’s Contact Info. If you need help with a project or have questions or thoughts you’d like to share: jshcwn@gmail.com or 514.816.8706 26
- 27. 27