I remember a quote from John Z Delorean, creator of the iconic Delorean car as seen in the Back to the Future movies. With his backers breathing down his neck to produce his ambitious car in just a few months, he asked legendary Lotus designer Colin Chapman whether he could do it. Chapman asked him which three aspects of the car were non-negotiable. Delorean replied, “Gull wings, stainless steel, rear engine. You can do what you like with the rest.”
But I remember wrong. This was not said to Chapman, but to the purchasing manager of Delorean, Barrie Wills. It was not said as part of negotiations on what the car should be like, but as Delorean was showing Wills around the site that would become the factory. But as Wills tells it, it really does seem like this might genuinely have been the most succinct list of Musts in prioritization history.
Can you imagine getting such a result from a client when asked to come up with a short list of essential features in one of your own projects? How often have you heard someone say ‘We asked them to split the requirements into Musts, Shoulds and Coulds, but 90% came back Must!’. Well, what did you expect? Just try to imagine the pain suffered by the client each and every time they demoted one of their precious darlings from ‘Must!’ to ‘should…’
I had a rare chance to look at the plank in our own eye today through an ongoing post-mortem of a recent project. This post-mortem had identified twenty three technology choices (mostly our choices) that were deemed to be ‘ambitious’, and had identified all of five that were put on hold. That means that we failed to kill 65% of our own precious darlings. So the first lesson here is that this pathology of clinging to our ideas is a shared one that we must own up to and work through together with our client.
Solving this problem is not easy, but it does not require magical skills. The answer comes partly from common experiences in negotiating features with clients, but mostly from my favourite book on management: Don Reinertsen’s Managing the Design Factory.
Every time a client expresses the importance of a particular feature, you can ask why that feature is important, even if it is obvious that it is important. But asking why once is not enough. Ask why the reason given is an important reason until you end up at one of the fundamental drivers of the project. Why do you need this analytics engine? Is it for internal decision-making, or to sell more effectively to individuals? OK, how much do you think you will make with this selling? OK, how much would you make with untargeted selling? The difference is the dollar value of the feature. If they say ‘yes, both selling and internal decision-making’ you can ask about the value of each, and when one turns out to be ten times the value of the other, you can probably both agree that you can ignore the lower-value proposition. If they come out about the same, sadly you’ll just have to add up the values.
Reinertsen identifies four drivers of value and cost in a product: product unit cost, performance, expense and schedule. Reinertsen is talking about designing physical stuff to sell, so if we are dealing with software we might substitute total maintenance cost for product unit cost. We want to identify which drivers are being impacted by each requirement, and by how much. He also identifies that delay can affect different products (or even features of the same product) in different ways: in our analytics example, are you upselling primarily to people who otherwise would just forgo the product? Or are you trying to grab the customer before they go somewhere else? Or is this an emerging market that you are keen to grab a share of? In the first case the time pressure is light; you can deliver this after the product has launched and not lose too much. In the second case there are competitors, you will lose value more-or-less linearly with each week of delay. In the third case, if you miss the mass-market take up, you will have lost the lion’s share of the market in a short time span and so schedule is critical.
So now you and the client share a reasonable guess at each feature’s total value and its depreciation over time. Now you have done the difficult work you can agree a prioritization fairly easily, but also the developers charged with delivering the feature now know how to tailor it for maximum impact, as they can make sub-decisions without having to wait for client input (or having to guess) as they know why the feature is important and how to trade off functionality and performance against timeliness. This can be hugely valuable in building both development speed and client trust.
A performance requirement is similar. Performance requirements are often called “non-functional requirements”, suggesting a certain fuzziness about them. But once you have worked out the effect of missing performance targets you can see that they are far from woolly; if to reach different market penetrations you will need to hit different performance goals, you and the client can build a shared vision of how each millisecond, gigabyte or click counts towards or against the total value you are pushing towards.
So, to remove the plank so that we may see more clearly… how does using Kotlin rather than Java help us deliver this value? How does that stack against the risks? How does using machine learning help verses a simple Bayesian model and how does that compare against the risks? What are the risks? Is it shortfall in performance or delay to the schedule? What is delayed and how much does that impact the overall value?
Doing the hard analysis as requirements are gathered and refined can help us all make those difficult decisions with clear eyes.