Sdec10 lean package implementation


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Sdec10 lean package implementation

  1. 1. Lean Package ImplementationLean/Agile Myth #12
  2. 2. Lean/Agile Myth #12• Lean and Agile Methodologies are only applicable for greenfield opportunities - Not applicable for brownfield - Not applicable for Package Integration - Not applicable for Application Maintenance Services (Yesterday)
  3. 3. Agenda• What are Package Implementation Projects ?• How are Package Implementation Project typically done?• What aspects of Package Implementation projects could be done in a Lean Manner?• Questions
  4. 4. • What are Package Implementation Projects ?
  5. 5. Package Implementation Projects• Package Implementation Projects are projects that typically involves a Commercial Off The Shelf(COTS) product that needs to be integrated into the client environment.• These products involve more or less configuration and customization depending on the product and fit to the client’s requirements.
  6. 6. Audience Participation• Question #1 – Why do companies choose COTS products? - Time to Market? - Cost? - Transfer of Risk? - Shared Cost of Ownership? - Available resources/capacity? - Product fit to Requirements? - Others?
  7. 7. Reasons for choosing COTS products• Surprisingly, the two main reasons for selecting COTS products to address a business problem are: - Transfer of Risk - Shared Cost of Ownership• The one reason which should have greater importance but usually is not taken into consideration: - Product Fit to Requirements (read Cost) - Rule of thumb is that an 80-90% fit is required to make a COTS implementation cost effective. Otherwise possibly more money would be spent customizing a COTS package than building new.
  8. 8. • How are Package Implementation Project typically done?
  9. 9. Application Maintenance ServicesComponents Painful Implementation Painful Testing Painful Specification Painful Contracting
  10. 10. Contracting• This is done is a very adversarial way to try and anticipate all aspects of the relationship to ensure both parties are covered.• The contracts are very detailed and allow for very little change and modification• Most of the contract deals with how the companies will interact and there is little to any mention of the business problem being solved.
  11. 11. Specification• Specification follows the contracting process and the emphasis is to create extremely detailed specification documents to define all the functionality required.• Of course there are always items not thought of or not detailed enough.• Many time the product rationale is used to defend functionality. (i.e. that is how the product works) This can be initially accepted by the business but frequently requires change later when reality hits.
  12. 12. Testing• Testing of the COTS application is then problematic and it builds upon the specification which was built upon the contract.• Testing then attempts to verify that the application works as documented. Lost in this process is whether the application is actually addressing the business problem.
  13. 13. Implementation• Implementation is then built upon the testing which was built upon the specification which was built upon the contract and the question that is asked at Implementation is not: - Does this solve the business problem?• Rather it is: - Can you accept this solution and go live?
  14. 14. Where did it all go wrong?
  15. 15. Lean Principles Refresher• Before we discuss how Package Implementation can be done in a Lean manner, let’s do a Lean Principles Refresher
  16. 16. Lean Software Development• Lean Software development is a style of software development that emphasizes customer satisfaction through continuous delivery of functional software. In contrast to traditional software development methods, lean developers liaise continuously with business clients.• Their objective is to deliver working software as frequently as every two weeks during a project, and welcome changes to the requirements in response to evolving business needs.
  17. 17. Lean Software Development• The most crucial aspect of Lean is the execution of the project in iterations and quick feedback loops possible because of these iterations. It is essential to note that these iterations to not just apply to construction, they also apply to the following tasks: - Project Management and Planning - Analysis - Technical Design - Testing - Deployment
  18. 18. Lean Software Development• Iteration planning is ‘the’ key planning initiative - Iterations need to be planned in conjunction with the client to accomplish the following: • Deliver functionality to define the cadence and tempo of the project • Deliver functionality to deliver real value to the client • Deliver functionality to reduce and minimize risk for the entire project • Lessons learned from one iteration must feed into subsequent iterations so that we don’t execute the project in iterations with similar results, but that we execute the project in iterations with better results. - We execute better, smarter, and quicker
  19. 19. Lean Software Development Principles• Eliminate Waste - The three biggest wastes in software development are: - Extra Features - Churn - Crossing Boundaries• Build Quality In - If you routinely find defects in your verification process, your process is defective. - Mistake-Proof Code with Test-Driven Development - Stop Building Legacy Code - The Big Bang is Obsolete
  20. 20. Lean Software Development Principles• Create Knowledge - Planning is useful. Learning is essential. - Use the Scientific Method - Standards Exist to be Challenged and Improved - Predictable Performance is Driven by Feedback• Defer Commitment - Abolish the idea that it is a good idea to start development with a complete specification. - Break Dependencies - Maintain Options - Schedule Irreversible Decisions at the Last Responsible Moment
  21. 21. Lean Software Development Principles• Deliver Fast - Lists and queues are buffers between organizations that simply slow things down. - Rapid Delivery, High Quality, and Low Cost are Fully Compatible - Queuing Theory Applies to Development, not Just Servers - Limit Work to Capacity• Respect People - Engaged, thinking people provide the most sustainable competitive advantage. - Teams Thrive on Pride, Commitment, Trust, and Applause - Provide Effective Leadership - Respect Partners• Optimize the Whole - Brilliant products emerge from a unique combination of opportunity and technology. - Focus on the Entire Value Stream - Deliver a Complete Product - Measure UP
  22. 22. • What aspects of Package Implementation projects could be done in a Lean Manner?
  23. 23. Audience Participation• Question #2 – How could we implement an COTS application in a Lean Manner? - Visual Project Management? • i.e. dashboards/Ticket Boards - Iterations? - Requirement Management? - Implementation? - Logistics? - Lean Project Management? • i.e. Daily Stand ups
  24. 24. Requirements Management• Requirements Management is key to any successful project. For Package Implementation projects it becomes even more important to ensure everyone understands the requirements.• Frequently Use Cases are the traditional way of documenting requirements.• A much better way of defining requirements are: - User Stories - Test Cases
  25. 25. User Stories• A user story of one or more sentences in the everyday or business language of the user that captures what the user wants to achieve.• They are typically in the following format: - "As a <role>, I want <goal/desire> so that <benefit>"• User Stories are much more concise that Use Cases and provide this extra communication and detail required when dealing with an external and somewhat unknown COTS product.• These User Stories can then be collected together to define features of the system.
  26. 26. User Stories• One challenge with User Stories is the ability to document batch on non end user processes• Honestly we need to address this on all Lean project
  27. 27. Test Cases• Traditionally Test Cases are not used for Requirements Management but rather for the testing process itself.• Ultimately, there are no better requirements than to list the test cases that will confirm the requirement has been met or not met.• These Test Cases should be defined at the start of the project and with User Stories will define the system requirements.
  28. 28. Iterations• Traditionally, Package Implementations follow a Big Bang approach. All the functionality is analyzed, designed, coded, tested, and implemented at once.• This does not take advantage of one of the main tenets of Lean to execute better as we progress through the project.• It is highly recommended that Package Implementations also be implemented in iterations. These iterations should go right through to production.
  29. 29. Iterations• It is important to remember that these iterations are not just for development and testing, but for all phases of the project including testing and implementation.• Sometimes critical items are left out of iterations like Reporting and Data Conversion. This is not recommended. An iteration must be able to stand on it’s own.
  30. 30. Iteration Schedule• Agreement on scope and schedule• Execution of required scope• Demonstration of iteration scope - This is more than a simple project led demonstration - The business execute all of the User Stories and Test cases to ensure the expected outcome occur• Feedback is then solicited for new User Stories or test cases that should be added to future iterations• Clients are then asked to sign off that iteration
  31. 31. Implementation• For some unknown reason the bulk of Package Implementations still implement using the Big Bang approach• Very rarely are they implemented using the parallel or pilot approach• This adds a great amount of risk to the projects.
  32. 32. Contractual• Include Contractual incentives - profit sharing for finishing early - Cost sharing for finishing late - Ability and incentive to add additional business value • Concept of trading User Stories
  33. 33. Logistics• Lean Software Development recommends having the project team and business co-located.• For Package Implementations, I would also recommend that the vendor should also be co-located.
  34. 34. Conclusion• The principles of Lean Software Development are applicable to all types of projects• They are some areas of Package Implementation projects that can benefit greatly. These are: - Requirements Management - Iterations - Implementation - Contractual - Logistics
  35. 35. Questions?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.