Agile product development: Sharing risks and rewards

Product development is mostly in Agile mode where the development is done incrementally prioritizing the features, while being flexible to changes in them and ensuring product quality in each iteration. Product companies develop the product internally and outsource a portion of the work to vendors for a variety of reasons.

Internal product development is budgeted as per business plans associated with the product and managed within the same. Features are prioritized, planned and implemented with product quality in every iteration in Agile mode. This ensures that the product launch can be done at any stage when either the timeline is reached or the budget is exhausted.

For the outsourced portion of the product development, it is a challenge to finalize the budget as the pricing has to be worked out with the external vendor. Pricing in software engineering industry is done in one or a combination of the well-known Fixed Pricing (FP), Time and Materials (TNM), Output based and Outcome based pricing models. Each of these come with their own advantages and disadvantages for the client and the vendor. A suitable pricing model with some variations from the standard models or a hybrid variant is typically worked out as per the context. Agile mode of execution poses additional challenges as requirements are constantly evolving and changes are welcome without the conventional change management clauses. The clients (Product companies) prefer FP so that there is a sense of the cost upfront and in turn the budget for the product development. However, the vendor prefers TNM pricing model as this reduces the chances of cost overruns due to scope uncertainty associated with the agile mode of execution.

In order to address this situation, clients and vendors need to work as partners sharing the risks and rewards by coming to a middle ground between the two extreme positions of TNM and FP. A few ideas the public domain are shared below with references for additional reading.

Clients can accept a TNM pricing initially to refine the specifications, benchmark the sizing of the requirements in terms of story points and such units and understand the stable velocity that the team is able to reach. Subsequently, the vendors can accept a FP per unit of requirements (typically story points) delivered. Because the sizing of the requirements have been benchmarked earlier, efforts per unit output of requirement is expected to be constant. However, there is a chance of effort deviations (overrun / savings). This deviation can be a risk for one party and an opportunity for another. A good approach to address this can be sharing of the risks and the rewards associated with effort deviations since this is not a FP engagement with change request option to address deviations. After each iteration, vendors can be permitted to charge a portion of the effort overrun with a threshold though FP has been agreed per unit of requirement delivered. To be fair to the client, this should be coupled with an offer by vendor to reduce the price (upto a certain threshold) if there was effort savings in an iteration.

Another concern that clients have with TNM is that of the capability and the associated productivity of the team. I have highlighted the challenges in defining and measuring productivity in another post. Assuming that the client and vendor agreed to define and measure productivity, vendor can commit a certain productivity target with an associated reward for doing better than that and an associated penalty if not meeting the productivity target. This would enable clients to choose TNM pricing model with an assurance that the vendor would deliver value for the cost expended and that the priority features would be implemented before the budget or timeline is forcing the project completion due to agile mode of execution.

To manage changes in requirements when FP model is chosen, the total number of story points to be delivered can be maintained as per agreed contract while swapping in priority new requirements and swapping out current requirements which are not priority.

Hybrid pricing is yet another option. Here TNM can be chosen for the portion of software where requirements are still evolving and FP can be chosen for the portion of the software where requirements are clear and technical complexity/uncertainty is minimum. Other combinations of pricing are possible as well in hybrid pricing mode.

In outsourced agile projects, clients and vendors working as partners and sharing the risks & rewards is the way to go!

Few references for additional reading

1. Book, M., Gruhn, V., & Striemer, R. (2012, May). adVANTAGE: A fair pricing model for agile software development contracting. In International Conference on Agile Software Development (pp. 193-200). Springer, Berlin, Heidelberg.
2. Sutherland, J.: Money for Nothing and Your Change for Free: Agile Contracts. Agile 2008 talk, http://www.slideshare.net/gerrykirk/money-for-nothing-agile-2008-presentation
3. https://www.cognizant.com/InsightsWhitepapers/An-Agile-Twist-Fixed-Bid-Pricing.pdf