Managing risk is a key part of any software development process. As an external consultancy it's even more critical that we manage the risk inherent in our software engineering engagements.
As part of our software development process we dedicate a part of our design and analysis to identifying risk and putting in place strategies to mitigate those risks.
Risk categories
We have categorised the various risks in to 5 categories and broken down each category with the common issues that may arise.
Stakeholder Risk
This category is essentially about whether we have the correct stakeholders engaged with the project. We need to make sure that we have all users of the software properly represented and that decisions can be made to ensure progress on the project.
Technical Complexity
For us, technical complexity can arise from 3 places: the domain of the work itself, the software that's being written and any integrations that are required with 3rd parties. There are mutliple reasons why the domain may itself be complex including unfamiliar contexts, inherent complexity, process change. The software itself could be making use of new technology or pushing the limits of what's possible.
User Experience
Pragmatically, the level of effort expended on a particular feature can be judged based on the users of that particular feature. At one end of the scale you have a piece of functionality that will only be used by a handful of well known users. At the other end of the scale you have features which are to be used by thousands of users. The cost benefit decision for these situations is different as you want to make the experience as intuitive as possible for the thousands whereas you may be able to do a cheaper implementation for the handful and rely on training instead.
InfoSec
When developing software we need to recognise cases where we are potentially making large changes to the security footprint of the software. Does the feature require a new authentication or authorisation mechanism? What type of data is going to be involved and have we considered appropriate regulations (e.g. GDPR). Does the feature provide export functionality of data and how should we protect that from abuse?
External Factors
External factors are those things that we are not directly in control of as the project team. They range from a lack of strategic alignment with the project, to dependencies on other projects, to regulatory changes that could impact us.
How to mitigate these risks
Mitigating these risks is context specific but we try to use the same tools where appropriate. Some of the risks identified above clearly lie outside of the scope of the engineer working on the particular feature.
For the software itself, we rely on the principles of agile delivery around iteratively releasing small features as quickly as possible. This ensures that the cost of misunderstanding is kept as small as possible - we keep our work in progress small.
The key thing across nearly all of these risks is that the engineer identifies the people who need to be involved in decision making: that's client employees, end customers as well as other Abstract Leap employees. Once these people have been identified the engineers makes use of the appropriate tools to minimise the risk of misunderstanding and incurring unnecessary cost.
Practically, the tools we usually rely on are:
- Mockups - for user experience decisions it's quicker to "build" a mockup and get agreement on that before writing any code.
- Process flow diagrams - where the software is automating complex processes it makes sense to articulate them explicitly.
- Preview environments - we use separate dedicated environments for stakeholders to review work in progress.
- Code review process - we make use of code reviews to ensure that the software is built well.
