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.
Although “keeping cloud costs down” may initially sound like clickbait, the reality behind this topic is actually important and has a genuine impact on businesses. In my experience, cloud expenditures aren’t just about picking the right provider, whether AWS, Azure, etc., but mainly about how a company manages its cloud provisioning and cleanup processes. Here are several practical strategies I’ve found that do help with this:
1. Simplify Deletion as Much as Provisioning
Companies often emphasise rapid and easy provisioning of cloud resources due to immediate demands from teams wanting resources quickly. Unfortunately, deleting resources is usually more complicated because of the perceived risks involved, especially the fear of mistakenly removing something crucial.
To address this:
Implement a straightforward deletion process at the same administrative level as provisioning; you can script or develop ways of checking if dependent or downstream resources have been used.
Introduce robust referential integrity checks to ensure resources are safe to delete.
Provide easy access to clear logs, making it simple to identify inactive or underutilised resources.
2. Enable Easy Resource Resizing
There’s a common misconception that the cloud will automatically handle scaling seamlessly. While autoscaling can indeed work beautifully, it’s not always as straightforward as it sounds, especially when third-party managed services complicate the process. This can lead to operations teams over-provisioning initially to avoid the hassle of scaling later, inadvertently inflating costs.
Therefore:
Create processes that simplify scaling resources without cumbersome workflows or downtime.
Reduce the complexity and risk associated with resizing, helping operations teams feel confident in provisioning only what’s necessary initially.
3. Ensure Supporting Infrastructure is Cloud-Friendly
A hidden factor often overlooked is how cloud-friendly your supporting infrastructure actually is. Legacy networks, IP addressing schemes, and particularly firewall provisioning processes can significantly slow down cloud agility. If a firewall rule change takes weeks to approve and implement, teams become reluctant to make cost-saving adjustments such as shutting down unused test environments.
Recommended actions:
Update your infrastructure and processes to match cloud agility standards, or at least highlight this as a risk and help them get budget to do so.
Automate firewall and network provisioning where possible, reducing administrative bottlenecks.
For instance, test and development environments often don’t need to run continuously. By implementing scripts or automation to shut these down when unused, substantial savings can be realised, but only if the supporting infrastructure can accommodate these quick changes, such as keeping firewall routes open when the environments are spun back up with new IP addresses.
4. Align Cost Management with Technical Expertise
Often, the individuals responsible for managing cloud cost reports, like project managers or financial controllers, might not fully understand technical details or which resources represent genuine value or unnecessary overhead.
To mitigate this:
Ensure cost breakdown reports are regularly reviewed by technical architects or senior subject matter experts alongside non-technical managers.
Facilitate regular discussions between these roles to identify redundant or temporary resources, like those used in proofs of concept, that could be safely decommissioned.
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.
A “watermelon project” is a term used to describe a project that appears healthy and trouble-free on the surface, signified as “green” in project management status reports, but internally is experiencing significant issues, symbolised by “red.”
Explanation:
In many corporations, especially large ones with numerous simultaneous projects, stakeholders and senior managers often rely on simple visual indicators to understand project status. Projects marked “green” typically receive minimal attention, as they signal smooth operation and successful progression.
Conversely, projects marked “red” or “amber” immediately attract scrutiny, potentially triggering managerial interventions and escalations.
Because of this, project managers might intentionally represent their project’s status as green to avoid negative attention or perceptions of incompetence, even if substantial internal issues exist. This leads to the creation of a watermelon project, green externally but problematic internally.
This phenomenon highlights a significant flaw in simplistic project tracking methods and emphasises the need for deeper, more transparent project health evaluations rather than relying solely on surface-level colour codes, as well as removing the shame associated with letting your project move out of “green”.
Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.
