{"id":2851,"date":"2024-10-03T08:40:18","date_gmt":"2024-10-03T06:40:18","guid":{"rendered":"https:\/\/www.theprojectgroup.com\/blog\/en\/?p=2851"},"modified":"2024-10-17T13:38:15","modified_gmt":"2024-10-17T11:38:15","slug":"agile-contract-models","status":"publish","type":"post","link":"https:\/\/www.theprojectgroup.com\/blog\/en\/agile-contract-models\/","title":{"rendered":"Agile Contract Models \u2013 Working with Cross-Corporate Teams"},"content":{"rendered":"<p>Those using agile methodology first focus on the methods and becoming familiar with the agile roles, work practices and principles. Regardless of which rules you follow though, these rules do not address the collaboration of cross-corporate teams. The following article fills this important gap. You will learn:<\/p>\n<ul>\n<li>How cross-corporate collaboration works<\/li>\n<li>The advantages and disadvantages of how the roles are distributed<\/li>\n<li>How to write an agile contract that protects everyone involved in this collaboration<\/li>\n<\/ul>\n<p>Here you will find a collection of different contract models specifically for use in agile project environments.<\/p>\n<p>Let us begin with an overview of the chapters:<\/p>\n<ul>\n<li><a href=\"#Chapter1\">How do agile teams work?<\/a><\/li>\n<li><a href=\"#Chapter2\">What is a \u201cproduct owner\u201d?<\/a><\/li>\n<li><a href=\"#Chapter3\">Contract model for agile projects: Who chooses the product owner?<\/a><\/li>\n<li><a href=\"#Chapter4\">Overview of agile contract models<\/a><\/li>\n<li><a href=\"#Chapter5\">Other forms of hybrid and customized contracts for agile projects<\/a><\/li>\n<li><a href=\"#Chapter6\">Which contract type is most suitable?<\/a><\/li>\n<li><a href=\"#Chapter7\">Conclusion \u2013 Agile contract models<\/a><\/li>\n<\/ul>\n<h2 id=\"Chapter1\">How Do Agile Teams Work?<\/h2>\n<p>We will start with a quick review: an agile team \u2013 often a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)\" target=\"_blank\" rel=\"noopener\">Scrum <\/a>team \u2013 consists of a product owner, a Scrum master and three to nine developers. The team uses iterations, called sprints, to focus on the development of a new product or the further development of an existing one. Each product increment should be ready to be demonstrated and potentially delivered by the end of each sprint.<\/p>\n<p>Development cycles should last no longer than one month. The product owner defines the stakeholder expectations. The Scrum master acts as team coach and process owner, and helps teams not yet familiar with the new rhythm of this type of development.<\/p>\n<div id=\"id69573c1f1973b\" class=\"iframecontainer iframecontainer--hidden\">\n            <div class=\"iframecontainer__head\" style=\"background: #D60B52!important;\">\n                <div class=\"iframecontainer__head__inner\" style=\"color:#ffffff;\" data-for=\"#id69573c1f1973b\">\n                    <p><strong>PDF Download: <\/strong> Comparing PM Methodologies: Agile, Traditional, and Hybrid<\/p>\n                <\/div>\n                <div class=\"iframecontainer__head__icon\" data-for=\"#id69573c1f1973b\">\n                    <svg width=\"10px\" height=\"16px\" viewBox=\"1092 550 10 16\" version=\"1.1\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" xmlns:xlink=\"http:\/\/www.w3.org\/1999\/xlink\">\n                        <polygon class=\"iframecontainer__head__icon__pfeil\"  data-for=\"#id69573c1f1973b\" stroke=\"none\" fill=\"#ffffff\" fill-rule=\"evenodd\" points=\"1093.875 550 1101.875 558 1093.875 566 1092 564.125 1098.125 558 1092 551.875\"><\/polygon>\n                    <\/svg>\n                <\/div>\n            <\/div>\n            <div class=\"iframecontainer__iframe\">\n                <div class=\"iframecontainer__iframe__inner\">\n                    <p>This downloadable article about project management methodologies outlines the differences between agile, traditional and hybrid and will help you to choose the right method for your project.<\/p>\n<p>Please fill in the form.<br \/>\n<span style=\"font-size: xx-small;\">* Required Fields\u00a0 |\u00a0 <a href=\"https:\/\/www.theprojectgroup.com\/en\/data-protection\" target=\"_blank\" rel=\"noopener\">Data Protection<\/a><\/span><\/p>\n<div class=\"cookieconsent-optout-marketing\">This form is blocked by your cookie settings to our website. Please <a>click here<\/a> and select at least the marketing cookies. Then this form will be visible. Thanks a lot.<\/div>\n\n                \t<!-- ENGLISCH Wichtig: nur den Code in download-asset \u00e4ndern - definiert Download -->\r\n<script type='text\/x-ccm-loader' data-ccm-loader-src=\"https:\/\/js-eu1.hsforms.net\/forms\/embed\/developer\/146642994.js\" defer><\/script>\r\n\r\n<div class=\"hs-form-html\"\r\n     data-download-asset=\"CU5E\"\r\n     data-region=\"eu1\"\r\n     data-form-id=\"ed0008c7-47d5-4c2e-ad2f-000bd95b74c5\"\r\n     data-portal-id=\"146642994\"><\/div>\r\n\r\n<script>\r\n(() => {\r\n  const FORM_ID = 'ed0008c7-47d5-4c2e-ad2f-000bd95b74c5';\r\n  const FIELD   = '0-1\/download_asset';\r\n  const roots   = new Set();\r\n  const formsByRoot = new WeakMap();\r\n\r\n  const setViaApi = (root) => {\r\n    const code = root.dataset.downloadAsset || '';\r\n    const form = formsByRoot.get(root);\r\n    if (!code || !form) return;\r\n    form.setFieldValue(FIELD, code);\r\n  };\r\n\r\n  window.addEventListener('hs-form-event:on-ready', (event) => {\r\n    if (!window.HubSpotFormsV4) return;\r\n    const form = HubSpotFormsV4.getFormFromEvent(event);\r\n    if (!form || form.getFormId() !== FORM_ID) return;\r\n\r\n    const root = [...roots].find(r => r.contains(event.target));\r\n    if (!root) return;\r\n\r\n    formsByRoot.set(root, form);\r\n    setViaApi(root);\r\n  });\r\n\r\n  window.addEventListener('message', (event) => {\r\n    const d = event.data;\r\n    if (!d || d.type !== 'hsFormCallback' || d.eventName !== 'onFormSubmit') return;\r\n    if (d.id !== FORM_ID) return;\r\n\r\n    roots.forEach(setViaApi);\r\n  });\r\n\r\n  document.addEventListener('DOMContentLoaded', () => {\r\n    document.querySelectorAll('.hs-form-html[data-download-asset][data-form-id=\"' + FORM_ID + '\"]')\r\n      .forEach(r => roots.add(r));\r\n  });\r\n})();\r\n<\/script>\n                    <style>\/* Kompaktere Darstellung f\u00fcr HubSpot Formulare *\/\n[data-hsfc-id=\"Renderer\"] .hsfc-Step .hsfc-Step__Content { padding: 0 20px 20px !important; }\n[data-hsfc-id=Renderer] .hsfc-TextField>*:not(:last-child) { margin-bottom:4px !important; }\n[data-hsfc-id=\"Renderer\"] .hsfc-Row { gap: 20px !important; margin-bottom: 12px !important; }\n[data-hsfc-id=\"Renderer\"] .hsfc-NavigationRow { margin-top: 6px !important; }\n[data-hsfc-id=\"Renderer\"] .hsfc-TextInput { padding: 8px !important; }<\/style>\n                <\/div>\n            <\/div>\n        <\/div><h2 id=\"Chapter2\">What Is a \u201cProduct Owner\u201d?<\/h2>\n<p>An agile team does not have to be a Scrum team. It can simply be a group of people that work together using Kanban. It can also be a team that employs hybrid elements and combines agile and traditional procedures.<\/p>\n<p>In any case, there is normally one person who bears responsibility for clarifying, documenting and communicating the requirements. This role is often called <strong>\u201c<a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/product-owner\/\" target=\"_blank\" rel=\"noopener\">product owner<\/a>\u201d<\/strong> even in non-Scrum teams.\u00a0 However, \u201crequirements engineers\u201d, \u201cbusiness analysts\u201d or simply \u201ccustomers\u201d can also assume this role. For simplicity\u2019s sake, we will refer to this role as \u201cproduct owner\u201d in this article.<\/p>\n\n    <p class=\"datamintsbanner\">\n        <a href=\"https:\/\/www.theprojectgroup.com\/en\/project-management-newsletter\" target=\"_blank\" class=\"datamintsbanner__link\" title=\"Project Management Newsletter TPG PMO Resource Management Agile PM Project Projects Projectmanager Projectmanagementoffice\" style=\"display: block;\">\n            <img decoding=\"async\" src=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2022\/08\/TPG_Banner-Blog_1400_Newsletter_EN.jpg\" class=\"datamintsbanner__image\" style=\"display: block; max-width: 100%\">\n        <\/a>\n    <\/p>\n    \n<h2 id=\"Chapter3\">Contract Model for Agile Projects: Who Chooses the Product Owner?<\/h2>\n<p>Cross-corporate Scrum teams are actually the norm and might even be considered more common than single-company teams. Many agile teams are therefore faced with the challenge of implementing the Scrum team\u2019s rules and ideals without having the corresponding guidelines.<\/p>\n<figure id=\"attachment_2856\" aria-describedby=\"caption-attachment-2856\" style=\"width: 636px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-1-1.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-2856 size-full\" src=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-1-1.png\" alt=\"Collaboration faces a major challenge: creating an agile team involving different companies\" width=\"636\" height=\"360\" srcset=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-1-1.png 636w, https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-1-1-300x170.png 300w\" sizes=\"(max-width: 636px) 100vw, 636px\" \/><\/a><figcaption id=\"caption-attachment-2856\" class=\"wp-caption-text\">Image: Collaboration faces a major challenge: creating an agile team involving different companies<\/figcaption><\/figure>\n<blockquote><p>Further reading: <strong>What Is a <a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/product-owner\/\" target=\"_blank\" rel=\"noopener\">Product Owner<\/a> &amp; What Is Their Role in an Agile Team?<\/strong><\/p><\/blockquote>\n<p>The first step is to clarify which of the contracting parties chooses the product owner. This is important with regard to the customer collaboration over contract negotiation and involves asking the following questions:<\/p>\n<ul>\n<li>How good is the relationship between the client and the supplier? Will the product owner representing the customer be able to work closely enough with the development team and able to guarantee that he \/ she will be available as much as needed? And: Do the product owner and the developers trust each other, or is there an air of mistrust?<\/li>\n<li>Who knows the stakeholders well and understands their needs? Who really understands the market? This should generally be the company commissioning the work.<\/li>\n<li>On the other hand, who knows the development team well and is familiar with its methods?<\/li>\n<li>Who is best able to translate and prioritize the client\u2019s requirements at the implementation level?<\/li>\n<li>How knowledgeable about agile methods are those involved? Is there someone on either side who has experience with being a product owner?<\/li>\n<\/ul>\n<p><strong>The arguments for having the product owner be someone on the supplier side are:<\/strong><\/p>\n<ul>\n<li>Technical skills<\/li>\n<li>Proximity to the implementation team<\/li>\n<li>Familiarity with internal development processes<\/li>\n<\/ul>\n<p><strong>On the other hand, the arguments for having the product owner be someone on the client side are:<\/strong><\/p>\n<ul>\n<li>Proximity to the market, the end customers \/ stakeholders, the requirements<\/li>\n<li>\u201cPower\u201d or authority through their position as a paying client<\/li>\n<\/ul>\n<blockquote><p><strong>Our tip:<\/strong>\u00a0The best strategy is to discuss the distribution of roles with the contractor and client already during the contract negotiations and then document this in the contract. It becomes even more essential to <strong>clearly define the distribution of roles<\/strong> if you decide that the product owner responsibilities should be divided between the contracting parties. We cannot emphasize this enough, because some of the most severe conflicts involving multiple companies occur in projects where the roles were not clearly defined. This can often have legal repercussions.<\/p><\/blockquote>\n<blockquote><p>Another interesting read: <strong>3 Important <a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/jira-tips-for-product-owners\/\" target=\"_blank\" rel=\"noopener\">Jira Tips for Product Owners<\/a><\/strong><\/p><\/blockquote>\n<h3>What Is a \u201cProxy Product Owner\u201d?<\/h3>\n<p>In addition to selecting a product owner from only one of the contracting parties, there is also the option of choosing a <strong>hybrid solution<\/strong>.<strong>\u00a0<\/strong>This person would then be, for example, a <strong>\u201cproxy product owner\u201d<\/strong>. In this case, there is a product owner from the contractor company and one person from the client company who acts as a liaison to the client.<\/p>\n<p>However, the proxy product owner is generally in a weak position, and therefore has<span style=\"color: #000000;\">\u00a0l<\/span>ittle decision-making authority. This person basically serves as a filter with regard to the requirements.<\/p>\n<p>These and the other characteristics constituting the typical challenges facing a product owner are described by Roman Pichler in his blog article \u201c<a href=\"https:\/\/www.romanpichler.com\/blog\/avoiding-common-product-owner-mistake\/\" target=\"_blank\" rel=\"noopener\">Avoiding Common Product Owner Mistakes<\/a>\u201d.<\/p>\n<blockquote><p><strong>Our tip:\u00a0<\/strong>People finding themselves in the role of proxy product owner and facing problems should try to resolve the situation, as that is the only solution. The person should be granted the <strong>authority<\/strong>\u00a0needed to be a \u201ctrue product owner\u201d, including the authority to make product-related decisions and set priorities, or the role should be given to someone with that authority. At the very least, clearly describe the roles and delineate decision-making responsibilities for them, with an emphasis on communications and alignment between them. Role conflicts will otherwise endanger any efforts to set priorities in the product development.<\/p><\/blockquote>\n<h3>Other Factors You Should Consider in a Contract Involving Agile Projects<\/h3>\n<p>OK, you have now solved the challenge of who is the product owner? Great! Here are a few other things that should be considered in agile contract management:<\/p>\n<ul>\n<li>Shared interests and a partnership based on the <strong>principle of good faith<\/strong> should be documented in writing.<\/li>\n<li>It should be clear to everyone what assumptions and leadership principles will prevail in the project.<\/li>\n<li>Stakeholders at the client\u2019s company should regularly participate in meetings to discuss the details.<\/li>\n<li>The development team should be able to organize itself within the given framework. The team members are the technical experts for the implementation.<\/li>\n<\/ul>\n<h2 id=\"Chapter4\">Overview of Agile Contract Models<\/h2>\n<p>The following sections describe the various contract models that can be used to write a contract for\u00a0agile development services. It also discusses the billing practices for each type of agile contract.<\/p>\n<h3>Fixed-Price Models<\/h3>\n<p>For clients, fixed-price contracts minimize the risk that costs will exceed the budget. However, there are a number of problems with this model for agile projects. Some feel that\u00a0fixed price contracts are not suitable for agile projects for the following reasons:<\/p>\n<ol>\n<li>Not being able to adequately alleviate the risk of missed deadlines or that a product is developed that proves useless for the client.<\/li>\n<li>The use of agile methods requires development that strongly focuses on the client\u2019s needs. However, it is very difficult to reach an agreement on the fixed price if the overall functionality has not even yet been defined.<\/li>\n<li>A fixed-price agile contract often only defines the time frame in which the initial product will be developed. Everything that happens after that point (further development, maintenance and support) is initially ignored.<\/li>\n<\/ol>\n<p>The following document workflows are often used in such contract processes:<\/p>\n<figure id=\"attachment_2857\" aria-describedby=\"caption-attachment-2857\" style=\"width: 638px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-2-1.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-2857 size-full\" src=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-2-1.png\" alt=\"The traditional sequence of documents and processes in project procurement\" width=\"638\" height=\"355\" srcset=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-2-1.png 638w, https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-2-1-300x167.png 300w\" sizes=\"(max-width: 638px) 100vw, 638px\" \/><\/a><figcaption id=\"caption-attachment-2857\" class=\"wp-caption-text\">Image: The traditional sequence of documents and processes in project procurement<\/figcaption><\/figure>\n<p><strong>Specifications<\/strong>\u00a0normally contain important information for the client and are part of the call for bids available to possible bidders. As soon as the collaboration has been agreed, these bidders develop a detailed description of the content and scope (<strong>performance specifications<\/strong>\u00a0or similar). Sometimes this is prepared using a template provided by the client. For agile projects in which the requirements are to be \u201cdiscovered\u201d, these descriptions can actually hinder innovation. In this case, a more \u201clightweight\u201d document like a <strong>product backlog<\/strong>\u00a0can be used.<\/p>\n<h3>Fixed Price with Several Agile Elements<\/h3>\n<p>To adapt a fixed-price model to be more suitable for agile projects, you will have to include several agile principles in it. The following factors can be considered:<\/p>\n<ol>\n<li><strong>Functions\u00a0<\/strong>are not completely defined in the beginning. Each of the contracting parties confirms to the others that they understand this fact.<\/li>\n<li>There is <strong>mutual agreement on the project goals<\/strong>, specifically that there is a shared vision of the product and a roadmap. There is a contractual obligation to continually share information via discussions, and not only by sending documents back and forth.<\/li>\n<li>If problems arise, <strong>cooperative approaches\u00a0<\/strong>are used to solve the problem and the\u00a0<strong>\u201cagile mindset\u201d<\/strong> is emphasized to reduce differences and find common ground. This demands trust and empowerment among all those involved. A reference to an existing approach can be contractually documented. For example, there can be a reference to a Scrum guide if the team uses this as a framework.<\/li>\n<li>The\u00a0<strong>completion criteria\u00a0<\/strong>(Definition of Done) agreed upon by the implementation team together with the product owner and stakeholders can also be included in the contract. However, you should emphasize that these criteria might change during the course of the project. The contracting parties must understand what exactly a <strong>Definition of Done<\/strong>\u00a0is, how this differs from acceptance criteria, and why this represents a <strong>team agreement<\/strong>.\u00a0<strong>Acceptance criteria<\/strong>\u00a0can also be defined in the contract and serve as a basis for the Definition of Done. Lastly, <strong>defined timeboxes<\/strong> for iterations (called \u201csprints\u201d in Scrums) and meetings (and their frequency) can be written into the contract as well.<\/li>\n<li><strong>Clarification of Roles\u00a0<\/strong>and\u00a0<strong>Team Charters<\/strong>\u00a0are other documents that can be included in fixed-price contracts adapted for agile projects.<\/li>\n<li>In lieu of a scope statement or\u00a0<strong>performance specifications<\/strong>, there can be a contractual agreement on the necessity of a <strong>product backlog<\/strong>.<\/li>\n<li><strong>Roles\u00a0<\/strong>are clearly defined for the project and documented in the contract. Also documented is who should participate in which meetings. For example, the contractor and the client can each send a representative to the sprint planning meetings to prevent contractual and unpleasant surprises.<\/li>\n<li><strong>Estimation methods\u00a0<\/strong>can be used in the way that\u00a0<span style=\"font-family: 'Open Sans', Arial, sans-serif; font-size: 14px;\">works\u00a0<\/span>best. You are not required to use agile sizing and relative effort estimations. This is especially true when there are existing methods that have been proven effective. The parties can devote more time to <strong>agile estimates<\/strong>\u00a0if they feel that these would benefit the project. Of course, the parties can also contractually agree to use product or release burndown charts to <strong>measure progress<\/strong>.<\/li>\n<\/ol>\n<h3>Prioritization in Agile Projects<\/h3>\n<p>If the <strong>estimates prove to be wrong<\/strong>\u00a0and problems occur, you need to react. In the worst-case scenario, the project must be prematurely terminated. Otherwise, the service provider must make provisions and reevaluate the project portfolio\u2019s priorities to compensate for any problems that affect the project in order to safeguard its own liquidity.<\/p>\n<p>A good strategy is to evaluate the incoming requirements with regard to risk vs. benefit as follows:<\/p>\n<figure id=\"attachment_2858\" aria-describedby=\"caption-attachment-2858\" style=\"width: 586px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-3-1.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-2858 size-full\" src=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-3-1.png\" alt=\"Matrix for prioritizing requirements in agile projects for clients\" width=\"586\" height=\"340\" srcset=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-3-1.png 586w, https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-3-1-300x174.png 300w\" sizes=\"(max-width: 586px) 100vw, 586px\" \/><\/a><figcaption id=\"caption-attachment-2858\" class=\"wp-caption-text\">Image: Matrix for prioritizing requirements in agile projects for clients<\/figcaption><\/figure>\n<p>Accordingly, more risky work should be completed earlier than other work. This gives you a greater range of options at a time when the incurred expenditures are lower.<\/p>\n<blockquote><p>Need more information on agile PM? <strong>Read about the <a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/agile-retrospective\/\" target=\"_blank\" rel=\"noopener\">agile retrospective<\/a>.<\/strong><\/p><\/blockquote>\n<h3>Agile Fixed-Price<\/h3>\n<p>The examples described so far serve to gradually introduce agile principles in traditional environments and agreements. You also have the option to make the entire contract more \u201cagile.\u201d<\/p>\n<p>With the \u201cagile fixed-price\u201d model, you first describe the contractually agreed <strong>project scope<\/strong>\u00a0as based on the <strong>product vision<\/strong>\u00a0and provide a very rough description of the features.<\/p>\n<p>Those involved then estimate the overall effort using <strong>story points<\/strong>\u00a0and translate these into person-days. This is done, for example, by simulating the first sprint-planning meeting to provide a reference point.<\/p>\n<p>As a safety precaution, the project can still be canceled at this point if you determine that the effort required is too great. Agreements are also reached on the <strong>distribution of risk<\/strong>\u00a0among those involved in the project. Contractors can obligate themselves to realize all the \u201cmust-haves\u201d and only develop additional features if the budget permits it.<\/p>\n<p>A\u00a0<strong>special type<\/strong>\u00a0of contract for agile projects in this context is the <strong>\u201dMoney for Nothing, Change for Free\u201d<\/strong> model\u00a0of <a href=\"https:\/\/en.wikipedia.org\/wiki\/Jeff_Sutherland\" target=\"_blank\" rel=\"noopener\">Scrum co-inventor Jeff Sutherland<\/a>. In this case, the client initially follows the traditional course by defining the requirements, and the bidder then responds by submitting a bid at a fixed price. As the implementation begins, the client assumes the role of product owner and manages the product backlog.<\/p>\n<p>At each sprint review meeting in which the service provider presents the results of the previous iteration, the client \u2212 as is typical in Scrums \u2212 provides feedback and revises the product backlog. However, the fact that this is a project with a fixed-price contract makes it special in that there is an agreement that: for each new requirement added to the backlog \u2212 in the form of a user story \u2212 a requirement with a comparable level of effort must be removed from the backlog. This is the <strong>\u201cChange for Free\u201d part of the contract model<\/strong>.<\/p>\n<p>Another unique characteristic is the <strong>\u201cMoney-for-Nothing\u201d principle<\/strong>.<strong>\u00a0<\/strong>This applies to cases in which the bidder and service provider agree at some point to end further development of the product and terminate their collaboration on this topic. If there is money left in the original budget at this point, the contracting parties split this money in accordance with the percentages previously defined in the contract.<\/p>\n<p>As innovative as this \u201cMoney-for-Nothing\u201d principle is, and despite it being so compatible with the agile development environment, there is still a problem in that the existing processes in most companies do not allow any remaining budget to be distributed.<\/p>\n<p>The \u201cChange-for-Free\u201d idea, on the other hand, has proven to be successful in actual projects.<\/p>\n<h3>Fixed Price: Payment per Sprint<\/h3>\n<p>You can also make your basic contract more agile by reaching an agreement on a payment cycle aligned with the sprint rhythm \u2212 hence, a fixed-price per sprint. In this <strong>\u201cfixed-price per sprint\u201d<\/strong>\u00a0model, the contracting parties essentially have many small fixed-price projects, whereby each iteration represents a mini-product. Each sprint plan leads to a new contract and each review represents an acceptance meeting. The time frame of each sprint is thereby clearly defined. Similar models are frequently used by U.S. regulatory authorities, where they are known as \u201cBlanket Purchase Agreements\u201d or also \u201cIndefinite Delivery \/ Indefinite Quantity\u201d (IDIQ) contracts.<\/p>\n<h3>Time &amp; Materials (T&amp;M)<\/h3>\n<p>In a Time &amp; Materials contract, the client obligates itself to pay the contractor in accordance with the time spent on the work and the materials used. This type of contract is very suitable for agile project situations that lack very detailed information, especially initially.<\/p>\n<p>However, it is vital that the contractor not take unfair advantage of this situation, and remain honest and truthful in <strong>documenting the incurred expenses<\/strong>. The contractor also has less incentive to work effectively. If there is a dispute and the two contracting parties in a T&amp;M project go to court, there is another potential problem in that the relationship could be interpreted as a form of <strong>employee leasing<\/strong>.<\/p>\n<p>One solution could be to adapt the T&amp;M contract to create a \u201cDesign to Cost\u201d or \u201cPay per Productivity\u201d contract.<\/p>\n<ul>\n<li><strong>\u201cDesign-to-Cost\u201d<\/strong> contracts have a fixed budget but a more flexible project scope. This type of contract is especially well-suited to situations where the contractor is able to propose price amenable to them based on their prior experience with similar projects.<\/li>\n<li>In a <strong>\u201cPay per Productivity\u201d<\/strong>contract, the contractor contractually obligates itself to a specific productivity rate based on the agreed criteria. The objective is to provide an incentive to maintain a high standard of product quality. A large portion of the paid productivity is otherwise spent on simple maintenance and rectifying problems. However, this model does not really focus on the client benefit because the teams could theoretically be working very effectively on functionality that does little to benefit either the client or end-user.<\/li>\n<\/ul>\n<h3>T&amp;M: Payment per Sprint<\/h3>\n<p>The\u00a0<strong>\u201cPay what you get\u201d<\/strong>\u00a0model is similar to the \u201cfixed-price per sprint\u201d one. However, there is an explicit agreement that the client will only pay for the deliverables accepted in the sprint review. This works if there is a high degree of trust between the contracting parties.<\/p>\n<p>Otherwise, it generally does not work because the supplier is required to provide the goods and services in advance for the duration of the sprint before getting paid.<\/p>\n<figure id=\"attachment_2859\" aria-describedby=\"caption-attachment-2859\" style=\"width: 475px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-4-1.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-2859 size-full\" src=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-4-1-e1573630741242.png\" alt=\"agile contract: Comparison of a fixed-price model and Time&amp;materials model with regard to the degree of control and the cost risks for the client and supplier\" width=\"475\" height=\"136\" srcset=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-4-1-e1573630741242.png 475w, https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2019\/11\/Screenshot-4-1-e1573630741242-300x86.png 300w\" sizes=\"(max-width: 475px) 100vw, 475px\" \/><\/a><figcaption id=\"caption-attachment-2859\" class=\"wp-caption-text\">Image: Comparison of a fixed-price model and time &amp; materials model showing the degree of control and the cost risks for the client and supplier in an agile contract<\/figcaption><\/figure>\n<blockquote><p>Want to get certified? <strong>Learn about <a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/agile-project-management-certifications\/\" target=\"_blank\" rel=\"noopener\">agile project management certlifications<\/a>.<\/strong><\/p><\/blockquote>\n<h2 id=\"Chapter5\">Other Forms of Hybrid and Customized Contracts for Agile Projects<\/h2>\n<p>There are numerous other hybrid and customized contracts in addition to the most common ones: fixed-price and time &amp; materials. Past experience with agile projects has shown the following ideas to be among those feasible:<\/p>\n<h3>Benefit-Oriented Contract Models<\/h3>\n<p>Developing a value-adding product is one of agile development&#8217;s key objectives. None of the contract models presented so far helps to ensure that this objective is achieved. Legal experts are therefore often relatively unfamiliar with these contract principles. However, these can hold the solution for dealing with the high degree of complexity and uncertainty in today\u2019s software projects.<\/p>\n<p>Cost-benefit relationships must be continually monitored when using such contractual agreements. It must be possible to ensure a reasonable balance between effort and result over a longer period of time.<\/p>\n<h3>Benefit-Oriented Award Agreements<\/h3>\n<p>There are contract models in which the client pays a relatively small daily rate intended to cover the contractor\u2019s costs. To enable the contractor to make a profit, an award is paid whenever an agreed value-in-use goal is reached.<\/p>\n<p>In this case, it must be clear to all involved what the client considers \u201cvalue\u201d and how this is measured. This is done using <strong>impact maps<\/strong>.<\/p>\n<h3>\u201cPay per Use\u201d<\/h3>\n<p>Value-based payment agreements, such as many of today\u2019s SAAS solution licensing models, are also considered value-in-use contract models. These are also suitable for agile projects.<\/p>\n<blockquote><p><strong>Handpicked Content:<\/strong> Read more about how agile methods can make resource management succeed: <strong><a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/agile-resource-planning\/\" target=\"_blank\" rel=\"noopener\">Agile Resource Planning<\/a> \u2013 Can It Reduce Resource Conflicts in Projects?<\/strong><\/p><\/blockquote>\n\n    <p class=\"datamintsbanner\">\n        <a href=\"https:\/\/bit.ly\/4b3Fx51\" target=\"_blank\" class=\"datamintsbanner__link\" title=\"The comprehensive Resource Management Tool\" style=\"display: block;\">\n            <img decoding=\"async\" src=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2024\/06\/Banner-TPG-CoReSuite-EN-6-2024.png\" class=\"datamintsbanner__image\" style=\"display: block; max-width: 100%\">\n        <\/a>\n    <\/p>\n    \n<h2 id=\"Chapter6\">Which Contract Type is Most Suitable?<\/h2>\n<table width=\"614\">\n<tbody>\n<tr>\n<td width=\"113\"><strong>Contract type<\/strong><\/td>\n<td width=\"145\"><strong>Sub-type \/ variation<\/strong><\/td>\n<td width=\"186\"><strong>Characteristics<\/strong><\/td>\n<td width=\"170\"><strong>When suitable?<\/strong><\/td>\n<\/tr>\n<tr>\n<td width=\"113\">Traditional fixed-price<\/td>\n<td width=\"145\"><\/td>\n<td width=\"186\">Rather inflexible: Less suitable if flexibility in the product development is needed<\/td>\n<td width=\"170\">Suitable if the effort can be precisely determined beforehand<\/td>\n<\/tr>\n<tr>\n<td width=\"113\"><\/td>\n<td width=\"145\">Fixed price with agile elements<\/td>\n<td width=\"186\">Still rather inflexible, but it generates an initial awareness of agile concepts<\/td>\n<td width=\"170\"><a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/hybrid-project-management\" target=\"_blank\" rel=\"noopener\">Hybrid project management<\/a> approach, new introduction of agile principles in a traditional environment<\/td>\n<\/tr>\n<tr>\n<td width=\"113\"><\/td>\n<td width=\"145\">Agile fixed-price<\/td>\n<td width=\"186\">Product vision and a rough determination of the features are used to estimate a fixed price. This can work, but there is a risk of problems occurring if the estimates are wrong.<\/td>\n<td width=\"170\">Processes that require a fixed price but for which there is a strong demand to use agile methodology<\/td>\n<\/tr>\n<tr>\n<td width=\"113\"><\/td>\n<td width=\"145\">\u201cMoney for Nothing, Change for Free\u201d<\/td>\n<td width=\"186\">Adds a high rate of change and budget responsibility to a fixed-price project<\/td>\n<td width=\"170\">This model works if there is mutual trust between the contracting parties, a collaboration based on equality, the client is closely involved in the actual work, and the client\u2019s procurement processes allow the use of this model.<\/td>\n<\/tr>\n<tr>\n<td width=\"113\"><\/td>\n<td width=\"145\">Fixed price per sprint<\/td>\n<td width=\"186\">This emphasizes the iterative nature of a Scrum team\u2019s work \u2212 minimal flexibility broken down into sprints<\/td>\n<td width=\"170\">Mutual trust between the contracting parties, empirical data should be available or quickly obtainable<\/td>\n<\/tr>\n<tr>\n<td width=\"113\">Time &amp; Materials<\/td>\n<td width=\"145\"><\/td>\n<td width=\"186\">Payment and invoicing based on expenses incurred. The contractor is flexible as to the work to be performed, which is helpful for agile projects, but there is a risk that something can go wrong.<\/td>\n<td width=\"170\">The client\u2019s trust that the contractor will not abuse this relationship and assurance that this contract model will not be legally skewed to its disadvantage.<\/td>\n<\/tr>\n<tr>\n<td width=\"113\"><\/td>\n<td width=\"145\">Pay what you get<\/td>\n<td width=\"186\">The service provider performs the work in advance of getting paid, and the client only pays if it approves of the result when the sprint ends.<\/td>\n<td width=\"170\">This demands a high degree of trust among the contracting parties so that there are no unpleasant surprises.<\/td>\n<\/tr>\n<tr>\n<td width=\"113\"><\/td>\n<td width=\"145\">Design to cost<\/td>\n<td width=\"186\">Fixed budget, flexible scope, invoiced in accordance with expenses incurred<\/td>\n<td width=\"170\">Applicable empirical data available<\/td>\n<\/tr>\n<tr>\n<td width=\"113\"><\/td>\n<td width=\"145\">Pay per productivity<\/td>\n<td width=\"186\">Payment based on agreed criteria for the assessed productivity rate; content is flexible<\/td>\n<td width=\"170\">Trust that the contractor will develop something actually useful to the client; strong client involvement<\/td>\n<\/tr>\n<tr>\n<td width=\"113\">Purely value-added contracts<\/td>\n<td width=\"145\"><\/td>\n<td width=\"186\">A focus on the client\u2019s needs is one of agile development&#8217;s core principles, and this contract model tries to take this into account.<\/td>\n<td width=\"170\">Good metrics for defining, evaluating and then measuring the added value are available and understood.<\/td>\n<\/tr>\n<tr>\n<td width=\"113\"><\/td>\n<td width=\"145\">Benefit-oriented award agreements<\/td>\n<td width=\"186\">The contractor is paid based on effort and receives an additional incentive for the added value produced.<\/td>\n<td width=\"170\">Good metrics for defining, evaluating and then measuring the added value are available and understood \u2212 if possible, and there is no unpleasant surprise if no award is paid.<\/td>\n<\/tr>\n<tr>\n<td width=\"113\"><\/td>\n<td width=\"145\">Pay per use<\/td>\n<td width=\"186\">SAAS licensing model: the client only pays for the functionality actually used<\/td>\n<td width=\"170\">A project to introduce a license-based software for the client and its subsequent regular use<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<h2 id=\"Chapter7\">Conclusion \u2013 Agile Contract Models<\/h2>\n<p>Projects are unique, temporary endeavors. No single contract model is the best one for every possible project. The project manager and everyone else involved in the contract negotiations must work together to find the model best suited to the situation and environment of that particular project. This is especially true for agile projects, with all their uncertainty.<\/p>\n<p>This article has presented you with a selection of suitable contract models to use as a framework. You now understand the advantages and disadvantages of designating a product owner from either the contractor\u2019s or client\u2019s side. In addition, you have gained an overview of the various agile contract models.<\/p>\n<ul>\n<li>Now you understand the advantages of setting a fixed price or invoicing based on expenses incurred or other metrics.<\/li>\n<li>You have become familiar with several contractual agreements that are well-suited to agile projects, but have also learned about their limitations.<\/li>\n<li>You have also learned about other substantive factors to consider in your cooperation agreements when using the selected contract model.<\/li>\n<\/ul>\n<p>The fundamental importance of the \u201cgood faith\u201d principle is even greater with agile projects than with other projects. Reaching the shared goals demands that the contracting parties cooperate and not try to take advantage of each other.<\/p>\n<p>The motto should always be a <strong>focus on the project\u2019s success<\/strong>. If this is really done, then choosing the most suitable contract model is relegated to a mere necessary formality.<\/p>\n<p><strong>Do you have experience with agile contract models? What, in your opinion, requires particular attention? Please leave us a brief comment.<\/strong><\/p>\n<blockquote><p><strong>Our final tips<\/strong><\/p>\n<p>Get to know the individually adaptable \u201cPPM Paradise\u201d \u2013 the optimal environment for your enterprise-wide project, program, portfolio and resource management. <a href=\"https:\/\/www.theprojectgroup.com\/data\/Downloads_eBooks\/TPG_PPM_Paradise_eBook_EN_-_TPG_TheProjectGroup.pdf\" target=\"_blank\" rel=\"noopener\">Download the eBook now<\/a> (just click, no form).<\/p>\n<p>And sign up for our <a href=\"https:\/\/www.theprojectgroup.com\/en\/project-management-newsletter\" target=\"_blank\" rel=\"noopener\">bi-weekly blog newsletter<\/a> to make sure you receive all our updates.<\/p><\/blockquote>\n<div id=\"id69573c1f19a49\" class=\"iframecontainer iframecontainer--hidden\">\n            <div class=\"iframecontainer__head\" style=\"background: #D60B52!important;\">\n                <div class=\"iframecontainer__head__inner\" style=\"color:#ffffff;\" data-for=\"#id69573c1f19a49\">\n                    <p><strong>Subscribe to TPG BlogInfo:<\/strong> Never miss new practice-oriented tips &amp; tricks<\/p>\n                <\/div>\n                <div class=\"iframecontainer__head__icon\" data-for=\"#id69573c1f19a49\">\n                    <svg width=\"10px\" height=\"16px\" viewBox=\"1092 550 10 16\" version=\"1.1\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" xmlns:xlink=\"http:\/\/www.w3.org\/1999\/xlink\">\n                        <polygon class=\"iframecontainer__head__icon__pfeil\"  data-for=\"#id69573c1f19a49\" stroke=\"none\" fill=\"#ffffff\" fill-rule=\"evenodd\" points=\"1093.875 550 1101.875 558 1093.875 566 1092 564.125 1098.125 558 1092 551.875\"><\/polygon>\n                    <\/svg>\n                <\/div>\n            <\/div>\n            <div class=\"iframecontainer__iframe\" style=\"height: 520px;\">\n                <div class=\"iframecontainer__iframe__inner\">\n                \t<p>Every other week: Receive practical tips in TPG blog posts written by recognized experts in project, portfolio, and resource management.<br \/>\n* Required Fields\u00a0 |\u00a0 <a href=\"https:\/\/www.theprojectgroup.com\/en\/data-protection\" target=\"_blank\" rel=\"noopener\">Data Protection<\/a><\/p>\n<div class=\"cookieconsent-optout-marketing\">This form is blocked by your cookie settings to our website. Please <a>click here<\/a> and select at least the marketing cookies. Then this form will be visible. Thanks a lot.<\/div>\n\n                    <iframe src=\"https:\/\/scnem.com\/art_resource.php?sid=hqvs9.qdei48\" style=\"width: 100%; height: 520px;\"><\/iframe>\n                <\/div>\n            <\/div>\n        <\/div><blockquote><p><strong class=\"alignnone\"><a href=\"https:\/\/www.theprojectgroup.com\/blog\/wp-content\/uploads\/2020\/04\/Antje-058-Bearbeitet_quadrat_Web.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-6274 size-thumbnail alignleft\" src=\"https:\/\/www.theprojectgroup.com\/blog\/wp-content\/uploads\/2020\/04\/Antje-058-Bearbeitet_quadrat_Web-150x150.jpg\" alt=\"\" width=\"150\" height=\"150\" \/><\/a>About the author:<\/strong>Antje Lehmann-Benz, PMP, PMI-ACP, PSM expert is a trainer for project management with a particular focus on agile practices and Scrum seminars. Furthermore, she has experience as a software trainer (Jira, Confluence) and consultant. In addition to teaching frameworks and theory, she is experienced in the use of agile games and practical exercises to reinforce the knowledge gained.<\/p><\/blockquote>\n<p>Read more about Antje Lehmann-Benz on <a href=\"https:\/\/www.linkedin.com\/in\/antje-lehmann-benz\/?locale=de_DE\" target=\"_blank\" rel=\"noopener\">Linkedin<\/a>.<\/p>\n\n    <p class=\"datamintsbanner\">\n        <a href=\"https:\/\/bit.ly\/3IFmguV\" target=\"_blank\" class=\"datamintsbanner__link\" title=\"Microsoft 365 Project Management TPG ProjectPowerPack: Best Practice Solution for Project & Portfolio Management Based on Microsoft 365 & Power Platform\" style=\"display: block;\">\n            <img decoding=\"async\" src=\"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-content\/uploads\/sites\/2\/2025\/05\/csm_PPP_Blog_Banner2_EN_1300px_tiny_8e50efa17d.jpg\" class=\"datamintsbanner__image\" style=\"display: block; max-width: 100%\">\n        <\/a>\n    <\/p>\n    \n","protected":false},"excerpt":{"rendered":"<p>Those using agile methodology first focus on the methods and becoming familiar with the agile roles, work practices and principles. Regardless of which rules you follow though, these rules do not address the collaboration of cross-corporate teams. The following article fills this important gap. You will learn: How cross-corporate collaboration works The advantages and disadvantages<\/p>\n<div class=\"read-more\"><a href=\"https:\/\/www.theprojectgroup.com\/blog\/en\/agile-contract-models\/\" title=\"Read More\">Read More<\/a><\/div>\n","protected":false},"author":22,"featured_media":5644,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[],"_links":{"self":[{"href":"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2851"}],"collection":[{"href":"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-json\/wp\/v2\/users\/22"}],"replies":[{"embeddable":true,"href":"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=2851"}],"version-history":[{"count":43,"href":"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2851\/revisions"}],"predecessor-version":[{"id":7957,"href":"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2851\/revisions\/7957"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-json\/wp\/v2\/media\/5644"}],"wp:attachment":[{"href":"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=2851"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=2851"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.theprojectgroup.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=2851"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}