I started out as a Tech but as I’ve progressed I’ve had to take on more and more man and project management to the point that it feels like I spend more time helping people than fixing broke computers.
If you work in a support, technical, or specialist role, you’ve probably felt the urge to dismiss a project manager’s status or planning demand with “I’ll get to it later.” or “FFS” but before you do, it helps to remember what drives their behaviour.
Project managers are hired to deliver one outcome, nothing more, nothing less.
Especially in contract roles, their performance is judged almost exclusively on whether the project’s scope, timeline, and budget are met. They aren’t rewarded for keeping infrastructure stability long term or for preserving team morale. They’re rewarded for shipping.
Prioritise deadlines over comfort: If a subject‑matter expert is at capacity, the project manager may still push, because slipping the schedule is costlier to their success and thus them than your overload.
Ignore peripheral fires: Issues that don’t directly block the project often fall outside their remit, even if they matter to you.
Understanding this incentive structure doesn’t excuse poor behaviour, but it does offer practical ways of working with them:
Clarify capacity early: Spell out what’s realistic, agree on trade‑offs, and document them.
Frame updates in impact terms: Explain how delays or scope changes affect the critical path; PMs will adjust if the risk is explicit.
Escalate strategically: When workload or morale is at stake, involve sponsors who balance delivery with sustainability, even offer to talk to the sponsors directly to help fight your case.
A project manager’s laser‑focus can feel abrasive, yet it’s the same focus that keeps initiatives from drifting. Recognise the problems they face, communicate to them within that context, and you will be able to get a better working relationship.
Ever notice that project estimations seem unusually slow or hesitant? Especially when working with a team with a lot of newly hired people in it, one overlooked factor might be the team’s level of historical experience with the specific implementation of this technology or system .
New team members, even if highly skilled and technically competent, may naturally hesitate due to unfamiliarity with the nuances of your particular implementation. They’re often cautious, aiming to avoid mistakes on their first significant project, leading to slower response times or overly conservative estimates.
On the other hand, experienced team members familiar with your systems quirks can quickly assess situations, drawing from past knowledge to provide faster and more accurate quotations.
As a manager or project leader, always factor in the team’s familiarity with your systems when evaluating timelines and performance, not just the raw platform. Offering additional support, training, or pairing new hires with experienced team members can significantly speed up the quoting and decision-making processes.
One persistent challenge faced by technical professionals in many organisations is the pressure to quickly provide project estimates and quotes before adequate information is available. If you’ve found yourself frustrated by unrealistic timelines and vague project scopes, you’re not alone. so here is a guide to help navigate this common issue effectively.
Why Technical Teams Are Asked for Premature Quotes
Typically, this situation arises from organisational structures where business needs are quickly escalated to IT management, who then require immediate answers. The usual questions from management include:
Can this be done?
How long will it take?
How much will it cost?
Realistically, detailed and accurate answers to these questions can require extensive work: proof of concept development, regulatory checks, and feasibility studies, all of which take considerable time and money. Yet, management and the business often expect preliminary estimates within a very short timeframe.
How to Handle Early Project Estimates
Instead of frustration, here’s how you can approach providing an early, preliminary quote:
1. Use Realistic Assumptions
You will inevitably need to make assumptions. To do this well, aim for assumptions that reflect realistic scenarios. A helpful analogy is the question, “How long does it take to travel to Australia?” Although many variables exist, your immediate reaction should not consider extreme scenarios like walking. Instead, you naturally think about common methods, such as flying, use widely available flight times and costs as your baseline.
2. Clearly Document Your Assumptions and Contingencies
Explicitly document all assumptions and known contingencies. For instance:
Clearly state if the quote assumes completion only up to a specific milestone (e.g., arriving at an airport versus a specific city or location).
Highlight known potential blockers such as regulatory or security restrictions.
This approach helps manage expectations and protect against future misunderstandings.
3. Provide a Reasonable Margin of Error
Include explicit language that highlights the preliminary nature of your estimate. Use clear, standardised statements like:
“This estimate has a potential variance of up to ±20%.”
“Final quotation requires a proof-of-concept phase of approximately two months.”
“Security approvals and regulatory checks may significantly impact timelines.”
If you find these notes are frequently removed from presentations by management, formally document these conditions elsewhere (e.g., in emails or follow-up notes).
Common Pitfalls to Avoid
Avoid Extreme Responses
Resist giving overly pessimistic or overly optimistic quotes, as both extremes tend to be ignored or cause pushback from management. Instead, offer balanced, evidence-based estimates.
Don’t Delegate Estimates to the Most Optimistic Team Member
While it’s tempting to delegate unpleasant tasks like estimation to the most helpful person on your team, this often results in overly optimistic estimates. It’s better to have slightly sceptical or more conservative team members lead estimate preparation to ensure realism and accuracy.
Handling Negotiation and Scope Creep
Be prepared for negotiation. Management teams naturally approach quotes as negotiable, even when your technical estimate is realistically calculated without any intentional padding. Counteract potential scope creep or budget reductions by clearly outlining consequences, such as failing compliance or security standards if corners are cut.
Final Thoughts
Early quoting isn’t ideal, but with thoughtful handling, you can provide meaningful preliminary estimates that guide decision-making effectively. Clearly articulated assumptions, contingencies, and evidence-based reasoning can position you as both helpful and realistic, qualities that reinforce your credibility. This means that when inevitable changes need to be made to quotes further on, people are more likely to assume they are reasonable needs.
The integration of goal-based or outcome-driven contracts with agile project management methodologies has become increasingly common, particularly in interactions between large corporations and their vendors.
While this trend may seem like a recent innovation, it’s just a new iteration of a long-standing challenge: balancing flexibility in doing a project (dealing with scope creep, fixing crises, and the like) with the financial certainty that fixed-price contracts provide.
The shift toward goal-based contracts (essentially fixed-price agreements under a new guise ) is primarily finance-driven. The reasons are clear: corporations aim to minimise scope creep and cost overruns.
As project managers, our role involves accommodating these financial constraints while delivering successful outcomes. However, agile methodologies, now the default expectation within many organisations, inherently conflicts with fixed-price agreements (which are better fit to the waterfall methodology).
So how do we reconcile these two seemingly incompatible requirements?
I have found several practical ways to make this work (rather than just saying “Use scaled agile framework (SAFe)” or some other boring reply):
1. Clearly Defined Initial Cost Boundaries Initially, costs must be explicitly fixed. This non-negotiable stance appeases finance departments, preventing early-stage roadblocks. While we know additional costs might arise later, establishing a firm baseline from the outset is crucial. Once you have got the project started, you can get ready to handle extra costs with separate statement of work agreements, but managers and such can get on with these while real people get on with delivery.
2. Shifting Goal Definitions A potential (though problematic) solution involves redefining goals as effort-based rather than strictly scope-based, that is, hire a vendor for a defined period of time with a certain number of people to do the job. Although appealing due to its simplicity, this approach may lead to compliance risks (e.g., IR35 concerns 1 ), particularly for smaller vendors, and can diminish vendor motivation as they know they will not be held to account for anything.
3. Breakdown deliveries into Smaller, Goal-Based Items Another viable approach is segmenting the statement of work into smaller, individually priced items. This method simplifies justification of outcome and billing but can also result in significant administrative overhead and ongoing negotiations.
4. Categorizing Goals by Priority A beneficial strategy involves dividing goals into mandatory and optional categories. Mandatory goals must be completed first, while optional goals can be adjusted or omitted to accommodate scope creep or unforeseen issues without compromising the fixed-price arrangement.
5. Internal Readiness and Client-Side Accountability Implementing an internal readiness firewall can protect vendors from being unfairly penalised for client side delays or process inefficiencies. Clearly defined client-side responsibilities and associated SLAs ensure transparency and accountability. Including explicit provisions for what occurs financially if these SLAs are breached helps maintain fairness.
6. Pre-Approved Contingency (Positive Change Budget) Creating a “white-listed change budget” of approximately 5-20% of the total cost serves as positive contingency. Unlike traditional contingency funds viewed negatively, this budget is openly acknowledged, pre-approved, and requires minimal paperwork, making it much, much easier and less “finger pointy” to roll with a cost overrun.
7. Streamlined Escalation Pathways Setting up non-confrontational, rapid escalation channels reduces friction. Both vendor and client teams should have clearly defined pathways for quickly addressing blockers without resorting to finger-pointing or aggressive tactics; this lets you behave far more in an agile way but within a waterfall-style contract.
8. Positive Incentives Rather than Penalties Contracts should ideally balance penalties with positive incentives, rewarding early deliveries, high test pass rates, and other performance-enhancing milestones. This approach helps collaboration and productivity rather than defensiveness.
9. Separate Internal and External Retrospectives Conducting internal retrospectives independently from vendor-involved sprint retrospectives can significantly reduce vendor frustration at fixing someone else’s issues while on a tight timeline and enhance internal process improvements. It allows teams to critically evaluate and address internal inefficiencies without placing undue burden on external partners.
10. Be Transparent Finally, treating a Statement of Work (SoW) as an “outer fence” while operating internally through agile backlog management, fixed team capacities, and friendly releases helps prevent defensiveness, promoting clear, blame-free visibility of progress.
This is a form of UK-based disguised employee legislation [↩]
In the realm of project management, there’s a recurring tension between delivering a project as a neatly packaged entity (basically a number of signed-off documents from a project manager’s perspective) and delivering a project as a truly useful feature for the business.
Now on one side, pure project managers often focus on precise documentation, formal ownership, and clear boundaries. This approach can streamline budgeting, clarify responsibilities, and minimise risk, particularly helpful if something goes wrong.
On the other side, managers with a business or operational background tend to prioritise tangible outcomes that meet real-world needs, even if this requires a less orderly process. This style, while potentially more chaotic, can often produce better, more enduring results for the business.
Both approaches have clear benefits and drawbacks. A strict adherence to process and paperwork can ensure compliance, financial clarity, and an “adequate” solution that meets requirements; this gives you a sound basis to claim payment against goal-based contracts.
However, it may not fully address real business needs.
Conversely, focusing purely on delivering the best business outcome can lead to scope creep, cost overruns, and never getting a sign-off on the project, but it might also generate a more valuable end product that truly benefits the organisation. In truth, I like a bit of column A and a bit of column B on this. You try to be as flexible to the business needs as you can while staying within your remit, and to this end, if you are honest with the business and say: “Look, we were made to sign this contract with these deliverables by our mutual bosses, and if we don’t do that, we won’t get paid. So please, can we do those first and then come back to the extra and different stuff you want?” it’s very often a good place to try balancing from.
