Engaging as a software consultant with new clients requires drinking from the firehose to learn how the client operates and what is valuable to their business. Every business is different, even those within the same industry.
Part of learning the client’s business and processes requires learning about risks. The success of a software project will often rise or fall based on a shared understanding of risk management.
This shared understanding encompasses how well the consultant understands risks in the business context, shares that knowledge with the client, and considers the risk inherent in services the software uses.
Risk is Part of Understanding a Business
A distinctive of a good consultant is the ability to articulate risks in terms of severity when software development is often approached as a commodity.
Effective consultants will be able to speak with the stakeholders at a business level, even more than at a technical level, to build an understanding of a client's needs.
Budget and delivery timelines can take up a lot of discussions as they’re often key reasons for choosing a particular consultant for the job.
Those reasons provide a quantitative (though predictive and often inaccurate) comparison, but budgets and timelines don't give the stakeholders any idea of how well the consultant understands their business.
Business needs extend beyond cost and scheduled deliverables; they also encompass contingency plans, security considerations, and remediation.
A good consultant will deep dive into existing risks and plans and anticipate potential risks and their severity.
On the Same Page
I don't know how many times I've walked into a business and the first thing they want me to know is, "The computers are down today," “The network is down,” or “The phones aren't working.”
Somewhere, something has stopped functioning, and the business may or may not have procedures to mitigate the outage or personnel trained in those procedures. A mismatch of values and understanding about risk can be disastrous.
As a consultant, it's not fair to the client to leave out risk. What happens if this piece breaks down and has a day-long outage? How much money will be lost? Is it worth bringing another service online for a while to mitigate the outage?
Risk and Services
When designing a software product or platform, we field and integrate many different services over the internet. Reliance on third-party services can help a platform reach operational status much more quickly. No one wants to plan for the platform to go down for any length of time.
But a competent, conscientious consultant, knowing what happens in the real world, doesn't leave that to chance–he asks questions and assesses the risks.
For instance, a lot of companies are beginning to integrate generative AI into their workflows. Let's say you build your workflow on one of the major players, like ChatGPT, Gemini, or DeepSeek.
It's well worth asking the question, what happens if that service goes down hard for a day or two? Or, when you scale to a certain level, what happens if that service is used too much, encounters rate limitations, and the software can't use as much of the service as you would like?
One backup plan is to have multiple AI models online in case of needed failover, but this can greatly increase a project's complexity.
The ideas discussed in a risk management conversation may not be immediately actionable. A client may not want or be able to immediately put resources toward having an operational backup plan that can slide into service at a moment's notice.
However, having the conversation is still valuable because it explores some technical feasibility without the added pressure of an active outage.
Results
Good consultants, especially those at the CTO level, should present the pros and cons of various approaches to risk management.
That starts with classifying various risks from minor annoyances to organizational risks that can bring down a company.
Little one-minute outages here and there may not be a big deal, as long as they don't happen very often. But losing a company's database due to hardware failure and not having a backup - well, that can spell doom.
As the consultant drinks from the firehose of contextual learning, existing and potential risks should become part of the conversation around a proposed software solution.