Over-Promise and Under-Deliver: The Hidden Cost of Unrealistic Project Commitments

In the competitive world of technology and software, promises are currency. Companies promise innovation, efficiency, and transformation to secure deals. But what happens when those promises exceed what can be delivered? "Over-promise and under-deliver" is not just a cliché; it’s a costly pitfall that affects everyone involved in a project.

Let’s explore the repercussions of over-promising, how to identify it early, and what you can do if you find yourself in such a situation.

The Problem with Over-Promising

To win projects, suppliers often overstate the capabilities of their solutions. They may promise features or timelines that their product cannot realistically deliver. This overconfidence can stem from various factors:

• Lack of Suitable Products: The solution isn’t fit for purpose and requires significant modification.
• Underestimating Costs or Timelines: Sales teams downplay the complexity of the project.
• Knowledge Gaps: The supplier doesn't fully understand the client’s requirements or their own product’s limitations.

For the client, the gap between expectations and reality can lead to frustration, wasted time, and wasted resources. For the supplier, the cost is stressed teams and tarnished reputations.

The Impact on Clients

Clients pay the highest price when promises fail to materialize. Here’s how:

1. Wasted Resources: Clients often deploy additional staff to compensate for shortfalls, increasing costs. These resources are diverted from other projects or responsibilities.
2. Frustrated Teams: The client’s employees, often the first to notice issues, scramble to fill gaps, resulting in stress and burnout.
3. Diminished Trust: Stakeholders lose faith in both the project and the supplier, damaging relationships and future collaborations.

The Impact on Suppliers

Suppliers also bear the burden of over-promising:

1. Disjointed Handoffs: Sales teams, who made the lofty promises, often move on to new deals, leaving delivery teams to face the fallout.
2. Pressure on Delivery Teams: Developers and implementers work under intense stress, trying to retrofit unsuitable products to meet commitments.
3. Reputational Damage: Failing to deliver tarnishes the supplier’s credibility, affecting future sales and partnerships.

Early Warning Signs of Trouble

Spotting over-promising early can save a project from disaster. Look for these red flags:

• Missed Deliverables: Early milestones are delayed or skipped entirely.
• Shifting Blame: Teams start pointing fingers, and excuses become frequent.
• Compounded Delays: One delay leads to another, creating a domino effect.
• Rumours and Discontent: On-the-ground staff discuss missing features or limitations compared to the promised solution.
• Gaps in Requirements: Functionalities of the old system are not replicated in the new solution.

What to Do When Things Go Wrong

If a project veers off track, several options are available. None are ideal, but understanding the trade-offs can help you choose the least damaging path:

1. Pull the Plug: If the project is beyond salvageable, cutting your losses may be the wisest choice.
2. Accept a Reduced Scope: Scale back expectations to align with what the supplier can realistically deliver.
3. Learn and Move On: Document lessons learned and apply them to future projects.
4. Refocus on Minimum Viable Functionality: Strip the project to its core essentials, ensuring at least some value is delivered.
5. Deprioritize: Shift focus to other initiatives, letting this project take a backseat while still attempting to salvage some outcomes.

Preventing Over-Promise and Under-Deliver

The best way to avoid these challenges is through thorough preparation and due diligence:

• Validate Supplier Claims: Insist on real-world examples and case studies that demonstrate the supplier’s ability to deliver similar solutions.
• Engage Your Team: Involve your staff early to assess proposals and match them against actual needs.
• Define Requirements Clearly: Document precise requirements and ensure the supplier can meet them.
• Set Gates and Checkpoints: Break the project into phases with clear milestones and validation steps.
• Prioritize Transparency: Establish an open dialogue with suppliers to ensure alignment and realistic expectations.

Conclusion

Over-promising and under-delivering isn’t just a project management issue; it’s a systemic problem that creates stress, wastes resources, and undermines trust. By recognizing the warning signs and taking proactive steps, organizations can protect themselves from falling into this trap.

The key takeaway? Due diligence is your best defence. Understand what you’re buying, involve your team, and ensure the supplier can deliver what they promise. In the end, realistic expectations lead to successful partnerships—and projects that deliver real value.

Software Projects and the Sunk Cost Fallacy: When to Walk Away

The “sunk cost fallacy” is a classic trap that leads organizations to keep investing in projects that are already over budget and behind schedule. In software development, this fallacy can be especially damaging, as costs spiral, returns are uncertain, and the final product has limited resale or tangible value. Yet many teams persist, driven by the belief that they’ve already invested too much to abandon the project now.

This mindset can cause companies to throw more money into projects with diminishing chances of success.

Why Software Projects Are Uniquely Prone to the Sunk Cost Fallacy

Software projects are complex, hard to estimate, and, unlike physical assets, don’t result in a tangible product. This makes them highly susceptible to the sunk cost fallacy.

Intangible Value and Non-Physical Output

• Software lacks the material value of a physical asset. For example, if you build a house and it goes over budget, you at least end up with a physical structure with market value. Software, however, is a set of digital instructions stored on servers. If a project fails, what remains is often worthless—it can’t be sold off or repurposed easily.
• This lack of residual value makes it hard to justify pouring more money into a failing project, yet many teams continue doing so to "complete" something, even if the return on investment is unclear.

Over-optimistic vendors and Scope Creep

• Software vendors can sometimes over-promise to win a contract, painting an overly optimistic picture of the product’s capabilities. When the time comes to deliver, they may struggle to meet the agreed specifications and timeline. In these cases, the vendor might request more money and time to compensate for unforeseen challenges or their own initial overestimation.
• With each delay and budget increase, the customer faces the difficult decision to keep funding the project or cut their losses. However, due to the sunk cost fallacy, decision-makers often feel pressured to stick with the vendor and project, fearing that backing out would mean wasting all previous investments.

Difficulty in Estimation and Scope Creep

• Estimating software projects is notoriously difficult. Requirements frequently change, new features are added, and unexpected complexities arise. Each adjustment drives up the cost, and each delay extends the timeline, yet the project remains incomplete and generates no revenue until launch.
• Scope creep, where the project grows beyond the original plan, is common in software. In the quest to make the investment worthwhile, teams often add more features, which only compounds costs and delays. Ironically, these “extra features” are frequently proposed by the very vendors who oversold the project in the first place, further ensnaring clients in the sunk cost trap.

Labor Costs and Project Management Challenges

• Software development demands highly skilled and highly paid developers, project managers, and testers. When projects fall behind, organizations face the choice of either adding more resources (which drives up costs further) or extending deadlines (which impacts business timelines).
• However, adding more developers doesn’t always work. Additional team members require communication and oversight, which can actually slow down progress. As teams continue spending, the sunk cost fallacy may convince them to keep funding the project, even if a fresh assessment suggests it may not succeed.

No Residual Value in Failure

• Failed software projects offer almost no residual value. In construction, a half-finished building or the land itself still holds some market worth, while a car with issues can be sold for parts. But if you cancel a software project that isn’t functional, all you’re left with is code that may never be used.
• This lack of tangible fallback value can make decision-makers reluctant to pull the plug. Instead, they throw more money into the project, hoping to “get something out of it,” even as the financial return diminishes.

Real-World Examples of Software Sunk Costs Gone Awry

Here are a few common scenarios where software projects fall prey to the sunk cost fallacy:

• Government Software Initiatives: Government software projects are highly visible and politically sensitive, often leading contractors to overstate what they can deliver to win bids. As costs escalate, governments continue funding these projects rather than cancelling them, fearing backlash over wasted taxpayer money.
• Corporate Legacy Systems: Corporations sometimes rely on outdated software that becomes buggy and hard to maintain. Rather than shifting to modern alternatives, they continue funding updates to these legacy systems to avoid the costs of migrating to new platforms, even though this ongoing investment may ultimately be wasteful.
• Healthcare Management Systems: Healthcare software often requires customization to meet complex regulatory needs. As these projects run over budget, providers may feel trapped, continuing to fund projects that are far more expensive than anticipated because switching systems mid-stream would appear even costlier.

Recognizing and Resisting the Sunk Cost Fallacy in Software Projects

Here are some strategies to help identify and avoid the sunk cost fallacy in software projects:

• Conduct Regular Project Evaluations: Schedule periodic evaluations to assess whether the project remains viable. If costs have consistently outpaced projections, reassess whether the end product will still provide the intended benefits. At each major milestone, be prepared to make a tough call if necessary.
• Focus on Minimum Viable Product (MVP): Rather than trying to include every feature originally promised by the vendor, focus on creating an MVP that fulfils the most essential functions. This approach can deliver value faster and help reveal whether the project is worth further investment.
• Prioritize Strategic Value, Not Sunk Costs: Base decisions on future potential, not past expenses. If an objective assessment doesn’t justify further spending, it may be time to pull the plug. Pouring money into a project purely to avoid “wasting” what’s already been spent only leads to further losses.
• Establish Accountability for Vendors: Hold vendors accountable for delivering on their promises. Rather than paying more to accommodate their mistakes or misrepresentations, ensure that contracts include penalties for underperformance or delivery delays. This can help reduce vendor-driven costs that contribute to the sunk cost trap.
• Build Awareness of the Sunk Cost Fallacy: Make sure everyone involved in the project—from stakeholders to project managers—understands the sunk cost fallacy and its dangers. With awareness, teams are better equipped to make objective decisions and focus on the project’s long-term value.

Conclusion

Software projects are particularly vulnerable to the sunk cost fallacy due to their intangible nature, high labour costs, and vendors who may oversell their solutions. Recognizing this risk can help teams avoid the trap of “just a little more” spending when the potential for return is low. In the end, software development should always be guided by future value rather than past expenses. Cutting losses early on may be the smartest move, allowing organizations to allocate resources to projects with clearer paths to success.

Why Every Request Needs a Task: Structuring DevOps Workflow for Success

As a software developer working closely with a third-party team, I rely heavily on structured workflows to stay organized, efficient, and accountable. At the center of this process is Microsoft DevOps, which has been my go-to project planning and management tool for over a year. DevOps provides a centralized “home” for everything I need—whether it’s capturing requirements, managing pipelines, organizing Git repositories, or most importantly, keeping track of work items through tasks.

However, despite all the structure and process that DevOps affords us, I find myself increasingly sidetracked by @mentions—quick pings from colleagues asking me to review code or set something up outside of a formal task. In this post, I’ll explain why relying on @mentions undermines the DevOps workflow and why every request, no matter how "quick," deserves a task of its own.

Microsoft DevOps: A Place for Everything

Microsoft DevOps offers a comprehensive suite for managing development projects. Here’s how I typically use it:

• Features and User Stories to capture high-level requirements.
• Pipelines for managing continuous integration and deployment.
• Git Repository for code versioning and collaboration.
• Tasks, Bugs, and Issues to prioritize and track every actionable item.

Tasks are central to my workflow. I work off my task list, treating each task as a clearly defined unit of work with a deadline, priority, and context. Once a task is completed, it becomes part of my completed task list, which I can reference for historical context or performance tracking. This transparency isn’t just beneficial to me but helps the entire team track progress and allocate resources effectively.

The Problem with @Mentions

Recently, I’ve seen an uptick in requests made through @mentions rather than formal tasks. Examples include:

• “@mention, can you quickly review X?”
• “@mention, could you set up Y?”

The rationale given is often that it’s "just a quick job" or they "just wanted to keep it informal." But here’s the reality: without a task, there’s no commitment, accountability, or visibility.

@mentions create several problems:

• Lack of Structure: An @mention lacks the built-in attributes of a task—no deadline, no priority, no clear scope.
• No Visibility for Others: Other team members can’t see @mentions in the same way they can with tasks, leading to communication gaps and potential bottlenecks.
• Difficulty in Tracking Work: Without a task, I lose the ability to track my work history effectively. The query I run to see my completed tasks won’t include anything asked of me in a stray @mention.

The Ideal Workflow: Why Every Request Deserves a Task

When everyone uses tasks instead of relying on @mentions, it creates a fair, organized, and predictable workflow. Here’s what this approach enables:

1. Clear Expectations: With every request tied to a task, both parties know the deadline, priority, and specific requirements.
2. Transparency for the Team: Tasks make work visible across the team. During daily standups, anyone can view the task list and understand where the project stands.
3. Accountability: A task isn’t just a request; it’s a recorded commitment. This is especially important for project management, as each task can be accounted for and followed up on.
4. Personal Productivity: Having all requests as tasks allows me to prioritize effectively, set realistic timelines, and avoid interruptions from informal requests. It’s easier for me to focus when all work is organized within my task list.

How I Handle @Mentions Now

I’ve started treating @mention requests as casual conversation. I might read them, but unless they are formalized into a task, I won’t action them. In fact, if someone asks if I’ve seen their message, my standard response is, “Did you raise a task for that?” It’s not about being rigid; it’s about creating a sustainable workflow that respects everyone’s time.

Encouraging a Task-Driven Culture

For developers or team members facing similar challenges, here are a few tips to foster a task-driven culture in your DevOps environment:

• Explain the Benefits: Share with your team why tasks make things clearer, easier to track, and ultimately lead to a smoother project flow.
• Lead by Example: Consistently ask for a task to be raised, even for small requests, to reinforce the expectation.
• Stand Your Ground: If a request is made via @mention, politely ask them to create a task with relevant details. Stick to your process, and over time, others will adapt.

Conclusion

Microsoft DevOps is a powerful tool for managing work when used properly. Every request, no matter how small, should be structured as a task. This approach fosters a culture of transparency, accountability, and productivity, ensuring that we spend less time scrambling and more time building. So, the next time you think about sending a quick @mention to a developer—consider creating a task instead. It’s a small change that can make a big difference in everyone’s workflow.

Finding the Balance: Remote Life, Occasional Office Days, and the Joy of Connection

When I made the shift to working from home, it was like discovering a hidden treasure in my own house. For years now, my study—tucked away upstairs—has been my primary workspace, where peace and quiet reign, and where I can focus on coding and problem-solving without the usual office interruptions. Becoming remote wasn’t just a necessary change during Covid; it turned into an unexpected gift. I found myself enjoying the flexibility, the time I got back, and the boost in productivity that comes from being able to focus without distraction. In this cocoon of solitude, I felt more connected to my work and more empowered in my own space.

There’s a certain clarity that comes with remote work, especially for someone like me, a software developer who needs deep concentration and focus to get into the flow. The lack of commute, the comfort of home, and the ability to work undisturbed are all benefits that have helped me thrive. The “come back to the office” chorus, often led by those who prefer to have their teams in sight, doesn’t hold the same allure for me. Productivity speaks for itself; results are measurable. When the work is getting done, and getting done well, it’s easy to question whether office presence is truly necessary. In fact, I’m sure the productivity equation tilts heavily in favour of those quiet hours at home, uninterrupted.

Yet recently, I’ve started going into the office one day a week, just to see if maybe there’s a side to in-office work I’ve been missing. The shift has been... interesting, a mix of unexpected downsides and delightful surprises. True, my productivity dips on these office days. The environment can be distracting compared to my quiet home setup, and the pace doesn’t quite match that of a dedicated day in my study. But what I’ve found—and perhaps even rediscovered—is the joy of in-person connection.

Stepping out the door a little earlier, hopping on a bus, and taking a brisk walk to the office stirs a sense of nostalgia. There’s something refreshingly grounding about leaving the house with a purpose, joining the ebb and flow of people heading to work, and the slow hum of the city waking up. Once there, I get to see colleagues not as tiny, pixelated faces on a screen, but in full, 3D, real-life presence. Today, I even ran into a few people I hadn’t seen in ages, some of whom I’d never even met face-to-face until now. It was strange and wonderful, and yes, there’s a certain buzz, a dopamine kick that can’t be replicated over a video call.

I even enjoyed the mid-morning escape from the desk, ducking out for a sandwich and smoothie, a small ritual that felt indulgent, even celebratory. The office itself was nearly silent—ironic, given that most people are still working from home—but in the quiet, there was a soft reminder of why we all do this work together. As I left at four, with the familiar anticipation of a pub meet-up, I felt a balance I hadn’t in a while. Sitting with a pint at the end of the day, typing this post and waiting for a friend, I can feel that strange joy of shared space and human contact.

Maybe there’s no “best” way to work; perhaps it’s about embracing the mix. I’ll always love my quiet, productive days in the study, the freedom remote work offers, and the way it lets me dive deep without distraction. But these occasional office days add a welcome splash of colour, a reminder of community and connection. And maybe that’s the sweet spot: a life where flexibility reigns, where both the solitude and the soft buzz of connection can coexist, each enriching the other in its own quiet way.

Today, I feel grateful for both worlds and the freedom to choose. Life is good, balanced—and, right now, the world feels like it’s in a good place.