Conceptual Integrity Risk
Part Of
Reduced By Practices
- Approvals: Conceptual issues can be avoided by reviews and approvals
- Design: Provides a clear structure and organization, making the system easier to understand and use.
- Requirements Capture: Helps in explaining exactly what should be built.
- Review: Maintains alignment with design principles and goals.
Conceptual Integrity Risk is the risk that chasing after features leaves the product making no sense, and therefore pleasing no-one.
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. Sometimes the development team can spot this kind of conceptual failure as soon as the suggestion is made, but usually it's in coding that this becomes apparent.
Sometimes it can go for a lot longer. Here's an example: 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.
Feature Phones are another example: although it seemed like the market wanted more and more features added to their phones, Apple's iPhone was able to steal huge market share by presenting a much more enjoyable, more coherent user experience, despite being more expensive and having fewer features. Feature Phones had been drowning in increasing Conceptual Integrity Risk without realising it.
Conceptual Integrity Risk is a particularly pernicious kind of Feature Risk which can only be mitigated by good design and feedback. Human needs are fractal in nature: the more you examine them, the more complexity you can find. The aim of a product is to capture some needs at a general level: you can't hope to anticipate everything. As with the other risks, there is an inherent Schedule Risk as addressing these risks takes time.