5 min read
Federal IT programs continue to experience cost overruns, schedule delays, and limited adoption. These outcomes persist despite widespread adoption of modern delivery practices, cloud infrastructure, commercial software, and performance-based acquisition strategies. The issue is not a lack of tools or guidance. Over the past decade, agencies have gained more access to both. Yet results remain inconsistent.
Risk in federal IT programs is not primarily technical. It is introduced earlier, through decisions about problem framing, governance, delegation of authority, and acquisition structure. These decisions are made before development begins and are difficult, sometimes impossible, to reverse after award.
Programs rarely fail because of platform limitations or lack of delivery capability. They struggle when authority is diffuse, incentives are misaligned, and oversight prioritizes control over outcomes. In these conditions, modern delivery practices cannot function as intended.
De-risking IT requires deliberate leadership choices. It depends on how authority is assigned, how acquisition vehicles are structured, and how progress is evaluated. The central point is straightforward: most IT risk is created before development begins, and the most effective interventions occur at the leadership and acquisition level.
Agile methods and modern platforms are often positioned as risk mitigation strategies. They can be effective, but only within the right conditions. Agile assumes timely decision making, clear authority, and the ability to adjust based on evidence. When those conditions are absent, teams continue the motions but lose the substance. Progress becomes procedural.
In these environments, activity can obscure risk. Regular cadence creates the appearance of momentum while unresolved issues accumulate. Platforms operate similarly. They constrain design choices but still require prioritization and tradeoffs. When those decisions are deferred, teams compensate through customization, increasing long-term risk. Oversight often lags behind. Progress is measured through plans and artifacts rather than working outcomes, limiting visibility into emerging issues.
Neither agile nor platforms compensate for weak governance. Their effectiveness depends on it.
Acquisition as a Risk-Shaping Mechanism
Common indicators include:
De-risking IT is not achieved through technology selection alone. It is driven by leadership decisions.
Executives influence outcomes most before delivery begins. Decisions about problem framing, delegation, acquisition, and oversight establish the conditions for success.
Programs that perform well share consistent traits:
Most IT risk is created before a line of code is written. The most effective interventions occur at the leadership and acquisition level, where decisions shape everything that follows.
If you want to learn more, contact Steven Lock-Campbell at steven.lockcampbell@veracityit.com or connect with him on LinkedIn to continue the conversation.
Risk in federal IT programs is not primarily technical. It is introduced earlier, through decisions about problem framing, governance, delegation of authority, and acquisition structure. These decisions are made before development begins and are difficult, sometimes impossible, to reverse after award.
Programs rarely fail because of platform limitations or lack of delivery capability. They struggle when authority is diffuse, incentives are misaligned, and oversight prioritizes control over outcomes. In these conditions, modern delivery practices cannot function as intended.
De-risking IT requires deliberate leadership choices. It depends on how authority is assigned, how acquisition vehicles are structured, and how progress is evaluated. The central point is straightforward: most IT risk is created before development begins, and the most effective interventions occur at the leadership and acquisition level.
The Misattribution of IT Risk
When programs encounter difficulty, the explanation often points to technology, vendors, or methodology. In some cases, those factors contribute. In most cases, they do not explain the outcome.
Many struggling programs already use modern infrastructure, commercial products, and experienced delivery teams. These elements are often treated as evidence that risk has been addressed. They are not sufficient on their own.
What is labeled as technical risk is often decision risk. It accumulates through choices that delay commitment, diffuse accountability, or constrain delivery teams. These decisions are typically well-intentioned, balancing oversight and compliance, but they create conditions where failure becomes more likely.
Technology reflects these conditions. It does not create them.
Programs that recover do so when leadership clarifies authority, resets priorities, or realigns incentives. The intervention is structural, not technical.
Many struggling programs already use modern infrastructure, commercial products, and experienced delivery teams. These elements are often treated as evidence that risk has been addressed. They are not sufficient on their own.
What is labeled as technical risk is often decision risk. It accumulates through choices that delay commitment, diffuse accountability, or constrain delivery teams. These decisions are typically well-intentioned, balancing oversight and compliance, but they create conditions where failure becomes more likely.
Technology reflects these conditions. It does not create them.
Programs that recover do so when leadership clarifies authority, resets priorities, or realigns incentives. The intervention is structural, not technical.
Where Risk Enters the Lifecycle
The majority of risk is introduced before development begins.
It often starts with how the problem is defined. Programs that begin with a predetermined solution limit their ability to adapt. Early convergence on a platform or approach, driven by policy, timelines, or prior investments, shapes every downstream decision.
Solution selection can compound this. Commercial software is often viewed as lower risk, but it performs best when agencies align processes to standard functionality. When they do not, customization increases complexity, cost, and dependency.
Platforms do not eliminate this tradeoff. They shift it. Decisions about scope, sequencing, and constraints remain. When those decisions are deferred, complexity surfaces later.
Acquisition strategy reinforces these dynamics. Highly prescriptive solicitations attempt to reduce uncertainty upfront but often lock programs into assumptions that cannot be validated until delivery begins. When conditions change, flexibility is limited.
Programs that manage risk effectively treat early decisions as provisional. They preserve flexibility, align acquisition with learning, and recognize that clarity improves during delivery.
It often starts with how the problem is defined. Programs that begin with a predetermined solution limit their ability to adapt. Early convergence on a platform or approach, driven by policy, timelines, or prior investments, shapes every downstream decision.
Solution selection can compound this. Commercial software is often viewed as lower risk, but it performs best when agencies align processes to standard functionality. When they do not, customization increases complexity, cost, and dependency.
Platforms do not eliminate this tradeoff. They shift it. Decisions about scope, sequencing, and constraints remain. When those decisions are deferred, complexity surfaces later.
Acquisition strategy reinforces these dynamics. Highly prescriptive solicitations attempt to reduce uncertainty upfront but often lock programs into assumptions that cannot be validated until delivery begins. When conditions change, flexibility is limited.
Programs that manage risk effectively treat early decisions as provisional. They preserve flexibility, align acquisition with learning, and recognize that clarity improves during delivery.
The Limits of Agile and Platform-Based Mitigation
Agile methods and modern platforms are often positioned as risk mitigation strategies. They can be effective, but only within the right conditions. Agile assumes timely decision making, clear authority, and the ability to adjust based on evidence. When those conditions are absent, teams continue the motions but lose the substance. Progress becomes procedural.In these environments, activity can obscure risk. Regular cadence creates the appearance of momentum while unresolved issues accumulate. Platforms operate similarly. They constrain design choices but still require prioritization and tradeoffs. When those decisions are deferred, teams compensate through customization, increasing long-term risk. Oversight often lags behind. Progress is measured through plans and artifacts rather than working outcomes, limiting visibility into emerging issues.
Neither agile nor platforms compensate for weak governance. Their effectiveness depends on it.
Delegated Authority as a Risk Reduction Mechanism
Programs that sustain momentum share a common condition: clear, delegated authority.
Decision-making authority is assigned to a single accountable leader, often a product owner or program lead. This role is responsible for balancing priorities and making tradeoffs.
In many programs, authority is fragmented across committees and approval chains. This slows decisions and diffuses accountability.
Effective delegation does not remove oversight. It clarifies it. Leadership sets direction and constraints. Execution-level decisions are made close to the work.
Without this structure, teams either stall or proceed based on assumptions. In both cases, risk increases.
Decision-making authority is assigned to a single accountable leader, often a product owner or program lead. This role is responsible for balancing priorities and making tradeoffs.
In many programs, authority is fragmented across committees and approval chains. This slows decisions and diffuses accountability.
Effective delegation does not remove oversight. It clarifies it. Leadership sets direction and constraints. Execution-level decisions are made close to the work.
Without this structure, teams either stall or proceed based on assumptions. In both cases, risk increases.
Acquisition as a Risk-Shaping Mechanism
Acquisition decisions influence delivery long after contract award.
Highly prescriptive solicitations aim to reduce uncertainty but often shift risk downstream. Vendors optimize for compliance rather than outcomes. Contracts limit the ability to adapt as new information emerges.
Evaluation criteria can reinforce this. Emphasis on documentation and upfront plans selects for proposal strength, not delivery capability.
Performance-based approaches offer an alternative when applied deliberately. By focusing on outcomes and quality indicators, they align incentives and preserve flexibility.
Acquisition does not remove risk. It determines where it sits and how it is managed.
Highly prescriptive solicitations aim to reduce uncertainty but often shift risk downstream. Vendors optimize for compliance rather than outcomes. Contracts limit the ability to adapt as new information emerges.
Evaluation criteria can reinforce this. Emphasis on documentation and upfront plans selects for proposal strength, not delivery capability.
Performance-based approaches offer an alternative when applied deliberately. By focusing on outcomes and quality indicators, they align incentives and preserve flexibility.
Acquisition does not remove risk. It determines where it sits and how it is managed.
Early Indicators of Elevated Risk
Risk signals appear early, often before cost or schedule impacts.
Common indicators include:
| Persistent delays in decision making | Progress that is active but difficult to interpret | Lack of an empowered product owner | Static roadmaps despite new information | Limited visibility into tradeoffs |
These are not delivery issues. They reflect governance and decision-making conditions. Addressed early, they can be corrected. Ignored, they compound.
De-Risking as an Executive Responsibility
De-risking IT is not achieved through technology selection alone. It is driven by leadership decisions.
Executives influence outcomes most before delivery begins. Decisions about problem framing, delegation, acquisition, and oversight establish the conditions for success.
Programs that perform well share consistent traits:
| Early and sustained leadership engagement | Clear delegation of authority | Acquisition strategies aligned to learning and adaptation | Oversight focused on outcomes and evidence |
These practices do not eliminate uncertainty. They make it manageable.
Most IT risk is created before a line of code is written. The most effective interventions occur at the leadership and acquisition level, where decisions shape everything that follows.
If you want to learn more, contact Steven Lock-Campbell at steven.lockcampbell@veracityit.com or connect with him on LinkedIn to continue the conversation.
Related Posts
Driving ServiceNow Client Success with Veracity Support Services
This month, Veracity celebrates 19 years in business, and during that time, we have remained...
Supercharge Your ServiceNow Investment with Veracity Support Services
ServiceNow clients everywhere are investing heavily in their digital transformations. But once the...
From Project Management to Strategic Execution: Why SPM Is Becoming a Leadership Priority
As Veracity approaches its 20th year in business, one principle has remained consistent: project...