To find out more about Dan Ariely, check out his website.
A Different Approach
We've rulled out measuring based on our customer's results and on trying to find the 'right' requirements for BAs, so what is left? If it were up to me, I'd do it in two ways, mostly depending upon how much revenue or customer satisfaction is directly attributable to your work or on how much cost you avoided by your efforts.
Let me return to m 'upsell' example from part 1, with numbers that are totally fictional for my organization. Lets say that I determine those upsells are bypassed 100,000 times per day and are only effective 50 times during any given business day. If those upsells produce $2 in extra revenue each, that's $100 per day. If I determine that each upsell takes approximately 5 extra seconds per customer call, then that's 500,000 seconds per day. Divide that up by an average 8 hour shift and you have approximately 17.36 hours at an average cost of $10/hour, making an expense of $173.60 per day. Say that of the $100 in revenue, you only make $15 in profit (before labor is removed) but have $173.60 in labor expense and those upsells start to look like a REALLY bad investment.
Not only could I actually save money by eliminating the upsells, but I save money by having a smaller code base and thus, less maintenance and documentation for developers and analysts. I'm sure there are other costs you could conceivable add in here (electricity, wear on servers, drive space, you get the idea) but the numbers make up the point.
Lets flip the scenario around and assume I figure out a way to make those upsells intelligent by looking at the customer's past order history, the items they're ordering now and the types of products other customers with the same demographic profile and then making smarter recommendations. If I up the number of upsells from 50 to 10,000, then the picture starts to look very different. Suddenly, I'm making $4,000 in profit (again before labor is removed) on $173.60 worth of employee time. When the order takers start to realize how potent of a weapon that upsell is in driving sales, they'll probably pay more attention and use it more, driving even more sales.
Still Not Perfect
Once again we're at a problem in our measurements because how do you know what is directly attributable to your performance and what is not. If you captured the requirement, but it was really the idea of a stakeholder, should you get credit for that? If the developer is the one that did the analysis to find the exact ratio between all the inputs, should all that revenue pot (or a percentage of it) be theirs?
This is where you have to factor in two more items: team and time. You really need to take a look at who was involved and their contribution to each saving or selling that made the difference. Second, you can't do one project, feature or phase, but have to measure over time. You get a slice of every addition you make and then each of those slices are averaged over a long horizon, and I'm talking years here not just a financial period.
By focusing on a team, and I don't mean that in the reporting structure definition of the word, you get lots of other side benefits like cohesion, group survivability, etc plus you remove the problem of needing precise measurements of who added what to each individual project. If someone fails to perform over time, the rest of the team will ensure that they either begin to contribute equally or that the underperformer leaves.
Measuring over time takes away the pressure of the financial cycle and puts the focus on long term health of the business. It also ensures that knowledge stays within a business and, if combined with an HR team that really understands how to recruit and retain top talent, allows for new, high-performing junior team members to gain an immediate foothold and be rewarded for their contributions.
So, am I dreaming here? Does this make sense? Do you have a better idea? Let me know in the comments!