Some of the methodologies and pricing approaches you will see with outsourcing partners include:
- Agile contracting
- Story point pricing
Agile Contracts
Agile contracts are fairly common. In that model, there’s an initial test phase, and then budget, due date, and the scope are agreed upon. The customer and the supplier define common assumptions about the business value of the IT project, and those shared assumptions created a fixed price scope, before the test phase. In the test phase, implementation begins, and after implementation, the customer and the supplier compare what actually happened with their initial assumptions, which drives the scope and the pricing.
This model can work very well for bigger-scope projects, but there are issues. First, the supplier and the customer need to work really closely together. If that’s challenging, because of COVID or even before a pandemic, this model won’t work as well. Also, the broad requirements -- the “epics” -- need to be broken down into smaller chunks -- “stories,” often -- in the very beginning, otherwise there’s too much complexity and confusion and the project can derail. It’s a very effective model, but it does require collaboration.
Story point pricing
Story point pricing came around about 10-12 years ago. It’s widely accepted in some IT circles. It helps teams prioritize different projects in the sprint, because the customer can see how much it will cost to complete a story point, and thus if some aspect of the sprint is expensive but not immediately essential, they can de-prioritize it. It also requires collaboration, but it’s a little bit more “live budgeting” than an agile contract; things can adjust quickly, even week-to-week, based on the cost of story point and the overall budget at the customer’s HQ.
One of the big drawbacks of this model is that it over-focuses on the price per hour of the Dev’s work (usually relative to their seniority level). That means lots of other things necessary for a successful sprint are not communicated and the focus is too much on “Oh, de-prioritize that because it’s too expensive a story point.”
Outcome-based pricing
Now, the third model that’s come up recently is outcome-based pricing, where costs are less important and the value of the stories is more relevant. Typically in this model, the supplier (the outsourcing partner) will take over the responsibility of timing, i.e. “This story will take six months.” The onus is then on the supplier, because they don’t want to deliver in six months and have to spend time fixing their own mistakes. It’s a more quality- and value-driven model. Costs are important and still tracked within this model, but the focus is value.
One of the major KPIs within the outcome-based model is velocity, or the average amount of stories that the supplier development team can deliver. The customer and supplier create “reference stories,” and the rest of the stories within the sprint are defined off those reference stories. Like the agile model, it requires a lot of trust and collaboration, but the customer can almost look at the DEV work as a “black box.” If they don’t want to focus on some elements, they don’t have to. The focus is on quality of outcome, defined in concert with the supplier, and that is ultimately what the customer will be paying for. It’s the most value-driven model of the three described here.
At Serengeti, we work in an agile framework with DevOps principles, and can design contracts in different ways relative to what the customer and their end users need. Our core value is a Team Extension Model, whereby our team bakes directly into your team to avoid any confusion or distractions during strategic planning, sprints, and stories. We also know that your software development is a crucial part of your business, so we offer a refund policy as well. Those are some of our bigger pricing differentiators in the market, but we can be flexible on the design of contracts, sprints, epics, and stories.
