Two Business Cases in One Project: How to Align Client and Contractor Interests
In any project involving a client and a contractor, there are always two independent business cases. When they don't align, it's the primary reason for failure. Here's how to build mutually beneficial collaboration and sidestep common pitfalls.
Why Are There Always Two Business Cases in a Project?
A project kicks off with a request: one side (the Client) defines the task, the other (the Contractor) delivers it. Even within the same company, the project creates two economic entities with their own goals. The Client aims to minimize costs while achieving results. The Contractor seeks to maximize profit while meeting contract terms. These goals are inherently at odds, but the project only works if both sides have a positive business case.
Key point: a business case isn't just a profitability calculation. It's a technical-economic justification that includes:
- Expected outcomes and benefits
- Financial metrics (revenue, costs, margins)
- Risk assessment and impacts
- Alternative scenarios (PRINCE2 requires at least three: "do nothing," "minimum," "optimum")
If business cases aren't formalized or updated during the project, imbalance creeps in. For instance, a Contractor might keep working at a loss, hoping for future bonuses, which leads to quality drops or missed deadlines.
Academic View: Business Case Structure
The PRINCE2 standard defines the business case as a mandatory project artifact. It must provide an objective assessment of project viability and be recalculated at every major change. In practice, though, there's often a gap between theory and reality.
Typical issues:
- Lack of formalization: 70% of projects launch without a detailed business case. Decisions rely on a commercial proposal with simplified calculations.
- Ignoring risks: Profitability is assessed without factoring in risk dynamics. For example, no recalculation happens when timelines or scope change.
- Contract mismatch: Contracts fix only end parameters, not adaptation mechanisms for changes.
To make a business case effective, integrate it into the project charter. Clearly define:
- Triggers for recalculation (scope changes, timelines, market conditions)
- Thresholds for key metrics (minimum margins, maximum labor costs)
- Procedure for approving adjustments
Cultural Differences: How Business Case Prep Affects Success
Company culture shapes attitudes toward business cases. In reactive organizations (where "firefighting" is the norm), it boils down to a couple of numbers in the commercial proposal. In proactive ones, it's a living document that's regularly updated.
Real-world example: In one IT project, the Contractor took a prepayment and started work but didn't recalculate the business case after team reallocation. Result:
- Deadlines missed due to expert shortages
- Costs rose 30% from hiring external resources
- Margins hit zero, but the project dragged on "for reputation's sake"
Solution: Implement regular "business audits" every 2-3 months. During these:
- Compare actuals against forecasts
- Analyze deviations in labor and budget
- Decide on continuation, adjustment, or termination
This approach cuts risks by 40% (per PMI data), but it demands a culture of transparency—where the team admits estimation errors without fear of punishment.
Practical Case: How a Business Case Saved the Project
Consider a real SaaS platform development. The Client demanded tight deadlines; the Contractor gave aggressive estimates in the commercial proposal. Post-kickoff issues:
- Team overloaded with parallel projects
- Key developer quit
- Technical hurdles boosted labor by 25%
The Contractor ignored business case recalculation, hoping to "catch up" later. Outcome:
- 3-month deadline overrun
- 15% budget overrun
- Conflict with Client over quality
What turned it around? A crisis-stage recalculation session:
- Defined the "point of no return": max labor costs for profitability
- Negotiated scope reduction without hurting the MVP
- Introduced weekly margin monitoring
Result: Project wrapped with 8% profit (vs. projected 20%), no losses. Client got a working product; Contractor kept its reputation.
Human Factor: Personal Motives in Projects
Even a perfect business case fails without accounting for the human element. Every project participant has their own "personal business case":
- Sales manager chasing revenue KPIs
- Tech lead seeking professional growth
- Developer focused on salary and stability
Misaligned personal goals spark conflicts. Examples:
- Sales rep promises tight timelines to win the bid
- Tech lead stays quiet on risks to close the deal
- Developer skimps on docs to hit the plan
Solution: Align all levels:
- Project level: Clear KPIs for timelines, budget, quality
- Organizational level: Bonuses for successful completion (not just startup)
- Personal level: Individual goals tied to project ones (e.g., learning new tech on the job)
Key Takeaways
- Two cases, two projects: Client and Contractor are always running separate projects. The contract is their only link.
- Recalculate regularly: Business cases age out every 3-6 months. Ignoring changes leads to losses.
- Find overlap points: Contracts must spell out adjustment terms if business cases shift.
- Factor in humans: Personal motives trump formal KPIs. Aligning interests is the key to success.
— Editorial Team
No comments yet.