Utilizing Agile in Your Contracting Process
•
2 recomendaciones•1,666 vistas
The document discusses contracting with an agile approach. It recommends focusing on collaboration over contract negotiation and allowing flexibility to change course as needs emerge. Key suggestions include using simple contracts that can be easily adapted and terminated, avoiding lock-ins, and maintaining an agile portfolio of contracts that can scale up or down quickly. The overall message is that contract terms should not limit necessary agility in complex, changing environments.
Recomendados
Recomendados
Más contenido relacionado
Similar a Utilizing Agile in Your Contracting Process
Similar a Utilizing Agile in Your Contracting Process (20)
Último
Último (20)
Utilizing Agile in Your Contracting Process
- 2. Reaktor Mannerheimintie 2 00100, Helsinki Finland tel: +358 9 4152 0200 www.reaktor.com info@reaktor.com ©2016 Reaktor All rights reserved Utilizing Agile in Your Contracting Process General Counsel Juha Ilola IACCM EMEA Conference / 10 May 2016, Rome
- 3. REAKTOR MAY 2016 REAKTOR MAY 2016 About Reaktor • Creative technology company on mission to build exceptional digital services • Offices in NYC, Helsinki and Tokyo • Headcount 360, turnover 43 MEUR • Customers include HBO, Finnair, Nasdaq, Panasonic, Michael Kors, Kone, Supercell • Also one of the most active Nordic early stage investors through its investment arm Reaktor Ventures
- 4. REAKTOR MAY 2016 REAKTOR MAY 2016 My Focus • I come from sell side, but presentation focus is buy side • Typical contract is continuous professional service contract with 0 - 2 weeks’ notice period and 500K - 5 MEUR annual value • Reaktor’s focus industries are finance, retail, media, telecommunications, in- flight services and the public sector • Reaktor has flat organization consisting of small, self-organizing teams
- 5. REAKTOR MAY 2016 REAKTOR MAY 2016 1. Why agile? 2. What is agile? 3. How to contract in more agile manner? 4. Key takeaways My Agenda
- 6. REAKTOR MAY 2016 1. Why agile?
- 7. Agile methods were conceived in the software industry to tackle constant project delays and failures. REAKTOR MAY 2016
- 8. Back in 1994, success rate in software projects was abysmal 16% with 31% of projects failing and 53% becoming challenged. REAKTOR MAY 2016 SOURCE: STANDISH GROUP INTERNATIONAL: CHAOS REPORT 1994
- 9. By 2015, success rate with agile methods has climbed to 39% with 9% projects failing and 52% becoming challenged. REAKTOR MAY 2016 SOURCE: STANDISH GROUP INTERNATIONAL: CHAOS REPORT 2015
- 10. REAKTOR MAY 2016 Technologies Customerneeds Known Uncertain ClearUnclear SOURCE: STRATEGIC MANAGEMENT AND ORGANIZATIONAL DYNAMICS BY RALPH STACEY
- 11. REAKTOR MAY 2016
- 12. I’m not in software business. Why should I care? REAKTOR MAY 2016
- 13. Software is eating the world. Disruptive new players shake every industry. Those who cannot adapt face extinction. REAKTOR MAY 2016
- 14. REAKTOR MAY 2016 2. What is agile?
- 15. REAKTOR MAY 2016 Typically when someone explains agile, you may hear and see something like this.
- 26. Although that stuff is important, let’s put it aside for the remainder of this presentation. REAKTOR MAY 2016
- 27. Being agile means being able to change course, and then changing course when appropriate. REAKTOR MAY 2016
- 28. Changing course includes the ability to easily start, and to end, something when appropriate. The ability to try. REAKTOR MAY 2016
- 29. REAKTOR MAY 2016 When operating in the complex problem domain you need to be able to change course; and to start, end and try things. You need to be agile. REAKTOR MAY 2016
- 30. REAKTOR MAY 2016 3. How to contract in more agile manner?
- 31. “we have come to value… customer collaboration over contract negotiation” The Agile Manifesto REAKTOR MAY 2016
- 32. Risks in a software projects are most effectively managed with proper ways of working, i.e. agile methodologies. Not with a contract. REAKTOR MAY 2016
- 33. A “great deal” passing all risk to other party mitigates your down-side risk, but may hinder or even remove chances of succeeding. REAKTOR MAY 2016
- 34. DON’T prepare detailed, up-front specifications of deliverables as in reality deliverables are bound to evolve during the project when your real needs are discovered. REAKTOR MAY 2016
- 35. DO find the best talent for the project. Keep possible contractual requirements on a high level only so that implementation details can benefit from emerging knowledge. REAKTOR MAY 2016
- 36. DON’T impose strict change management process in the contract where “business owner to engineer” or “engineer to engineer” change management is sufficient. REAKTOR MAY 2016
- 37. REAKTOR MAY 2016 DO give your business / project owner and the supplier’s professionals the power to agree on changes to the scope within specified budget.
- 38. DON’T use liquidated damages for delay or excessive warranties as they force the supplier to deliver on the outdated requirements set out in the contract and to fight changes. REAKTOR MAY 2016
- 39. REAKTOR MAY 2016 DO aim for collaborative issue resolution, e.g. by downscaling scope in case of apparent delay. If sanctions are necessary, aim for “smaller percentages” without need to evidence breach (e.g., trial period, satisfaction guarantee).
- 40. DON’T enter into long fixed-term contracts with limited exit rights, or (excessive) early termination penalties. REAKTOR MAY 2016
- 41. REAKTOR MAY 2016 DO aim for contracts that can be freely terminated when they no longer benefit both parties. Split big contracts into small contracts. Test new suppliers with PoC’s / small contracts before bigger awards.
- 42. DON’T contractually force non-optimal ways of working onto people performing the work. REAKTOR MAY 2016
- 43. DO let the people performing the work define and improve the ways or working.
- 44. DON’T set-up or agree to vendor lock-ins (via limited licenses or otherwise). REAKTOR MAY 2016
- 45. DO ensure that you can actually end the business relationship when it is no longer in your interest. In software world, ensure that you have the IPR or unlimited license after expiry.
- 46. DON’T increase your transaction costs by drafting unnessarily complex contracts. REAKTOR MAY 2016
- 47. DO strive to draft simple, beautiful contracts, that provide the simplest solution to the problem at hand. Simple contracts are easy to negotiate, perform and change.
- 48. DON’T limit your thinking of agile to context of one contract only. REAKTOR MAY 2016
- 49. DO aim for an agile portfolio of contracts that can be quickly adapted to change - e.g., by concluding and ending contracts, re-awarding contracts between suppliers, scaling scopes up and down on the basis of focus area shifts.
- 50. REAKTOR MAY 2016 4. Key takeaways
- 51. 1. Agility is crucial in complex domain. 2. To be agile is to be able to change course - and to start, end and try. 3. Contract terms should not limit agility in name of risk management if and where risks are best managed otherwise.