1 / 42

Feature-Creep Delivery Framework

Feature-Creep Delivery Framework. Version 1. The Waterfall looks like this:. The waterfall model is a special case of such rarity in the real software industry as to be of no interest. Spirals or Trains.

wolfe
Télécharger la présentation

Feature-Creep Delivery Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Feature-Creep Delivery Framework Version 1

  2. The Waterfall looks like this: The waterfall model is a special case of such rarity in the real software industry as to be of no interest

  3. Spirals or Trains In practice product development will follow either a spiral or release train model. The characteristics are essentially the same but release trains usually have a fixed cadence.

  4. FDFProvides Predictability and quality in Product Releases By creating a structured process for agreeing timing and scope of releases. By reducing churn in requirements By establishing baseline against which change can be managed Clear visibility of release content and timing Alignment of all business functions around product releases Release Strategy Support and End-of-Life Policy

  5. Product Release Framework • End-to-end product lifecycle planning process. • Defines the lifecycle in terms of distinct project phases • Each functional unit in the business is responsible for defined tasks and deliverables in each phase • Governance is provided by a Product Delivery Team (PDT) chaired by Product Management • Each functional group is represented by a Product Delivery Team Member • The PDT is accountable to the overall business leadership (C level execs and key stakeholders)

  6. Overview Distinct phases in the project from concept through to delivery Role Phase 1 Concept Phase 2 Definition & Planning Phase 3 Development Phase 4 Readiness Phase 5 Launch Project Mandate Release Requirements Final Product Description Draft Product Description Business Case Requirements Baselined Product Management Workflow Model PRD (Product Requirements Document) Secure Field Trial Customer Channel Development Channel Strategy Sales Validation Package Go-To-Market Strategy Sales Planning and Account Targeting Marketing Go-To-Market Execution Go-To-Market Plan Sales Validation Functional groups represented by a Product Delivery Team Member Design Complete Technology Evaluation Design Specification Functional Specification Code Complete System Architecture Analysis Update Software Product Architecture Document Development Construction and Unit Test Integration Complete Interface Control Document Installation & Integration Test Documentation Plan Product Documentation Development Update Documentation Training and Documentation Training Plan Training Development Training Execution TC Test Analysis Test Plan and Test Design Test Execution CR Test GA EA Field Trial Plan Field Trial Design Documentation Review Project activities coordinated by a Product Manager CE Acceptance Criteria Maintenance & Support Transition to CE TPS Release Evaluation and Feedback TPS User Documentation Review TPS Operational Impact Statement Add M&S Requirements to PRD Global Services Install and Deployment Plan Install & Deploy Phase review points where the project team presents to the Company leaders Product Delivery Team Dissolved Product Delivery Team Leader and Project Mgmt Project Plan Baselined Product Delivery Team Formed Integrated Project Plan Post Launch Review Phase Review

  7. Project Phases Role Phase 1 Concept Phase 2 Definition & Planning Phase 3 Development Phase 4 Readiness Phase 5 Launch Project Mandate Release Requirements Final Product Description Draft Product Description Business Case Requirements Baselined Product Management Workflow Model PRD (Product Requirements Document) Secure Field Trial Customer Channel Development Channel Strategy Sales Validation Package Go-To-Market Strategy Sales Planning and Account Targeting Marketing Go-To-Market Execution Go-To-Market Plan Sales Validation Design Complete Technology Evaluation Design Specification Functional Specification Code Complete System Architecture Analysis Update Software Product Architecture Document Development Construction and Unit Test Integration Complete Interface Control Document Installation & Integration Test Documentation Plan Product Documentation Development Update Documentation Training and Documentation Training Plan Training Development Training Execution TC Test Analysis Test Plan and Test Design Test Execution CR Test GA EA Field Trial Plan Field Trial Design Documentation Review CE Acceptance Criteria Maintenance & Support Transition to CE TPS Release Evaluation and Feedback TPS User Documentation Review TPS Operational Impact Statement Add M&S Requirements to PRD Global Services Install and Deployment Plan Install & Deploy Product Delivery Team Dissolved Product Delivery Team Leader and Project Mgmt Project Plan Baselined Product Delivery Team Formed Integrated Project Plan Post Launch Review Phase Review Phase 1. Concept Phase 2. Definition and Planning Phase 3. Development Phase 4. Readiness Phase 5. Release Each project phase has a corresponding end of phaseReview, where project status, issues and recommendationsare presented

  8. Functional Groups Role Phase 1 Concept Phase 2 Definition & Planning Phase 3 Development Phase 4 Readiness Phase 5 Launch Project Mandate Release Requirements Final Product Description Draft Product Description Business Case Product Management (lead) Marketing Development Test Documentation Support & Maintenance Services inc. Training Requirements Baselined Product Management Product Management Workflow Model Development PRD (Product Requirements Document) Secure Field Trial Customer Global Services Sales Channel Development Channel Strategy Product DeliveryTeamLeader* Product Delivery Team Leader Training & Documentation Maintenance & Support Sales Validation Package Go-To-Market Strategy Sales Planning and Account Targeting Marketing Go-To-Market Execution Go-To-Market Plan Test Marketing Sales Validation Design Complete Technology Evaluation Design Specification Product Delivery Team Functional Specification Code Complete System Architecture Analysis Update Software Product Architecture Document Development Construction and Unit Test Integration Complete Interface Control Document Installation & Integration Test Documentation Plan Product Documentation Development Update Documentation Training and Documentation Training Plan Training Development Training Execution TC Test Analysis Test Plan and Test Design Test Execution CR Test GA EA Field Trial Plan Field Trial Design Documentation Review CE Acceptance Criteria Maintenance & Support Transition to CE TPS Release Evaluation and Feedback TPS User Documentation Review TPS Operational Impact Statement Add M&S Requirements to PRD Global Services Install and Deployment Plan Install & Deploy Product Delivery Team Dissolved Product Delivery Team Leader and Project Mgmt Project Plan Baselined Product Delivery Team Formed Integrated Project Plan Post Launch Review Phase Review Define the swim lanes appropriate for your business

  9. Tasks and Deliverables Role Phase 1 Concept Phase 2 Definition & Planning Phase 3 Development Phase 4 Readiness Phase 5 Launch Project Mandate Release Requirements Final Product Description Draft Product Description Business Case Requirements Baselined Product Management Workflow Model PRD (Product Requirements Document) Secure Field Trial Customer Channel Development Channel Strategy Sales Validation Package Go-To-Market Strategy Sales Planning and Account Targeting Marketing Go-To-Market Execution Go-To-Market Plan Sales Validation Design Complete Technology Evaluation Design Specification Functional Specification Code Complete System Architecture Analysis Update Software Product Architecture Document Development Construction and Unit Test Optional Deliverable – i.e. a document that may be required Integration Complete Interface Control Document Installation & Integration Test Documentation Plan Product Documentation Development Update Documentation Training and Documentation Training Plan Training Development Training Execution TC Test Analysis Test Plan and Test Design Test Execution CR Test GA EA Field Trial Plan Field Trial Technology Evaluation Deliverable – i.e. a document that is usually required within the Development Framework Functional Specification Design Documentation Review CE Acceptance Criteria Maintenance & Support Transition to CE TPS Release Evaluation and Feedback TPS User Documentation Review TPS Operational Impact Statement Architectural Analysis Add M&S Requirements to PRD Product Architecture Document Global Services Install and Deployment Plan Install & Deploy Product Delivery Team Dissolved Product Delivery Team Leader and Project Mgmt Project Plan Baselined Product Delivery Team Formed Integrated Project Plan Post Launch Review Task – i.e. a activity that is performed by a functional group within the project Phase Review Generally, a Deliverable will have a Template Document and a set of Guidelines for completion of the document A Task will usually have a set of Guidelines for the activity Modify these tasks and Deliverables to fit your business

  10. Overview Role Phase 1 Concept Phase 2 Definition & Planning Phase 3 Development Phase 4 Readiness Phase 5 Release MRD (Market Requirements Document) Sales Training Sales Planning and Account Targeting Business Case Go-To-Market Strategy(inc Channel Strategy) Sales Collateral (Updated) Go-To-Market Plan Sales & Marketing Sales Validation(with customers) Go-To-Market Execution Release Requirements Prescriptive Architecturesand Activity Profiles Updated Roadmap Final Product Description Requirements Baselined Draft Product Description PRD (Product Requirements Document) UpdatedPlatform Defn Product Management Benchmarks Platform Defn Secure Field Trial Customer Performance Reqs Field Trial Plan Design Complete Technology Evaluation Design Specification Functional Specification Re-work Software Unit Test Plan Architecture Analysis Developer Performance Guidelines Product Architecture Document Development Implementation and Unit Test Feature Complete Integration Test Perf designanalysis PerformanceDesign Changes Release Notes Integration Complete Iterative performance adjustments, tuning and testing Documentation Plan Product Documentation Development Update Documentation Documentation Test Execution TC Certification Test Strategy and Planning Test Plan and Test Cycle Design GA Test Tuning & Benchmarking CR Test Preparation Tuning/sizingguidelines Design Documentation Review Maintenance Maintainability Review Iterative performance adjustments, tuning and testing Maintenance Acceptance Criteria Support Operational Impact Statement Support Training Field Trial Support Add S&M Requirements to PRD Supportability Review Install & Deploy + Partner support Alpha Trial Install and Deployment Plan Add Services Requirements Services Training Custom Benchmarking Servicesinc. Training Training Materiel Development Training Execution Training Assessment Product Delivery Team Dissolved Product Delivery Team Leader and Project Mgmt Project Plan Baselined Product Delivery Team Formed Integrated Project Plan Post Release Review Concept Complete (RPG Review) Definition & Planning Complete (RPG Review) Optional Phase Review Development Complete (RPG Review) Readiness Complete (RPG Review) Release Complete (RPG Review) Phase Review TC = Test Complete CR = Controlled Release GA = General Availability Project Task Feature Status Key On the Radar Concept Committed Development Committed Deliverable Optional Optional Looks complicated but… Most people live in a single laneand the tasks and deliverablesare likely familiar

  11. continued The key items delivered by Product Management in order to commence the FDF process are: - Market Requirements - Business Case These items will permit planning for a Concept Commit to commence. Several of the Product Delivery Team members may be required to plan for Concept Commit. The Product Delivery Team Membership will be confirmed at Concept Commit milestone. Optional Optional Role Phase 1 Concept Phase 2 Definition & Planning Phase 3 Development Phase 4 Readiness Phase 5 Release MRD (Market Requirements Document) Sales Training Sales Planning and Account Targeting Business Case Go-To-Market Strategy(inc Channel Strategy) Sales Collateral (Updated) Go-To-Market Plan Sales & Marketing Sales Validation(with customers) Go-To-Market Execution Release Requirements Prescriptive Architecturesand Activity Profiles Updated Roadmap Final Product Description Requirements Baselined At Development Committed it is expected that all functional groups have a fully resourced plan for project delivery. Draft Product Description PRD (Product Requirements Document) UpdatedPlatform Defn Product Management Benchmarks Platform Defn Secure Field Trial Customer Performance Reqs Field Trial Plan Design Complete Technology Evaluation Design Specification Functional Specification Re-work Software Unit Test Plan Architecture Analysis Developer Performance Guidelines Product Architecture Document Development Implementation and Unit Test The “Go / No Go” Milestone is confirmed by RPG prior to investing in the next phase of the project. Each Product Delivery Team member is expected to provide a recommendation based on the status of their activities and those of the wider team. Feature Complete Integration Test Perf designanalysis PerformanceDesign Changes Release Notes Integration Complete Iterative performance adjustments, tuning and testing Documentation Plan Product Documentation Development Update Documentation Documentation Test Execution TC Certification Test Strategy and Planning Test Plan and Test Cycle Design GA Verification Tuning & Benchmarking CR Test Preparation Tuning/sizingguidelines Design Documentation Review Maintenance Maintainability Review Iterative performance adjustments, tuning and testing Maintenance Acceptance Criteria Support Operational Impact Statement Support Training Field Trial Support Add S&M Requirements to PRD Supportability Review Install & Deploy + Partner support Alpha Trial Install and Deployment Plan Add Services Requirements Services Training Custom Benchmarking Servicesinc. Training Three types of release: Early Access (EA) Controlled Release (CR) and General Availability (GA). Training Materiel Development Training Execution Training Assessment Product Delivery Team Dissolved Release Manager Project Plan Baselined Product Delivery Team Formed Integrated Project Plan Post Release Review Concept Complete (RPG Review) Definition & Planning Complete (RPG Review) Optional Phase Review Development Complete (RPG Review) Readiness Complete (RPG Review) Release Complete (RPG Review) Phase Review Feature Status TC = Test Complete EA = Early Access CR = Controlled Release GA = General Availability Key On the Radar Concept Committed Project Task Development Committed FDF Deliverable

  12. Release Types

  13. Release Criteria Development Support S&M Support Launch Production Readiness Dev • Quality levels defined at DC • Performance report and sizing capability • Maintenance sign-off Customer field Trial(s) GA CR requires requires • Quality levels defined atDevelopment Commit S&M sign-off in turn requires: • All the GA criteria plus: • Maintainability Review • Supportability Review • M&S Revenue stream • S&M resource plan (heads, training, hardware, tools)

  14. Product Delivery Team Enable cross-functional collaboration and coordination Facilitate efficient communications and effective decision-making Build ownership and accountability for project performance Enable rapid execution of project activities Provide project focus within an effective functional organization Direct day-to-day activities Create and manage to an integrated plan Resolve issues and make trade-off decisions Assess Release readiness E.g. Sales assess readiness of product for release and demonstrate sales team readiness. Release Manager Each FDF project is driven by the work and recommendations of a cross-functional Product Delivery team. Development Product Management Services Inc Training Product Delivery Team Leader Sales & Marketing Documentation Support & Maintenance Verification

  15. RPG Focus and Structure Product Management Development Global Services Sales Product DeliveryTeam Leader* Product Delivery Team Leader Training & Documentation Maintenance & Support Test Marketing Product Delivery Team • The Roadmap Planning Group is the governance body that provides management oversight and direction for FDF projects. • The RPG is responsible for • Setting direction and committing resources • Reviewing product line priorities • Ensuring that projects are well planned and remain on track Milestone Review Sales/Mkting S&M CTO Verification Services Dev CEO Release Manager presents to RPG Product Management representatives and Product Delivery Team members are invited to RPG

  16. Milestone Reviews – what is presented

  17. And this process will give you a roadmap…

  18. Disclaimer Due to the forward-looking nature of this Roadmap, Feature-Creep includes information about products that are in the planning stage of development or that represent custom features or product enhancements. Functionality cited in this document that is not publicly available is discussed within the context of the strategic evolution of the proposed products. This document is for informational purposes only. The information in this document is provisional and is subject to change without notice. Nothing in this document should be considered as a commitment by Feature-Creep in relation to future functionality, release dates, product roadmaps or any other matter. Feature-Creep MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

  19. Feature Status Definitions " Due to the forward-looking nature of this Roadmap, Feature-Creep includes information about products that are in the planning stage of development or that represent custom features or product enhancements. Functionality cited in this document that is not publicly available is discussed within the context of the strategic evolution of the proposed products. This document is for informational purposes only. The information in this document is provisional and is subject to change without notice. Nothing in this document should be considered as a commitment by Feature-Creep in relation to future functionality, release dates, product roadmaps or any other matter. Feature-Creep MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. "

  20. Feature-Creep Roadmap 2008 Feature Status Development Committed Concept Committed Radar

  21. Irregular or Cyclical Planning Irregular • Product Strategy reviewed and updated when desired • Each product release cycle kicks off as the previous cycle nears Readiness • Each release of arbitrary length based on business view of best compromise between release date and feature content Cyclical (example) • Annual Planning Cycle: Owned by Roadmap Planning Group (Key stakeholders) • Set out 12 months of Business and linked Product Strategy. “Concepts Committed” based on Business Cases. Product Management and Marketing driving the process. • Quarterly Planning Cycle: Owned by Product Management • Define the content of 3 monthly releases for the next quarter. “Developments Committed” based on engineering analysis, estimates and plans. • Approved by PSC • Monthly Planning Cycle: Owned by Engineering • Detailed delivery planning for the next release • Agile: daily Stand-up with cross-functional participation

  22. Annual Planning Cycle Q nConceptCommitted Q n+1ConceptCommitted Q n+2Concept Committed Q n+3ConceptCommitted Q n+4Concept Committed Q n+5ConceptCommitted QnConcept Committed Roadmap Planning Group Roadmap Planning Group Roadmap Planning Group Roadmap Planning Group Roadmap Planning Group Roadmap Planning Group Roadmap Planning Group 12 or 18 month roadmap Product Delivery Team Product Delivery Team 1 MonthDefinition & Planning Month 1Sprint 1 Month 2Sprint 2 Month 3Sprint 3 Release 3 MonthsDevelopment 1 MonthReadiness Product Lifecycle example DevelopmentCommitted Roadmap Planning Group reviews and approves release Change Control Each quarter, Product Delivery Team takes next quarter’s Concept Committed items go through Definition & Planning Phase and breaks down into 3 Agile Sprints Roadmap Planning Group approves next quarter’s release plan: it becomes “Development Committed” Product Delivery Team manages sprints and final release

  23. Release Train Example Roadmap Planning Group Roadmap Planning Group Roadmap Planning Group Roadmap Planning Group Q nDevelopmentCommitted Q n+1ConceptCommitted Q n+2ConceptCommitted Q n+3ConceptCommitted 1 MonthReadiness 1 MonthReadiness 1 MonthReadiness 3 MonthsDevelopment 3 MonthsDevelopment 3 MonthsDevelopment 1 MonthDefn & Plan 1 MonthDefn & Plan 1 MonthDefn & Plan Annual Planning Cycle DevelopmentCommitted DevelopmentCommitted DevelopmentCommitted Delivery of major new component(s) Activity for Qn starts beginning Q n-1 One Month contingency to meet quarterly roadmap commitment Dev transitions smoothly from one release to the next Ongoing development of major components

  24. Ground Rules • Don’t try to jump on a moving train; you may cause a crash and kill everyone – wait for the next one • The train at the station will almost always be full – if something goes on, something else has to come off, or at least change from a Must to a Should or Could • Customers don’t (often) expect total flexibility but they like predictability: quoting a date and then hitting it earns more loyalty longer term than aggressive but missed commitments • Product Management have to provide the change control mechanisms and communicate the changes to stakeholders in a timely manner

  25. Points to remember • FDF is not a Quality Management System – it doesn’t define how detailed planning and execution of product development is carried out. • Individual functional areas are expected to have their own more detailed plans, intermediate milestones and deliverables and to be actively managing them and reporting progress to the PDT. • It’s NOT complicated – most people need only be aware of the tasks and deliverables for one or two lanes.

  26. Feature-Creep Custom Development

  27. CDF Objectives Provide value added service to customers by delivering features outside normal FDF roadmap Provide consistent approach to dealing with customer enhancement requests Price features correctly in respect of cost to develop and opportunity cost of resources applied Ensure that Support and Maintenance issues and costs are properly addressed.

  28. Four Delivery Options RoadmapNormal roadmap process, dates and content established by FDF process and approved by RPG Accelerated Product A release to deliver one or more generic features, possibly already on the roadmap, in accelerated timescales Extended Product A release to deliver one or more customer specific features, not applicable to the general customer base and not road-mapped. Custom Professional Services developed modifications or extensions to standard product

  29. Economic Basis • Product Development resources (R&D, Maintenance and QA) drive software licence revenues and should deliver a contribution margin of >85% • In other words – Product Development resources should not be diverted on to work which delivers lower margins than this. • Loaded labour rates around £250 per day • Standard Product Development daily rate: £1700 • Accelerated Product Development rates (EMEA) £850 p.d. • Extended Product Development rates (EMEA) £1700 p.d. • Note that Accelerated rates are comparable to standard Professional Services rates and Services resources may be used for Accelerated (or Extended) Product Development work when skills are available • Any discounting must be agreed between the Sales Manager and the resource owner.

  30. Custom Delivery Framework IPR retained by Company throughout Note that Extended Product may never actually be purchased by a customer but having the concept allows positive customer engagements around unique needs Quotations valid for 4 weeks, then need re-confirmed sinceresource may have been re-assigned

  31. Delivery Options Owned byMaintenance Latest Version Service Pack: Preferred option but resource constrained In-Support Version Patch Release:Strongly discouraged – very undesirable to add features to a patch release. Out-of-Support Version Controlled Release:Discouraged but option for customer on legacy version who will not upgrade. Priced to reflect increased costs of support. • Owned by Product Development • Roadmap ReleaseLongest lead time and limited flexibility after Concept and Development Commit Dates

  32. Feature-Creep Releases

  33. Release Types Major Release Minor Release Service Pack Service Release Update Release

  34. Major Release ContentA full product release which delivers major new functions and/or architectural changes, which can include schema changes, new components, new deployment models and new packaging/licensing models. NamingFirst digit group increment e.g. 4.0, 5.0, 6.0 SupportSupported for 3 years after next major or minor release FrequencyNo more than one per year and more typically 2-3 years apart Upgrades supportedFrom any version in support at time of release

  35. Minor Release ContentA full product release which delivers significant new functions and/or architectural changes, which can include schema changes, new components, new deployment models and new packaging/licensing models. NamingSecond digit group increment e.g. 4.1, 5.3 SupportSupported for 3 years after next major or minor release FrequencyNo more than two per year and typically 1-2 years apart Upgrades supportedFrom any version in support at time of release

  36. Service Pack ContentA partial product release which delivers a roll-up of all patch release functionality since the last Major or Minor release, plus additional critical fixes. Will not normally include new feature content but small enhancements are permitted. No changes to schema, architecture, packaging or licensing. NamingNew build number e.g. ? (not that the patch numbers are monotonically increasing but not necessarily consecutive) SupportSupported for ? months after next service or patch release FrequencyNo more than four per year and typically 6-9 months apart Upgrades supportedFrom any version in support at time of release

  37. Service Release ContentA full product release which delivers a roll-up of all patch release functionality since the last Major or Minor release, plus additional critical fixes. Will not normally include new feature content but small enhancements are permitted. No changes to schema, architecture, packaging or licensing. NamingNew build number e.g. ? (not that the patch numbers are monotonically increasing but not necessarily consecutive) SupportSupported for ? months after next service or patch release FrequencyNo more than four per year and typically 6-9 months apart Upgrades supportedFrom any version in support at time of release

  38. Update Release ContentA partial release which delivers one or more fixes for specific critical issues. Will not normally include new feature content but small enhancements are permitted. No changes to schema, architecture, packaging or licensing. NamingNew build number e.g. ? (not that the patch numbers are monotonically increasing but not necessarily consecutive) SupportSupported for ? months after next service or patch release FrequencyNo more than one per week and typically 1 month apart

  39. Product Support Policy Support terms for both technical assistance and maintenance releases are as follows: • Major (no dot) Releases are supported for one year after the date of the next Major Release or Minor Release. • Minor (one dot) Releases are supported for six months after the date of the next Minor Release or for twelve months after the next Major Release • Service (two dot) and Update (three dot) Releases are supported for three months after the date of the next Update Release or for six months after the next Minor Release or for twelve months after the next Major Release. • Definitions • Update Release – unplanned release to fix one or more bugs. Will typically “roll-up” all previous patch releases since last Major/Minor release. • Service release – planned release to “roll-up” contents of multiple Update releases, and often to introduce small features.

  40. Support Precedence The Major Release grace period will take precedence over the Minor Release grace period, and the Minor Release grace period will take precedence over the Service and Update Release grace period. Technical assistance will be available for the life of a Major Release, but Updates for a given Service Release will only be provided for the life of the Service Release. In addition, Feature-Creep is only obligated to support the two (2) most recent Minor Releases of the Licensed Product at any one time. This de-support policy is OS specific, in that the de-support period is related to the next release on the OS platform in question e.g. where the dates for an AIX release differ from those for Solaris, the support period on AIX is solely determined by dates of the AIX releases.

  41. Extended Support We will not support a product release beyond de-support date unless by specific contractual agreement. When a product release is de-supported, the customer can buy a contract for Support even after de-support date.But the contract will normally state that -a- Support will not guarantee response timeb- Support will not fix bugsc- Support will try to get the customers a work-around but will not guarantee it. The actual level of support will vary by contract and preceding agreements may take precedence.

  42. Questions?

More Related