One of the more confusing but essential parts of project management, especially within large corporations, is handling the budget. It can be deeply satisfying to make everything line up, but it is just as often frustrating when external influences stop things from matching expectations.

First, budgets are frequently demanded long before it is reasonable to produce them, particularly in cloud or integration work. Senior stakeholders often want to know how much something will cost well before anyone can estimate it with any accuracy. Most technical or delivery teams would prefer to complete a proof of concept before providing numbers, but that rarely happens. Instead, an initial figure is asked for, and once it appears on a PowerPoint slide it becomes accepted as absolute truth.

This behavior leads to the familiar cycle of pushback. Delivery teams will initially include a large margin of error, only for that number to be negotiated down to something stakeholders find more palatable, often without context or awareness of what actually needs to be delivered. The result is that early estimates are wildly inaccurate. Any attempts to explain this are often smoothed over, quietly edited out, or ignored altogether. As a project manager, you must keep putting the caveats back in or formally record your objections whenever this happens.

Second, budgets change. Prices change. Currencies fluctuate. Even something as small as the licence type for a single piece of software can alter the long-term cost of a project by hundreds of thousands of pounds. A good project manager should set aside time each month to review the budget in detail and flag any major shifts. Many of these will not be explicitly reported, so you will need to chase people down. Costs have a habit of changing for the strangest reasons, with new items quietly added or adjusted without explanation.

Make it part of your discipline to check what has changed each month, identify the impacts, and estimate the longer-term effects. But be careful not to overdramatise this. If you constantly ping stakeholders saying “the budget has increased again”, they will soon tune out. There is an art to deciding when to escalate and when to wait for a more suitable opportunity.

Third, watch out for simple mistakes. Everyone makes them, and every organisation has its quirks. As a contractor or new joiner, you are more likely to miss these. Check your figures with long-term staff who know the local systems. Even experienced people can be caught out by a change in a subsidiary process or reporting rule.

Common problems include currency errors. If your reporting is in dollars but your billing is in pounds, exchange rates can cause nasty surprises. Find out whether the company has a fixed corporate exchange rate and use it. Sometimes people even report values in their local currency without realising that the invoices are in another. It happens most often between dollars and pounds or euros, and it can either blow your budget or save you money, depending on direction.

Finally, beware of unexpected success. This particularly applies to Cloud or AI-based services. When something works brilliantly, people will naturally use it more. Usage means cost, and you can quickly find that enthusiastic adoption pushes you into a higher billing tier or usage zone. Always keep an eye on growth patterns, because success can quietly double your costs overnight.

Framing is a political tool, and we probably should not use it in IT, but everybody does.

Essentially, framing means using particular terms to promote a viewpoint or a way of seeing something. It happens all the time, and it is a perfectly normal part of communication. For a fuller explanation, I would recommend reading “Don’t Think of an Elephant: Know Your Values and Frame the Debate” by George Lakoff, which provides useful background on the subject.

You see framing frequently in corporate IT, but you can fight back against it.

When framing is being used against you, particularly when you are trying to get something done, you will often hear complex technical language or reassuring, almost fatherly terms misused. You might hear phrases such as “advisory board” for a group that is supposedly just there to help. But in reality, it may be a group of gatekeepers trying to ensure that nobody does anything they do not like.

You can challenge this by flipping the framing around.

For example, if there is an approval document, which is itself a positive and authoritative term, you can simply call it paperwork.

“We are nearly ready. We just need to complete the paperwork.”

This diminishes what another part of the corporation might describe as an advisory document, governance document or strategic approval document.

The ultimate version of this, which has also been used in American politics, is the phrase “permission slip”.

Suppose you are waiting for approval from a governance board inside a corporation, and it calls its document a “strategic approval document”, which makes it sound like something grand and unarguable when it might be nothing of the sort, but if you refer to it as a permission slip, you completely change the frame.

It stops sounding like guidance, responsible oversight and strategic governance. Instead, it becomes paperwork handed out to a child by someone in authority.

I do not advise doing this. It is not a particularly nice tactic, but you will see people use it against you. They will use overly grand phrases to justify their own work, while using diminutive words and phrases to describe yours.

It is human nature, but it does have a name.

That name is framing.

Keep an eye out for it.