Some of the methodologies and pricing approaches you will see with outsourcing partners include:<\/p>\n\n\n
Agile contracts<\/a> are fairly common. In that model, there\u2019s 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 <\/em>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. <\/p>\n\n\n\n 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\u2019s challenging, because of COVID or even before a pandemic, this model won\u2019t work as well. Also, the broad requirements -- the \u201cepics\u201d -- need to be broken down into smaller chunks -- \u201cstories,\u201d often -- in the very beginning, otherwise there\u2019s too much complexity and confusion and the project can derail. It\u2019s a very effective model, but it does require collaboration.<\/p>\n\n\n\n Story point pricing<\/a> came around about 10-12 years ago. It\u2019s 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\u2019s a little bit more \u201clive budgeting\u201d 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\u2019s HQ.<\/p>\n\n\n\n One of the big drawbacks of this model is that it over-focuses on the price per hour of the Dev\u2019s work (usually relative to their seniority level). That means lots of other things necessary for a successful sprint are not <\/em>communicated and the focus is too much on \u201cOh, de-prioritize that because it\u2019s too expensive a story point.\u201d<\/p>\n\n\n\n Now, the third model that\u2019s come up recently is outcome-based pricing<\/a>, 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. \u201cThis story will take six months.\u201d The onus is then on the supplier, because they don\u2019t want to deliver in six months and have to spend time fixing their own mistakes. It\u2019s a more quality- and value-driven model. Costs are important and still tracked within this model, but the focus is value.<\/p>\n\n\n\n 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 \u201creference stories,\u201d 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 \u201cblack box.\u201d If they don\u2019t want to focus on some elements, they don\u2019t 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\u2019s the most value-driven model of the three described here.<\/p>\n\n\n\n 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 Modell<\/a>, 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<\/a> 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.<\/p>\n\n\nStory point pricing<\/h2>\n\n\n\n
Outcome-based pricing<\/h2>\n\n\n\n