Implementation Risk
Risk that the functionality you are providing doesn't match the features the client is expecting, due to poor or partial implementation.
Part Of
Reduced By Practices
- Analysis: Ensures that requirements and specifications are clearly understood before development begins.
- Approvals: Ensures that work meets the required standards and specifications before progressing.
- Automated Testing: Ensures that individual components work correctly.
- Change Management: Avoid bugs from creeping into the system.
- Configuration Management: Establishes and maintains consistency in the software product's performance and attributes.
- Debugging: Identifies and fixes defects in the software.
- Design: Guides the development process, ensuring that the system meets requirements and design specifications.
- Integration Testing: Validates that the implementation meets requirements.
- Issue Management: Tracks and manages defects and issues, ensuring they are resolved.
- Measurement: Identifies areas of improvement in the implementation process.
- Pair Programming: More eyeballs means fewer bugs and a better implementation
- Prototyping: Helps identify potential issues before full-scale development.
- Refactoring: Enhances code quality and maintainability.
- Review: Ensures quality and correctness of work products.
- Runtime Adoption: Ensures consistency and reliability by adhering to proven standards and libraries.
- User Acceptance Testing: Validates that the implementation meets the specified requirements.
- Version Control: Tracks changes and manages versions of the codebase, reducing the risk of implementation errors.
Attendant To Practices
- Coding: Poor coding practices can lead to significant implementation issues.
- Documentation: Poorly documentation can lead to implementation issues in development.
- Review: Can lead to conflicts over quality and implementation details.
- Standardisation: Can introduce complexity and delays during the implementation phase.
The Feature Risk family also includes things that don't work as expected, that is to say, bugs. Although the distinction between "a missing feature" and "a broken feature" might be worth making in the development team, we can consider these both the same kind of risk: the software doesn't do what the user expects. We call these Implementation Risks.
As shown in the above diagram, we can mitigate this risk with feedback from users, as well as further development and testing.
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, documentation or simply a poor user interface (and we'll look at that more in Communication Risk.)