Functional Based Pricing

The problem is containing dark matter (elements that were neither within nor without the spec but the client assumed were going to be taken care of – “well, obviously we need to be able to export the orders to our accounting system”).

I am looking to take three approaches to optimizing the accuracy of the quotes. Firstly to minimize the number of non-essential questions (not to ask anything that doesn’t directly drive the price of the system – unless it is business questions that would drive the functionality required which is a separate discussion based around our Intent Driven Design methodology). The second is to simplify the process of asking all of the essential questions and the third is to auto-generate a very detailed quote and to explain that anything not documented is not included is not part of the project.

The starting point I am using is a feature model where every feature has an associated price. In fact, I am defining a feature as a piece of customer valued functionality that affects the price I will charge for a project. In that way the distinction between the feature modeler and the configurator is very clear – you use the feature modeler to build the quote and the configurator to capture additional requirements that don’t affect pricing after closing the project (why bother getting any information that doesn’t affect pricing pre-close?!). I am also clustering feature specification around areas (product pricing, shipping, sales tax, etc.) that have historically been the biggest time sinks as they were most prone to dark matter.

I have DSLs to describe objects, attributes, relationships, screens, actions, steps, lists, data types, validations and transformations. I am looking at using screens and objects to drive the pricing of projects meaning that if you want additional attributes or relationships I won’t charge extra, but for each custom object or additional screen there will be a per unit charge to approximate the additional cost and value provided.

In addition, feature will be associated with self-describing metadata, so if you buy a simple cms package it’ll describe all of the screens, objects, attributes and relationships (both required and optional) that are included to make it very clear what people are getting as part of the project. I find that a lot of the custom requirements for a project (maybe 60% for the average project) can be described in terms of these DSLs so we don’t need to spec them upfront, cutting the cost of quotations substantially.

However, there are all kinds of custom functional requirements that don’t fit within these requirements. My initial though is to quote most projects based on feature model plus custom screens, imports, exports, reports and objects and then to ask for anything else that needs to be custom, manually specifying and pricing each additional piece of custom functionality. It doesn’t completely automate the process of quoting customized projects, but as we get custom classes of requirements repeatedly we can either turn them into standard features or new DSLs (perhaps for describing workflow features or notifications) with either no cost or standardized per unit pricing models so that over time a higher proportion of the functionality our clients require will be quotable by our resellers, cutting down our cost per quote and improving the responsiveness of our pricing system.

Anyone else playing with a combination of feature models and DSLs to automate the pricing for features (in the case of DSLs) and classes of functionality (in the case of DSL)?

Of course, there will continue to be plenty of pricing problems this won’t solve, but it seems to me that a combination of granular feature modeling along with DSL “per statement” pricing (per object, per screen, per report, etc.) with well defined rules for what comprises a valid statement in each DSL (if you can’t describe it in the language, you have a custom requirement that needs a custom price) is at least a good first order approximation for functional based pricing. This does NOT include the cost of services (graphic design, copywriting, market consulting, training, usability testing, etc.) but we tend to outsource such functions or let our resellers undertake them (professional services don’t scale as well as software sales) so that isn’t really a requirement of the functional pricing model, and while non-functional requirements can substantially affect pricing, we find that most of our clients aren’t willing to pay the additional costs required for custom guaranteed non-functional requirements (latency, simultaneous users, etc.) other than perhaps for browser compatibility which again isn’t something we deal with as our resellers or partners handle HTML templating.