Getting to Done

Spotting Trouble in IT Projects

When a client reaches out for help, the first question that usually pops up is whether the project is in trouble. Spotting trouble in an IT initiative isn’t a single light‑bulb moment; it’s a process of gathering clues, asking the right questions, and listening for warning signs that often hide behind polite updates and optimistic forecasts. The challenge is that trouble rarely presents itself as a single, obvious flag. Instead, it tends to manifest in subtle ways that can be missed if the focus stays on the headline numbers alone.

One of the most revealing questions I ask is, “How will you know when you’re done?” It forces project leaders to confront a definition of success that may not be explicitly written in any charter. If the answer is vague or missing, that vagueness can become a breeding ground for misunderstandings and scope creep. The absence of a clear completion criterion can lead to endless debates about whether the system is ready for production or whether another feature must be added to satisfy a stakeholder.

Often, stakeholders reply with one of four familiar responses. The first is a lofty statement about quality: “We’ll finish when the product meets our standards.” This idealistic view ignores the fact that quality is a moving target, especially in fast‑moving IT environments. The second is a legalistic focus on requirements: “We’ll finish when we hit every line on the spec.” This treats the spec as a contract and overlooks the realities of changing business needs. The third is a schedule‑driven mantra: “We’ll finish when the deadline hits.” In this scenario, the product may roll out before the business is fully ready to use it. Finally, the fourth response is budget‑centric: “We’ll finish when the money runs out.” This often leads to rushed, incomplete releases that damage the organization’s reputation.

None of these responses captures the full picture. The truth is that the definition of “done” in an IT context is rarely a simple, technical milestone. It hinges on political alignment, stakeholder satisfaction, and business readiness. Without an agreed‑upon end state, project teams spend valuable time and resources chasing a moving target. The resulting confusion can erode trust and delay delivery, even if the technical foundation is solid.

Detecting trouble also means looking beyond the surface of deliverables. A project can deliver code that runs, but if users find it difficult to adopt or if support teams can’t maintain it, the initiative will ultimately fail. To gauge this, I look for patterns such as repeated stakeholder pushback, high defect rates, or recurring delays that don’t seem to be resolved by the team. I also examine the team’s communication channels: Are they transparent? Do they invite open dialogue or hide setbacks behind jargon? A healthy project culture encourages early, honest conversation about risk and uncertainty.

Another clue that trouble may be brewing is the absence of measurable progress indicators. Projects that rely solely on status updates without clear metrics are prone to ambiguity. For example, “on track” can mean different things to different people. One manager might interpret it as being within budget, while another focuses on the number of user stories completed. When progress metrics lack a shared meaning, misalignment grows and the project’s trajectory becomes uncertain.

Finally, a useful diagnostic tool is to conduct a quick stakeholder audit. List all parties involved - product owners, end users, sponsors, developers, support staff, and external partners - and assess how each group perceives the project’s status. If most of them express concern or confusion, the project likely requires intervention. In contrast, if all stakeholders are aligned, you’re probably on a smoother path.

By asking the right questions, paying attention to communication patterns, and evaluating stakeholder sentiment, you can spot trouble early and take corrective action before the project spirals. The goal is to bring clarity to what “done” really means for each stakeholder, so the team can work toward a shared, realistic target rather than chasing an elusive, ever‑shifting goal.

Defining Completion in the Digital Realm

In a physical construction project, completion is easy to verify: a bridge stands, a building’s roof is sealed, and the structure meets safety standards. IT projects lack a tangible endpoint, so the notion of “done” becomes a negotiation of expectations. The true marker of completion is not a line on a codebase but a collective agreement among all parties that the system fulfills its purpose.

When stakeholders claim that a system is finished because it meets the specification, they assume that the spec itself is perfect and complete. However, business realities evolve. A requirement that was once essential may become obsolete, and new constraints can surface that were not envisioned during the initial analysis. Relying solely on a static document can lock the team into a path that no longer serves the organization. The safer approach is to view the spec as a living document that must be continuously validated against current business goals.

Quality‑centric definitions of completion focus on metrics like code coverage, defect density, or performance benchmarks. While these indicators provide objective evidence of technical robustness, they fail to capture user experience, integration with other systems, and operational support. An application can pass all unit tests yet remain unusable if the interface is confusing or the data flow is inefficient. Thus, quality alone is an incomplete story.

Schedule‑driven completion assumes that a fixed deadline guarantees readiness. This overlooks the reality that a team may finish coding before the business is ready to roll out. If the organization lacks the training, data migration plans, or marketing support needed for launch, the system will falter regardless of how well it’s built. Timing, therefore, must be coupled with business preparedness.

Budget‑centric completion, where the project ends once funds are exhausted, often leads to under‑delivered products. When financial resources dwindle, teams may cut corners, skip essential testing, or abandon features that were critical to user acceptance. The resulting product can damage stakeholder confidence and create costly remediation efforts later.

Because none of these narrow definitions capture the full picture, the most reliable indicator of completion is consensus. Each stakeholder group - developers, product owners, end users, support teams, and executives - must certify that the system meets enough of their priorities to be considered finished. This certification process typically involves a review of the system against a shared set of acceptance criteria that cover functional requirements, performance expectations, security compliance, usability, and operational supportability.

During acceptance reviews, stakeholders raise concerns, ask for clarifications, and verify that the system behaves as promised. A signed-off acceptance document is not merely a formality; it signals that the system has been vetted from multiple perspectives and that the risk of post‑launch failure has been mitigated. If a group remains hesitant, the project cannot legitimately claim completion until that hesitation is resolved.

In practice, this consensus approach means that project managers must facilitate open dialogues, create transparent tracking of issues, and foster a culture where stakeholders feel comfortable expressing doubts. It also demands that the team remains flexible enough to adapt to new insights that emerge during testing or user trials. When the final sign‑off arrives, it reflects not only technical readiness but also business alignment and operational readiness.

Ultimately, defining “done” in IT is less about a single milestone and more about a shared, multidimensional understanding of success. By moving beyond single‑faced definitions and focusing on stakeholder consensus, organizations can avoid the pitfalls of premature releases and ensure that the system truly delivers value.

Building a Consensus‑Ready Team

Technical skill is a necessary ingredient for delivering an IT solution, but it is far from sufficient on its own. When completion depends on political alignment, the team’s interpersonal and negotiation capabilities become equally vital. A group that can listen, interpret interests, manage conflict, and negotiate trade‑offs is more likely to guide a project to consensus and ultimately to a successful launch.

Listening goes beyond hearing words; it requires active engagement with both the explicit requests and the underlying concerns. A developer who listens attentively to a product owner will notice that a request for a new feature is driven by customer pressure, not just a wish list item. By confirming this understanding - “So you’re saying the main concern is to stay competitive in the marketplace, not just to add a nice aesthetic change?” - the team can align the technical solution with real business drivers.

Identifying interests is the next step. Stakeholders often articulate needs in terms of goals, but those goals stem from deeper motivations - financial pressure, regulatory compliance, or brand reputation. A project manager who can recognize that a finance team’s insistence on tight timelines stems from a looming audit will view the deadline not as a mere constraint but as a regulatory necessity. This perspective enables the team to prioritize resources and plan mitigation strategies that satisfy the root cause rather than just the symptom.

Managing constructive conflict involves turning disagreements into opportunities for refinement. In the early stages of a project, differing viewpoints are inevitable. The challenge lies in preventing these disputes from escalating into stalemates. A team that encourages a problem‑solving mindset will frame conflict as a chance to evaluate trade‑offs, rather than a battle of personalities. This shift reduces friction, preserves relationships, and keeps momentum flowing toward a shared outcome.

Negotiating trade‑offs is where the rubber meets the road. IT projects rarely have infinite resources, so decisions about scope, quality, schedule, and budget are inevitable. A team that can navigate these negotiations will employ a clear, transparent process that maps each trade‑off to business value. For example, sacrificing a non‑critical feature may free up enough time to conduct a thorough security audit, which has higher risk mitigation benefits. By presenting such cost‑benefit scenarios, the team can secure stakeholder buy‑in and avoid the “run out of money” trap that often leads to rushed releases.

These political skills complement technical expertise in creating a robust foundation for project success. A balanced team - composed of developers, testers, product owners, and support staff - can articulate the project’s technical roadmap while simultaneously managing stakeholder expectations. When everyone on the team understands both the “how” and the “why,” the path to consensus becomes clearer, and the likelihood of reaching a genuine “done” state increases.

To cultivate these skills, organizations can invest in cross‑functional training that blends technical workshops with soft‑skill development. Role‑playing exercises that simulate stakeholder meetings, conflict scenarios, and negotiation sessions provide a safe space for practice. Additionally, establishing a culture that rewards transparency, active listening, and collaborative problem‑solving helps reinforce the behaviors that lead to consensus.

In the end, success in IT projects is a political exercise wrapped in technology. Teams that master the art of listening, interpreting interests, managing conflict, and negotiating trade‑offs are better equipped to navigate the complex terrain of stakeholder expectations and deliver solutions that truly meet business needs.

Paul Glen is an IT management consultant and the author of the award‑winning book Leading Geeks: How to Manage and Lead People Who Deliver Technology (Jossey‑Bass Pfeiffer, 2003). He regularly speaks for corporations and national associations across North America. For more information go to: info@paulglen.com