How We Fix-Price Work
Traditional fixed-price models call for fixing the scope of work before fixing the costs to deliver that work. This typically leads to design overkill as the team tries to understand every little detail upfront before feeling confident to declare a fixed price. Analysis-paralysis results, forever designing and never developing.
And once underway, if the scope changes, the team needs to pause to assess the impact of those changes. This is typically a relatively structured and arduous process that impacts productivity and delays business benefits.
Those disadvantages aside, fixing the scope is completely counter-culture in an agile software development environment. How is it possible to fix the price when the scope is fluid, continually evolving and improving? At Arter Mobilize, we have an answer.
First, some background for context. We find conversations with our customers when designing and developing mobile Apps gravitates to ‘things on a screen’, i.e. the buttons, fields, switches, controls, etc. that appear on the screen. Everything from what they look like to how they behave when touched, swiped, etc. Over time, we have come to appreciate the effort involved in delivering any one of those ‘things’, regardless of the customer situation. So much so, we are now confident assigning a fixed-price to deliver any one of those screen elements, in any situation.
As with fixed-price scenarios in general, we bear the risk associated with the complexity of any one of those screen elements. An “OK” button might be fairly straight forward and simplistic in what it does in one instance and in another it might do or trigger something entirely different and complex. Our customers are assured that an “OK” button will always cost the same regardless of the situation. At a macro, project level, for a total fixed-price our customers can receive a fixed number of screen elements. They pick and choose the screen elements they want for that total fixed-price.
Our fixed-price model resonates very well with customers, particularly if they are not overly technical: the more ‘things” on a screen, the more costly that screen is; the more ‘things’ in the App, the more costly that App is. This empowers product owners with a simple, direct and obvious way to make scope and cost decisions – we provide recommendations and guidance, but the ultimate choice is the customer’s.
For a fixed-price, we deliver a fixed number of screen elements, or features. Our answer to fixing the scope for a fixed-price.
