The business is pressuring you to implement new IT systems to boost profitability more quickly and efficiently...
than ever before. You don't have the software development expertise in-house, so you must contract with a software development company to get the job done. The business also has a big-picture idea of what it wants to achieve with the new system, but there are many ways to get there. Agile software development's iterative method seems to be a better choice than a waterfall approach to meet the business's objectives. Because there are too many variables for a fixed-price contract to work, some sort of time and materials contract will be required, and the contract will have to provide flexibility for customer input and project modifications throughout the project. But neither can you afford to give the software developer a blank check. Your challenge is to work with legal counsel to create a legal structure that is flexible enough to give the right types of incentives to the software developer but also will provide adequate legal remedies if the developer doesn't perform up to your expectations.
For CIOs faced with this scenario, consider the following approach for Agile contracting:
Craft a story-based RFP. Kick off the process with a request for proposal that presents the "story" of what the software must do. The story should be a high-level description written from the perspective of people who will use the system. The story should be told in sentences and paragraphs, not thought fragments or bullet points. Writing in sentences and paragraphs forces us to think through the goals more thoroughly and results in a more understandable document. The story probably need not be more than a page or two long.
Map out performance criteria. In order to lay the groundwork for Agile contracting, the story should include the most important performance criteria. For example, process 1,000 sale transactions per minute; response to query within 10 seconds. The performance criteria are important because the software developer should consider them at the bidding stage in assessing whether your company's project is feasible and how much it realistically may cost.
Fold the story into the contract. Require an overall system architecture and project plan to be produced in the first sprint. The story is another important part of the Agile contracting process, so the one-to-two page document should be incorporated in the contract. The Agile contract should also require the software developer during the first sprint to design the first iteration of the overall system architecture necessary to achieve the performance criteria. It is important for the parties to identify potential dependencies and develop overall designs to address them that are consistent with performance requirements as early as possible to avoid costly rework down the road.
Require the project plan to be updated as needed after each sprint, with cost and scheduling estimates. The contract should also require that the software developer provide at the end of the first sprint the initial work plan specifying the number of sprints anticipated and the scope of the work to be accomplished during each sprint (project plan), with updated cost and scheduling estimates for each sprint and the project overall. Although the contract should make clear that this first iteration of the project plan can be changed at the end of each sprint as the project progresses, the contract should require that each time the project plan is changed, the software developer is required to estimate the impact of the changes on schedule and budget. With Agile contracting, the budget may increase over time, and actual expenditures may exceed budget, but the software developer will have an incentive to provide you with reasonable estimates (which will assist you in your internal budgeting process) because, as discussed more fully below, the contract will provide that the customer can terminate the software developer's services at the end of any sprint.
Keep an eye on performance and overall architecture throughout the project. Based upon our experience in resolving software development disputes in Agile contracting, it is important to focus on performance criteria and overall system architecture at the beginning of the contractual relationship and as the project progresses and functionality is changed or added: That's because the parties may well be pleased with the functionality of the components developed during individual sprints; however, the integrated system may not work well when performance-tested at the end if performance and design are not top of mind at every stage of the process.
Make the developer responsible for performance problems that crop up at the project's end. To prevent late surprises in Agile contracting -- which are generally are very costly to fix -- the Agile contract should provide that the software developer is responsible for fixing performance problems discovered at the end of the process. Such a provision is fair and equitable because the developer is hired to provide that type of design expertise. Furthermore, assigning the developer with responsibility for fixing performance problems discovered at the end of the process will give the developer additional incentives to assess whether the functionality requested during sprints can be provided consistent with the performance requirements and advise the customer as the project progresses.
Define payment terms that provide an escape clause at the end of each sprint. The contract should provide that at the end of each sprint, the customer can: (a) pay the bill and own the deliverables generated during that sprint; (b) if the customer is dissatisfied with the quality or cost of the deliverables, attempt to negotiate a resolution of the quality or cost issues; or (c) if negotiations are unsuccessful, terminate the contract.
Establish a kill fee, but incent both parties to settle differences. To give the parties additional incentives to attempt to resolve their differences and to provide for an equitable termination if the relationship cannot be saved, the contract should provide that if the customer terminates the contract, the customer must pay the developer for its work on the last sprint but at a lower rate specified in the contract. This rate would substantially reduce the developer's profits with respect to work performed during the last sprint -- an outcome that the developer would want to avoid, if possible. The customer would be required to pay this reduced charge, but would not acquire ownership of the deliverables generated during the last sprint, an outcome that the customer would want to avoid. Accordingly, both the customer and the software developer would have strong incentives to resolve their differences and continue with the project.
Be reasonable about your right to take action against the developer. Under the terms of the contract, the customer will not be able to make a legal claim as to any deliverable after acceptance of the deliverable at the end of the sprint, except if the system as a whole does not perform according to the performance requirements at the end of the process.
Determine how flaws will be addressed if the developer doesn't complete the project. If the contract is terminated before final performance testing, another developer is hired to complete the software and the customer discovers that the original developer's design or coding was defective and had to be fixed to meet the original performance criteria, the original developer is also responsible for paying those repair costs.
This Agile contracting approach is intended to enable parties to realize the benefits of flexible software development processes while achieving the accountability and predictability necessary to make the customer-software developer relationship work from a practical perspective. Time-consuming and expensive legal documentation is avoided in an effective Agile contracting process. The focus is on the software. But the relationship is structured with the correct incentives to get the work done right and at reasonable cost.
About the authors:
Robert Kriss is a partner in international law firm Mayer Brown's litigation and technology transactions practices and has extensive experience representing both suppliers and customers in high-stakes information technology outsourcing and software development disputes. Brad Peterson is a global co-leader of the technology transactions practice at Mayer Brown and has focused his practice for 20 years on helping companies work better with their technology and operations suppliers.
More on managing application development:
Mobile app development skills: Meeting enterprise demand
Build versus buy in creating a DevOps environment
Four things not to do in transitioning to a DevOps culture