Hey, fellow Leader 🚀,
I am Artur, and welcome to my weekly newsletter. I am focusing on topics like IT Management, Innovation, and Leadership, with an Entrepreneurial mindset. My goal is to help you navigate the IT corporate landscape. Make better decisions, create awareness, and share real-world stories.
There are clear telltale signs that a piece of work didn’t receive proper effort or a critical lens. The real problem arises later in the decision-making process: information is presented to justify a choice, but it never underwent rigorous analysis or critique.
The default assumption is always that someone did a careful study and that the data is solid in clarity and quality. Unfortunately, with AI in the mix, these assumptions are repeatedly proven wrong across various leadership levels.
Here are a few ways to avoid building decisions on fragile foundations.
Large Variations in the Estimations
It is normal for complex projects or tasks to carry a high degree of uncertainty.
Drilling down into risks, quantifying them, and building a mitigation strategy is a core part of the estimation process.
However, when an estimate carries a variance greater than 10%, it shows something was missed.
A 20% variance might be acceptable for highly complex, high-uncertainty tasks, but the wider the gap, the more likely the “plan” is just shallow bullet points on a slide.
For example, estimating that a feature will take “around 20 to 40 days” represents a 100% variance. Most likely, those numbers came straight from a developer without any sanity check from the engineering lead or manager.
The follow-up questions should always target that uncertainty: What can be done to narrow it, and how do we quantify it?
Drilling into that variance is the responsibility of the Lead Engineer or Engineering Manager. They must provide a proper cost estimate paired with an action plan to mitigate risk. At the very least, break out a separate line item for risk quantification to show how to handle it and how to keep underlying costs under control.
High cost variance is almost always a symptom of poor planning and shallow analysis. Now, we are seeing this exact issue spill straight out of raw AI prompts. Someone asks an LLM for an estimate and copy-pastes the output without a second thought.
Check The Basics
Assumptions are always the mother of all f%ck-ups.
A good way to clear those assumptions is to prepare a checklist of items that you want to make sure are included in a given cost or service assessment. You can even reuse this checklist over time, and tailor it to the environment you are working in.
It makes sense to add the features that you need to fulfill the project, but also, just as importantly, add the basic items that people assume are part of the offer or easily overlook.
A practical example: let’s imagine you are assessing the subscription of an IT service. A list of requirements is important to assess the coverage of the new service, but you also need to assess the support procedures:
What are the SLAs? How long does it take to receive a response to a support ticket?
What are the costs? Are they strictly business hours, or is support also included outside business hours? Are weekends and public holidays included? If yes, which country’s holidays?
Are the installation costs included?
Which items are included in the support? Only infra? Is the OS included? If the application crashes, is that included? Who updates the machines?
Are backups done? If yes, in which timeframes? Where are they located? How long does it take to recover from a backup?
Are those CAPEX or OPEX costs? (Very important, and sometimes not clearly identified.)
The examples seem very basic. However, no two cost estimations are created equal. Commercial staff love to sell their products by highlighting the strengths and leaving it for the client to identify the possible setbacks.
So many times I have caught voids in an analysis simply because basic mitigation protocols were not included in the financial statements.
Yearly Contracts Tend To Get More Expensive
Finance hates surprises more than high numbers. The goal is to avoid surprise costs threatening the budget baselines for the year.
Not only does the financial assessment need to ensure it covers all possible costs, but for systems that will run for multiple years, you need to take into account a very specific hidden cost: inflation.
If you are projecting a system with a multi-year contract, the cost is at least covered for the duration of that term. However, during contract negotiations, it is always expected that the values will go up by a certain percentage.
This can be potentially problematic for 1-year contracts. Since the duration is very short, the vendor can easily propose increasing the price in the next negotiation.
A good way to keep costs under control is to include limits on cost increases during renewal clauses. These updates should be reflected in your financial projections so there is strong control over costs for the entire duration of the relationship.
However, not all contracts have renewal clauses where you can set maximum percentage increases. In these cases, we should agree with Finance on a reasonable percentage to include in the statement.
The main goal is to avoid surprises. Also, the plan should have possible actions in case a certain line gets highly inflated by the vendor.
What is the plan if Vendor X decides to increase costs by over 15%? How easy is it to change the vendor?
If the vendor cannot be easily changed, you are much better off negotiating a longer contract term with proper renewal and reversibility clauses. The goal is always to protect the company from cost spikes, while keeping a door open for switching later on.
It has been a wild ride since I published the first article on the SoW. Exchanging views with you and hearing feedback on how these articles have been useful is what drives my motivation to write. Leave a comment, subscribe to the SoW, and be part of the community.
If this article resonates with you, or you know someone who might find it useful, just share the link!
That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.
Cheers,
Artur