Approach software, app, and web development projects risk-first. This article presents 6 steps to help you reduce risks before they derail your next development project.
How a software development team plans for and tackles the risk affects a project’s scope, budget, and timeline.
As the CEO of Table XI, a custom software company in Chicago, I find that focusing on monitoring issues and mitigating risks is the best way to keep a project on track.
Someone’s always going to be responsible for taking on the worry associated with risk. If you want to sleep well at night, make sure your software development company has a system in place for tracking and managing risk proactively. It’ll save you stress, and it might save your project too.
This article walks you through how to approach development projects risk-first.
6 Steps to Reduce Software Risks
- Track risks before they escalate, becoming issues that derail a development project
- Address the riskiest parts of the development process first
- Tackle risks immediately by using an Agile development approach
- Create plans for potential risks at the beginning of the project, and share all risks with clients to be transparent
- Track development and client team temperature metrics along with project timeline, budget, and scope
- Encourage open communication and feedback throughout the development process to maintain team morale
1. Track Risks Before They Become Issues
To prevent risks from escalating into issues, begin every development project by identifying all likely risks.
A risk is a behavior or situation that could cause problems for your project, such as preoccupied clients who disagree about the project’s main goal.
An issue is a risk that causes a problem for your project. For example, when the preoccupied clients delay the project.
One approach to tracking risks and preventing them from escalating to problems is to list all the features you plan to develop and evaluate each feature based on three factors:
- Volatility – likelihood that the feature will change
- Completeness – what is known about the feature
- Complexity – how difficult the feature will be to build
Combining relative volatility, completeness, and complexity will give you an idea of the estimated risk for each feature: high, medium, or low.
Risk doesn’t just go away once you’ve identified it though. Throughout the project, keep an eye out for new risks, risks becoming issues, and better ways to mitigate those issues.
2. Tackle the Riskiest Steps in Development Process First
Begin a new development project by tackling the riskiest, most difficult parts first. Identifying potential risks and planning for them early increases the odds a project will meet its deadlines.
3 Tips for Noticing Technical & User Experience Challenges Early
- Visualize high-risk steps in the development process
- Timebox research on high risks
- Perform user research
First, visualize high-risk steps in the development process in a matrix, and track these riskier processes throughout the development process – similar to how a team consistently tracks a project’s budget and timeline. Visualizing high and low risks in a matrix will help your development team prioritize high-risk tasks.
In the risk analysis matrix above, candidate profile and matching are the highest risk features in the project.
If the development team prioritizes these high risks at the beginning of the project, the project is more likely to meet its budget and timeline.
Second, for technical risks and challenges, have the development team perform timeboxed research to find solutions to potential risks.
By focusing on one problem for a fixed period of time, a development team can learn a lot, quickly, instead of getting stuck in the weeds.
Third, for user experience risks or design challenges, learn about your users by interviewing them and tracking how they engage with your product or service.
For example, Table XI is creating a mobile app that connects caregivers with people who want homecare assistance.
Main Risk: Our team didn’t have enough experience in the home healthcare industry.
How Table XI Tackled the Risk: Our team talked to our target users, the caregivers, to learn about the industry.
Result: Conversations with caregivers changed the shape of the project. We went in with assumptions that scheduling would be the most important feature; however, the caregivers told us that the most important aspect was the ability to communicate with each other. If we had ignored that risk, we would have built the wrong product.
3. Use an Agile Approach to Tackle Risks Immediately
The Agile approach to development breaks the development process into bite-sized chunks, leaving room for adjustments when faced with unforeseen risks.
When you cannot anticipate every risk, frontload the most uncertain parts of the development project, such as the caregivers’ needs in our example above.
When you can anticipate a project’s risks, wait to take on the risky parts of the development project until you complete the more valuable and less risky features.
When Table XI partnered with a health-care association on a new education app, our team generated dozens of ideas for what the app might do for the users and the business, including audio, video, and offline features, all of which posed technical risks.
To minimize the risks associated with launching a new product to their customers, the client wisely decided to start with a minimum viable project (MVP) release that deferred work on the more challenging features.
4. Plan for Risk & Communicate Your Plan to Clients
Always build a plan for de-risking a project, and communicate this plan to your clients.
Starting a relationship by listing everything you don't know may seem a little too transparent to some clients. But that level of honesty is important: Everyone involved in a project should know the risks and steps to mitigate the risks.
Tips for Transparent Development Projects
- Maintain an issue and risk log to track how often risks arise and whether they become issues
- Call out “top risks” in your project status reports (even if it makes you uncomfortable)
The development team learns about the unknowns it may encounter, while the client trusts the development team to finish the project. Both sides understand the potential challenges and understand how they will be tackled.
5. Track Team Temperature Metrics Along With Schedule, Budget, Scope
Part of identifying risks is quantifying them or assigning numbers that indicate their likelihood and potential harm.
The big three metrics for a development project include:
However, these three metrics tell you that something already has gone wrong: If your budget is too high or your schedule is overextended, something bad has already happened, and the project is off-track because of it.
To find issues before they affect your project, take a “team temperature” by surveying clients and project team members every two weeks to hear their thoughts on the status of the project.
Ask your clients and development team two questions:
- How are you feeling about your work on the project?
- How do you feel the project is going in general?
If you notice a gap in a person’s answers it’s a sign that something is starting to go wrong: for example, feeling okay about the project but not good about his/her own work.
Other software development shops participate in a version of the team temperature exercise as well.
When Doc Norton, Co-Founder and CEO of tech talent development firm CTO2, spoke on the Table XI podcast, he shared that he measures team joy by asking developers how they feel about the code they just worked on.
Answering the survey only takes one minute every two weeks and responses may uncover unforeseen problems.
6. Encourage Conversations & Feedback About The Development Process
Quantifying risk and expressing empathy complement each other throughout the development process.
For example, a developer who is split between two projects may struggle to switch contexts frequently.
Meetings may overlap, and the developer may end up spending a lot of time going from one "brainspace" to another.
This situation may require a staffing change to refocus the developer’s time and de-risk both projects.
Business processes that improve communication and feedback are important for identifying and quantifying the human element of project risk.
To encourage communication:
- Hold daily standup meetings for every project to create the space for reflection and feedback
- Schedule retrospectives at the end of every product iteration to celebrate what’s going right and to talk about what needs to be adjusted
- Use tools like Slack to increase lines of communication
Take Responsibility for Software Risk by Planning Ahead
Combining honest conversations with quantifiable evidence makes it possible to track and handle risk along with other project metrics, like scope, budget, and timeline.
Then, the product team can clearly tell clients what’s still unknown and what the team will do to address these risky unknowns: additional research, development approach, and task order.
These de-risking efforts add up, allowing a product team to head off problems and deliver completed projects on time and on budget.
About the Author
Mark Rickmeier has managed projects, products, and people for more than 15 years. He is the CEO at Table XI, a UX design and custom software company based in Chicago, and Founder of the Ops-Conf and Walkshop international software retreats.