Feature Risk
Feature Risk is the category of risks to do with features that have to be in your software.
You could also call it Functionality Risk. It is the risk that you face by not having features that your clients need.
Eventually, this will come down to lost money, business, acclaim, or whatever else reason you are doing your project for.
In a way, Feature Risk is very fundamental: if there were no feature risk, the job would be done already, either by you, or by another product.
As a simple example, if your needs are served perfectly by Microsoft Excel, then you don't have any Feature Risk. However, the day you find Microsoft Excel wanting, and decide to build an Add-On is the day when you first appreciate some Feature Risk.
This is the one we've just discussed above: the feature that you (or your clients) want to use in the software isn't there. Now, as usual, you could call this an issue, but we're calling it a Risk because it's not clear exactly how many people are affected, or how badly.
- This might manifest itself as complete absence of something you need, e.g "Where is the word count?"
- It could be that the implementation isn't complete enough, e.g "why can't I add really long numbers in this calculator?"
(At this point, it's worth pointing out that sometimes, the user expects the wrong thing. This is a different but related risk, which could be down to Training or Documentation or simply Poor User Interface and we'll look at that more in Communication Risk.)
Regression Risk is basically risk of breaking existing features in your software when you add new ones. As with the previous risks, the eventual result is the same; customers don't have the features they expect. This can become a problem as your code-base gains Complexity, as it becomes impossible to keep a complete Internal Model of the whole thing.
Also, while delivering new features can delight your customers, breaking existing ones will annoy them. This is something we'll come back to in Reputation Risk.
On the Risk Landscape page I introduced the idea of Market Risk as being the value that the market places on a particular asset. Since the product you are building is your asset, it makes sense that you'll face Market Risk on it:
"Market risk is the risk of losses in positions arising from movements in market prices." - Market Risk, Wikipedia
I face market risk when I own (i.e. have a position in) some Apple stock. Apple's's stock price will decline if a competitor brings out an amazing product, or if fashions change and people don't want their products any more.
In the same way, you have Market Risk on the product or service you are building: the market decides what it is prepared to pay for this, and it tends to be outside your control.
Sometimes, users swear blind that they need some feature or other, but it runs at odds with the design of the system, and plain doesn't make sense. Often, the development team can spot this kind of conceptual failure as soon as it enters the Backlog. Usually, it's in coding that this becomes apparent.
Sometimes, it can go for a lot longer. I once worked on some software that was built as a score-board within a chat application. However, after we'd added much-asked-for commenting and reply features to our score-board, we realised we'd implemented a chat application within a chat application, and had wasted our time enormously.
Which leads to Greenspun's 10th Rule:
"Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." - Greenspun's 10th Rule, Wikipedia
This is a particularly pernicious kind of Feature Risk which can only be mitigated by good Design. Human needs are fractal in nature: the more you examine them, the more differences you can find. The aim of a product is to capture some needs at a general level: you can't hope to "please all of the people all of the time".
Conceptual Integrity Risk is the risk that chasing after features leaves the product making no sense, and therefore pleasing no-one.
Sometimes, features can work for some people and not others: this could be down to Accessibility issues, language barriers or localization.
You could argue that the choice of platform is also going to limit access: writing code for XBox-only leaves PlayStation owners out in the cold. This is largely Feature Access Risk, though Dependency Risk is related here.
Feature Drift is the tendency that the features people need change over time. For example, at one point in time, supporting IE6 was right up there for website developers, but it's not really relevant anymore. Although that change took many years to materialize, other changes are more rapid.
The point is: Requirements captured today might not make it to tomorrow, especially in the fast-paced world of IT.
Feature Drift Risk is not the same thing as Requirements Drift, which is the tendency projects have to expand in scope as they go along. There are lots of reasons they do that, a key one being the Hidden Risks uncovered on the project as it progresses.
Fashion plays a big part in IT, as this infographic on website design shows. True, websites have got easier to use as time has gone by, and users now expect this. Also, bandwidth is greater now, which means we can afford more media and code on the client side. However, fashion has a part to play in this.
By being fashionable, websites are communicating: this is a new thing, this is relevant, this is not terrible: all of which is mitigating a Communication Risk. Users are all-too-aware that the Internet is awash with terrible, abandon-ware sites that are going to waste their time. How can you communicate that you're not one of them to your users?
If this breakdown of Feature Risk seems reductive, then try not to think of it that way: the aim of course should be to delight users, and turn them into fans. That's a laudable Goal, but should be treated in the usual Risk-First way: pick the biggest risk you can mitigate next.
Consider Feature Risk from both the down-side and the up-side:
- What are we missing?
- How can we be even better?
Hopefully, this has given you some ideas about what Feature Risk involves. Hopefully, you might be able to identify a few more specific varieties. But, it's time to move on and look in more detail at Complexity Risk and how it affects what we build.
