Is the Value Worth the Risk?

We need to produce 600+ words, avoid banned phrases. Write in natural human tone.

Let's craft.

The $64,000 Question

When a company sets out to deploy a major IT initiative, it does so with an eye on the benefits that the new system promises. Without those benefits, there would be no reason to start. But most business leaders understand, at some level, that the path to those benefits is not a straight line. The road is littered with uncertainty - technical hiccups, budget overruns, staff resistance, and shifting market conditions. The heart of the decision sits at the intersection of value and risk. It is a simple question that can cost tens of thousands of dollars or more, but the real cost is in the lost opportunity if the risk is not managed properly.

Many vendors push the narrative that value is the only thing that matters. Their sales pitches highlight projected ROI, efficiency gains, and competitive advantage. The language they use is clean, positive, and forward‑looking. That is because the vendor’s control ends at the point where the software is delivered. Beyond that, the responsibility belongs to the customer. Vendors cannot dictate how employees adapt to new workflows, how suppliers respond to new purchase orders, or how budget approvals are negotiated. The only thing they can guarantee is a technically sound product that meets specifications. They do not have the influence to mitigate the human, organizational, or market forces that can derail the projected benefits.

Consider a procurement system upgrade that promises to cut the average purchase cycle from five days to two. The promised value appears clear: shorter cycle times, fewer manual errors, and better vendor visibility. Yet, the implementation must change the way buyers interact with suppliers, how the finance team authorizes payments, and how the IT department handles system integration. If the purchasing staff resists the new interface or suppliers refuse to provide electronic invoices, the cycle time will not shrink. In such a scenario, the projected value evaporates because the risk was not anticipated or mitigated. The vendor may have addressed the technical risk of data migration, but the human risk remains outside their remit.

The cost of ignoring risk is not only financial. Projects can stall, reputations can suffer, and strategic momentum can be lost. When a project falls behind schedule, stakeholders may question the executive team's judgment. If the promised savings never materialize, budget requests for future initiatives may be denied. In these moments, the decision to ignore risk is as costly as any missed dollar of ROI. Therefore, before committing to a $64,000 (or any figure) investment, it is essential to ask: How many of the projected benefits do we realistically expect to realize, and what are the barriers that could prevent us from achieving them?

To answer this question, executives need a realistic, honest dialogue that explores both sides. It requires identifying exactly where the value will come from, measuring the potential gains, and mapping those gains to tangible business outcomes. It also demands a parallel examination of the risk landscape - technical, operational, financial, and cultural. By treating value and risk as two sides of the same coin, organizations can avoid the trap of overpromising and underdelivering.

The next section delves into how a cautious, eyes‑wide‑open mindset helps keep the focus on both benefits and challenges, preventing project derailment at the most critical moments.

Keeping Your Eyes Wide Open

Risk is an inevitable partner of value. The problem is that most organizations treat it as a villain to be feared, rather than a companion that can be managed. When risk is left unspoken, it can seep into the project at moments when decision makers are least prepared to counter it. In many cases, senior leaders treat risk as a taboo subject, fearing that mentioning it will signal weakness or cause the project to collapse before it even starts. Others think that simply ignoring risk will keep the project moving forward, as if risk will evaporate on its own. Both approaches lead to costly surprises later on.

A useful way to look at risk is to imagine it as a storm that can be forecasted and mitigated. If the weather forecaster - our risk assessment team - fails to notice the brewing storm, the organization will be caught off guard. Likewise, if risk is never discussed openly, the organization can find itself unable to react in time when a problem emerges. The result is either a failed project or a project that delivers only a fraction of its promised value.

A real‑world illustration comes from a mid‑size manufacturing firm that rolled out a new enterprise resource planning (ERP) system. The project was scheduled for a three‑month implementation window, with a projected annual savings of $200,000. During the first month, the project team celebrated early milestones and stopped discussing potential blockers. In the second month, an unforeseen regulatory change required the system to track additional data fields, which the original vendor had not accounted for. The team spent weeks scrambling to re‑design the data model, causing a two‑month delay. By the time the system was rolled out, the company had missed the first quarter’s inventory reporting deadline and the promised savings had been delayed for an additional six months. The cost of the delay - lost inventory accuracy, missed opportunities, and the overtime paid to resolve the issue - exceeded the projected savings. If the risk had been discussed earlier, the vendor could have been consulted about the regulatory update, and a solution could have been built into the schedule.

Another example involves a retail chain that implemented a customer relationship management (CRM) platform to streamline sales and marketing. The rollout plan did not account for the fact that the sales team was already overloaded with a new training program. As a result, sales reps struggled to learn the new system, leading to lower adoption rates. The projected 20 percent increase in upsell opportunities never materialized because the risk of low adoption was never surfaced.

The lesson in both cases is that risk must be part of the conversation from day one. When risk is spoken openly, stakeholders can plan for it, allocate resources to mitigation, and keep the project on track. When risk is hidden, stakeholders can feel blindsided by challenges, and the cost of surprise becomes much higher.

There are several ways to keep risk in the spotlight. First, risk discussions should be scheduled into the project cadence, not treated as an afterthought. Second, risk should be documented in a simple format that shows the potential impact and likelihood. Third, the organization should assign a risk owner - someone accountable for monitoring and reporting on each identified risk. Finally, risk should be tied to the project budget and schedule, so that mitigation activities receive the same level of attention as core deliverables.

When risk becomes part of the regular conversation, teams shift from reacting to preempting issues. This proactive stance increases the probability of delivering the promised value, or at least of adjusting expectations in a timely fashion. The next section explains how to structure risk management so that it remains a living part of the project lifecycle.

Managing Risk from Start to Finish

Risk management is not a one‑time checklist; it is an ongoing process that starts before a project is approved and continues long after the system goes live. A structured approach helps ensure that every potential threat is identified, assessed, and treated in a way that balances cost and benefit. The process can be broken down into five interconnected steps, each of which builds on the previous one.

Step one is to clearly define and quantify the expected value. Value statements should be specific, measurable, and tied to business outcomes. For example, “reduce purchase cycle time from five to two days, saving $150,000 annually” is a much stronger statement than “improve efficiency.” By having a quantified target, the team can later determine whether a risk actually threatens to derail that target. In practice, this often means working with finance, operations, and other stakeholders to translate strategic goals into concrete metrics.

Step two is to identify and analyze risks. This involves brainstorming with a cross‑functional team, reviewing historical data, and consulting experts. Each risk is then scored on two dimensions: the probability of occurrence and the severity of impact. A risk that is highly probable and would cause significant disruption must be treated differently from a low‑probability, low‑impact risk. While the process may sound like a spreadsheet exercise, the real value comes from the discussion that surfaces new perspectives. It is common to discover that a seemingly minor risk - such as a single vendor’s delivery schedule - can cascade into a larger problem if the vendor fails.

Step three is to develop a mitigation plan. A mitigation plan is a set of actions that reduce either the probability of the risk or the impact if it materializes. For a technical risk, mitigation might involve running a pilot or acquiring a backup system. For a business risk, it could mean training staff early or securing executive sponsorship. Importantly, mitigation actions are built into the project schedule and budget from the beginning, so that teams do not scramble to find resources later. A good practice is to treat mitigation activities like any other project task: assign owners, set deadlines, and track progress in the same project management tool.

Step four is to create a contingency plan. Unlike mitigation, a contingency plan is triggered only when the risk actually materializes. It defines what actions will be taken to contain damage, how much additional budget will be used, and how much time will be added to the schedule. The key is to reserve the necessary resources in a contingency pool, so that when the event occurs, the response is immediate rather than reactive. Contingency planning also helps stakeholders understand the real cost of risk, which reinforces the importance of the mitigation steps taken earlier.

Step five is ongoing risk monitoring. Throughout the project, the team watches for triggers that indicate a risk is developing. These triggers could be a rising defect count, a shift in vendor delivery dates, or a change in regulatory requirements. Monitoring allows the team to activate the contingency plan early or to adjust mitigation efforts. Effective monitoring requires a risk register that is reviewed in every sprint or milestone meeting, with clear owners for each entry. It also benefits from a culture that encourages team members to raise concerns without fear of reprisal.

The choice of risk management methodology can vary. Some organizations adopt lightweight frameworks that use simple risk matrices, while others employ sophisticated software that calculates risk exposure scores and simulates scenarios. The important part is to pick a method that fits the organization’s size, culture, and appetite for detail. A method that is too complex will be ignored; one that is too simple may miss critical nuances.

Throughout the risk management lifecycle, it is essential to keep communication open. Stakeholders should be regularly updated on the status of risks, mitigation progress, and any changes in risk exposure. Transparency builds trust, which in turn makes it easier to mobilize resources when a contingency plan is triggered. By treating risk management as a continuous conversation rather than a boxed activity, projects stay aligned with the ultimate goal of delivering tangible value.

Your First Step as an Executive

Executive leaders are the gatekeepers of risk and value. The most effective way to create a risk‑aware culture starts with leadership acknowledging risk openly and taking responsibility for it. When executives bring risk into the conversation at the earliest stages, they signal that risk is an acceptable part of any ambitious initiative, not a forbidden topic. This shift has a ripple effect: project managers feel empowered to speak up, and team members understand that their concerns are heard and valued.

The first concrete action is to incorporate risk discussion into the project approval process. Before a project moves from the ideation phase to the budgeting phase, executives should require a risk assessment that maps identified risks to mitigation and contingency strategies. This assessment should be presented in a concise, non‑technical format so that all stakeholders, regardless of background, can grasp the implications. By making risk an explicit approval criterion, leaders embed risk awareness into the organizational DNA.

Next, leaders should champion the creation of a risk owner for each high‑impact risk. A risk owner is a person - often a senior manager or project lead - who is accountable for monitoring the risk, updating the risk register, and triggering mitigation actions. By assigning ownership, executives ensure that risks do not remain dormant. Risk owners must be empowered with the authority to request resources or change priorities when a risk threatens to derail the project.

Another critical step is to allocate a dedicated risk budget. Many projects try to squeeze risk mitigation into the project’s regular budget, which can lead to shortcuts or incomplete actions. Instead, executives should carve out a separate contingency fund that is only accessed when a risk materializes. This approach protects the project’s core budget from being stretched thin and ensures that risk responses are timely and effective.

Leaders also need to model transparency when a risk materializes. If a project falls behind, the executive should communicate the reasons openly to stakeholders, explain the mitigation plan, and set realistic expectations for deliverables. This honesty builds credibility and prevents the “damage control” phase from turning into a blame game. Stakeholders learn that setbacks are part of the process, not a reflection of poor leadership.

Finally, executives should institutionalize lessons learned. After every project, teams should hold a retrospective that captures what worked, what didn’t, and how risk was handled. These lessons should be documented in a central repository, linked to future projects, and used to refine the risk management framework. By treating risk management as a living practice that evolves with each project, organizations create a learning culture that continuously improves value delivery.

The combination of clear leadership, dedicated risk ownership, allocated resources, and transparent communication establishes an environment where risk is not feared but managed. Executives who take these steps help their organizations pursue ambitious IT initiatives while keeping the risk of missed value at a manageable level.

Eileen Strider conducts project reviews, project retrospectives, and IT organization assessments based on experience as a developer, project manager, IT manager, and CIO. She provides coaching for business and IT executives and fills in as a temporary CIO. With her partner Wayne Strider, she leads the annual Strider & Cline Leaders' Forum. Her articles have been published in STQE magazine and on Stickyminds.com. To read more articles, go to Strider & Cline Takeaways or contact her at