Whether your software development team is starting a new project from scratch or updating an existing platform, risk is inevitable: miscommunicated expectations, third-party tools that don’t work as promised, feature changes midstream… And we all know that in software engineering, unaddressed risk can mean missed deadlines, blown budgets and disappointed customers.
Clearly, we’ve got to be able to handle risk throughout the development process. So how do we do that successfully? How do we assess risk and then decide on the most efficient steps for mitigating it?
It all starts with identifying risk.
What is risk in software engineering?
Risk in engineering projects can take many forms, but we can get moving with a simple definition.
“Risk in software product development is, basically, any friction that might slow down or jeopardize the delivery of a software product in a timely manner and within the projected budget and scope,” says Jaime Marcial, chief software architect at Modularis.
Modularis likes to categorize software product development risk into three broad buckets:
- people
- process
- technology
Knowing which buckets your team’s risk falls into can help you determine a course of action for addressing those risks and reducing their impact on your project.
People risks
The biggest sources of people-related risks for any software project are—surprise, surprise—communication breakdown and improper leadership.
Maybe you have a far-flung team with remote workers in different time zones who aren’t connecting in a timely fashion. Maybe some of your developers are facing language barriers in addition to different time zones. Perhaps decisions from a meeting simply weren’t passed along effectively. Or maybe a developer on your team is leaving the company right in the middle of a project; knowledge transfers are always complicated. All of these factors can contribute to misunderstood business objectives and dropped timelines.
Process risks
The process through which your team moves its projects can also introduce risk: do you jump in as quickly as possible, favoring carpe diem over a release plan? Are you able to pinpoint the number of developers needed per project objectively through data analysis or is that more of a gut-feel decision? Are you attempting to practice agility without fully grasping what that means?
Remember that being agile as a software development team requires more than just going through SCRUM training; it’s a philosophy rooted in being comfortable with change and being able to pivot when the data says it’s necessary. It’s more than simply dropping everything when the company needs to change directions—it’s being able to truly understand where the change is coming from and then devise a way forward.
Every time a development team has to pivot, new decisions have to be made that affect budget and deadline. And that’s where risks arise.
Technology risks
Any engineer who’s worked with brand-new software or old software that desperately needs updating can offer a couple dozen stories about technology risk.
The drive to keep up with the fast pace of technological development can affect a team coming and going: bleeding edge technology tools you use to build your own projects could have been pushed with bugs that made it through limited testing, and your own developers may battle the same pressure. Then there’s the learning curve of keeping up with the latest, shiniest languages and tools. Does the new thing actually do what it says it will, and even if it does, is it really the best option for the project your team is working on?
Conversely, older software can come with what Marcial calls technical debt. “Technical debt basically comes down to shortcuts that the development team had to take just to meet a deadline on a previous release of the product,” he says. High levels of technical debt slow down development velocity and reduce the ability to innovate.
When it’s time to update software, your team has to choose whether to fix existing problems that have carried over from older iterations, or keep pushing those issues down the road and focus on building new features. Do you spend the time to polish what you have, or do you try to keep up with the pace of the market?
However, if you push the debt forward long enough, the question becomes “do we fix this or scrap it and build something new altogether?” At that point, both options are expensive and full of risk.
How do you lessen the impact of risk?
Of course, these three buckets—people, process, technology—won’t account for every type of risk your development team might encounter. But they’re still a good starting point for considering what potential issues could crop up as you get deeper into your project. Once you know where your risks are hiding, you can begin putting fail-safes in place to mitigate them.
Lessen people risk
We’ve established that risk generated by people is often a product of miscommunication, so set clear strategic objectives as early in the process as possible. These should include what needs to be achieved and why, from the business perspective. As much as possible, show a path forward and the reason behind it.
When you empower your team with effective delegation, they’ll have the context necessary to make technical decisions. Strengthen that delegation with clearly defined accountability, which helps to keep tasks from falling through the cracks.
If you’re encouraging delegation and accountability, you’ll need to make sure feedback is frequent and helpful. Ask your development team to demonstrate their progress regularly. Don’t wait weeks or months to see the product, only to realize that what was built was not what the business needed.
Lessen process risk
One of the areas where clear communication is most crucial for an engineering team is your process. Have a well-defined Product Technology Roadmap that provides a short (one month), medium (one quarter), and a long (one year) term view of your business priorities. Be sure to offer transparency as to how the roadmap aligns with your technology needs.
The overall purpose of this roadmap is to inform the development team what they need to focus on now, but it should also provide enough visibility into the future that they can be on the lookout for opportunities to easily expand the design of the product. If they know what the business is looking for down the road, they’ll be more likely to offer their own insight into what makes sense to accomplish now.
Ask your team to develop in short iterations: design, develop, and deliver on a weekly or bi-weekly basis. The shorter the iteration, the faster you can evaluate if the product is heading in the right direction. Shorter iterations will also allow you to pivot with less friction to meet market changes.
Lessen technology risk
Having a technical roadmap in place goes hand in hand with reducing technology debt. With a defined path forward and short development sprints, your team can avoid costly and inefficient sidetracks.
These measures also ensure that your team has advance notice before jumping into any new tools and languages required for upcoming projects. Evaluate the training time and cost needed for new technologies, or if you can’t afford the extra time and/or cost, play to your developers’ strengths instead and stick with the technology stack for which they have the most expertise.
Additionally, encourage your team to make use of automation. Since so many risks arise from the potential for human error, pursue automation to cut down on those issues quickly. Automate tasks that are better suited for machines—anything repetitive, for example, such as moving code from a developer’s machine to production servers—and save your developers for work that requires creativity and initiative, such as brainstorming new features, paying off that technical debt we talked about, and outlining the next iteration of your company’s product.
In many cases, automation can be the key to de-risking and accelerating software development projects.
Consider a risk management partner
If you and your team need a little help overcoming certain risk factors, or even just getting on the same page about handling risk, it might be time to work with software development experts like Modularis. At Modularis, our mission is to de-risk and accelerate software development for our clients. We’re here to help you identify, minimize, and manage all risks, whether they stem from people, processes, technology, or elsewhere.
All of Modularis’s offerings target risk, whether it’s the 360 Technology Review geared toward organizational risk or the Technology Roadmap which focuses on technology risk. Even in the product design and delivery phases, we can help address risk based around the software development life cycle. And if your project has no room for error, we can help you build your software from scratch.
The importance of risk management in software projects can’t be overstated. But with the right planning, assessment, ongoing monitoring and flexibility, it’s possible to get your software development project off the ground on time, within budget and with as few hiccups as possible.
Get a free risk assessment
Schedule your free risk assessment call with a member of our executive team today!