This is a relatively new pattern I’ve seen across vendors and clients, and it seems to track with the rise of strict, goal-based projects with fixed-prices and tighter costing controls. Contingency has seemingly “disappeared”, but the prices of the contract have not gone down, in fact, they tend to have gone up.

Here’s how it tends to play out.

In order to keep a firm grip on fixed-price spend and avoid variance on any given deliverable, the client or central finance team insists contingency is held centrally rather than on the vendor’s estimate. On paper, that’s fine: if something goes wrong, you dip into the central pot. In practice, two problems appear.

First, finance teams are often reluctant to release contingency. They treat requests as overspend or evidence of poor project management/implementation. People don’t like losing control or inviting blame, so approvals get sticky. Second, removing contingency from the vendor’s scope strips away whatever flexibility the vendor or delivery team might have to address issues quickly.

For as long as I can remember ¹, there was usually a simple contingency line at the bottom of an estimate. It might have been in hours or a percentage, typically 10–20% (sometimes ~5% on a well-scoped waterfall project).

Now, many quotes simply cost about 20% more by default, and any challenge to time or scope turns into a long justification and a tussle over release of funds. Everyone knows the contingency hasn’t really gone; it’s just been moved and hidden. and that’s not much of a win for any of us.

The net effect is less transparency in our quotes and vendor interactions. If a project goes really well, we still “spend the contingency” because it’s already included in the bill. I’d much rather see contingency brought back as a clear line item. But while the push for ever-tighter fixed-price deliveries continues, I don’t expect that transparency to return any time soon.

1. ,20+ years[↩]

This has been a recent learning for me. In my experience, there are two broad styles of project management:

• The teeth-gritted, head-down “just get it done” approach.
• The status heavy, constant updates, emails to stakeholders, meetings and escalation approach.

These camps tend not to like each other. I’ve spent most of my career firmly in the first: solve the problem, keep moving, minimal noise. That’s often exactly what clients want, a fix, quickly, with as little fuss as possible.

Historically, I saw the “status update” camp as unhelpful: lots of escalation, senior management getting dragged in, tempers frayed, and, in the end, someone still has to grit their teeth and fix the thing. But I’ve come to appreciate that they provide a vital function: awareness.

If you can resolve an issue quietly, without additional cost and with no material risk, then yes, get it done and move on. However, if the fix will incur more than minimal cost or expose the client to more than minimal risk, there must be full awareness. Simply generating noise isn’t useful; it just makes people anxious, but silence in the face of material impact is worse.

A competent manager does both. Do the head-down work to understand the problem and shape a solution. Once you have a plan, validated with subject-matter experts and the business, raise awareness calmly and clearly. Make stakeholders aware of the implications and the risks, alongside the proposed path to resolution.

A note for anyone hiring PMs: you want people who can do both. Perpetual flappers add little value. Perpetual silencers can cost you dearly over time. Aim for professionals who are strong on delivery and strong on communication.
This isn’t an either/or. It’s both.

In the world of project management, we often focus on timelines, budgets, and stakeholder communication. However, there’s one critical skill that frequently gets overlooked:

The ability to do your own footwork and status checking. When you can independently investigate, gather insights, and verify information, you become far more effective in your role and less of a burden to your team.

As a project manager, you should be able to:

• Track and raise issues and tickets with whatever system your client uses (ServiceNow or what have you).
• Track sprints and work allocations in Jira (or any other tool) for any team, not just your own.
• Review automated business process statuses (success or failure) after a new release goes live.
• Understand logs at a high level, even if you’re not the one managing a system.

You might not need to dig into every technical detail (like sifting through Apache logs), but you should know where to look and what to look for.

Most modern project management and cloud-based tools offer robust logging, reporting, and monitoring features. If you have the right access, you can keep tabs on your project without constantly interrupting your team.

How Research Skills Make You a Better Leader

Stay Informed

Having the ability to quickly pull reports or check logs means you’ll have a real-time understanding of your project’s status. You’ll be the first to notice if something looks off, which gives you a chance to investigate further and proactively address issues.

Avoid Getting Deceived

When you rely solely on others to inform you of problems or progress, you risk missing critical details. By verifying information yourself, you’ll be much harder to mislead, intentionally or unintentionally.

Ask Better Questions

Instead of starting a daily stand-up or group chat with, “Where are we today?” do some quick research beforehand. This allows you to ask more targeted questions, which leads to more productive discussions and less frustration for everyone involved.

Earn Your Team’s Respect

Your project team members are often subject matter experts; they expect leadership that understands (at least on a basic level) how systems work. By showing that you can pull a quick report, interpret the data, and escalate issues properly, you’ll gain credibility.

Getting the Right Access

One of the biggest barriers to doing your own research is lack of access. If you’re unsure of how to proceed, follow these steps:

Request Reader Rights

Even if you can’t edit or contribute to certain systems, having reader rights allows you to see logs, ticket details, and reports. This is usually enough access to get an overview of what’s happening.

Learn Basic Navigation

Make sure you know how to navigate the tools your team uses: ServiceNow, Jira, etc. Practice pulling standard reports and locating the areas where jobs or tickets might be flagged.

Stay Updated

Tools change frequently, and new features are added all the time. Keep yourself updated on any new views, dashboards, or analytics that might help you monitor your projects more effectively.

Contributing During a Crisis

In critical situations, like a production outage, tensions run high. Instead of interrupting your team’s efforts to fix the issue:

Dive into the logs yourself.

Check job statuses, error messages, or recent updates so you can give higher-level managers real-time updates.

Consolidate Findings.

Summarise the situation for senior stakeholders, reducing the time your team spends reporting.

By doing so, you become a valuable contributor rather than an extra layer of overhead. You free up your technical experts to focus on solutions, while you handle stakeholder communication and status updates.

Final Thoughts

Doing your own research doesn’t mean you need to become a full-fledged developer or system administrator. However, by taking the initiative to learn basic investigative skills, you’ll:

• Make more informed decisions.
• Command greater respect from your team.
• Present clearer updates to stakeholders.
• Minimise downtime in a crisis.

Ultimately, self-sufficiency in information-gathering is a game-changer for any project manager. Challenge yourself to gain basic reader access in all key project tools, and practice using that access daily. The payoff in efficiency, respect, and overall project success will be well worth the effort.

Ownership and responsibility can be a never-ending challenge in large IT organisations. In fact, it’s rare to find a corporation that doesn’t struggle with these issues. Many people want the authority and control that come with ownership, but they’re wary of the overhead involved, especially in complex cloud environments. This post explores why ownership can be so complicated and offers strategies for clarifying and streamlining it.

Why Ownership Gets Complicated

The Cloud Factor

When dealing with traditional on-premises systems, like physical servers, switches, and firewalls, it’s relatively straightforward to identify who “owns” each piece of infrastructure. But cloud systems often lack the same physical presence and involve more abstract services. For instance, setting up networks across multiple cloud environments or even inside a single cloud environment can involve numerous layers of security and function-specific configurations. Because these configurations are invisible and frequently shared across teams, pinpointing a single owner can be tricky.

Support Costs and Billing

Support in the cloud world is more expensive and convoluted. If something breaks, it could be failing in one of many places, a network misconfiguration, a permissions issue, an application bug, or a problem with the underlying cloud service. Finding who is accountable can feel like detective work:

• Identify which piece is failing.
• Prove that this failure lies in a particular team’s domain.
• Negotiate any associated costs (e.g., cross-charging or project billing).

Because support often entails additional expenses, teams may not want ownership if it means they’ll be on the hook for increased costs. This can lead to a cycle where no one steps forward to take responsibility, and “the last person who touched it” becomes the de facto owner.

Three Layers of Ownership

In many large organisations, ownership tends to break down into three informal layers:

Official (Paper) Owner

The person who appears on the org chart as the owner. They often have sign-off authority and budget oversight. However, this owner might not be the one who reacts quickly when things go wrong.

Escalation or “Real” Owner

Often a senior architect or hands-on manager who steps in during a crisis. This person makes quick decisions, coordinates teams, and resolves technical or logistical bottlenecks.

Issue Owner or Specialist

The subject matter experts who actually fix problems. They hold deep knowledge of a specific system or process. Everyone goes directly to them for specialised help, sometimes bypassing formal channels to avoid paperwork and costs.

This layering can create confusion. The “paper” owner might not actively manage the system, while the “real” owner and specialists handle the day-to-day issues without official recognition or the resources to do so.

The Impact of Fuzzy Ownership

When ownership is unclear, or people avoid it, multiple problems arise:

• Overburdened Specialists: The same experts get called on repeatedly, leading to burnout and capacity issues.
• Budget Battles: Cost centres fight over who pays for support, making cross-charging and billing an administrative nightmare.
• Slowed Innovation: If key people are always dealing with “firefighting,” they have less time for new projects or strategic initiatives.
• Blame Culture: Support rarely gets recognition for maintaining the status quo, but mistakes draw immediate criticism.

How to Fix Ownership Challenges

Define Clear Boundaries

Document who owns what, especially for cloud services. Even if a service is abstract, outline the specific responsibilities of each team or role. Invite technical architects to clarify details for senior management, ensuring everyone understands the scope of each service.

Establish Transparent Budgets

Make sure that ongoing costs (beyond initial project budgets) are well-defined. If a new service or feature will increase the support burden, communicate this early. Agree on how expenses will be allocated so that nobody is surprised.

Prevent “Sneak-Ins”

Some projects quietly introduce new dependencies, only to leave the supporting team footing the bill. Insist on a formal review whenever something new enters production. Ensure that the project’s budget covers the required support or that the correct owner is identified from the start.

Track and Justify Costs

As environments grow more complex, support will inevitably cost more. Keep detailed records of what each service or system requires to run smoothly. This way, you can demonstrate the value provided and justify budget increases when necessary.

Reward Ownership

People often avoid ownership because support work is undervalued. Leadership should incentivise and recognise the teams or individuals who keep critical services running. Providing career growth opportunities, bonuses, or public praise for effective ownership can shift the culture from blame to appreciation.

Final Thoughts

Ownership in large-scale IT isn’t just about assigning a name on an org chart; it’s about ensuring that the right people have both the responsibility and the resources to manage complex infrastructures. By clarifying boundaries, aligning budgets, and recognising the contributions of those who take on support roles, organisations can foster a culture where ownership is genuinely shared and valued, rather than avoided.

Corporate silos ¹ can create subtle yet far-reaching problems within large organisations. Often, these departments act with the best intentions, addressing internal problems swiftly and decisively.

However, the insular nature of their approach can inadvertently harm the broader organisation.

Typically, influential departments like Finance, Procurement, or HR may identify an issue they consider critical. Driven by urgency, they set out to resolve it promptly. While they might make a cursory effort to seek feedback from other departments, this feedback is often viewed through a narrow, departmental lens. Because the feedback deals with external concerns, it is frequently misunderstood, undervalued, or dismissed outright.

As a result, these departments implement changes to processes, policies, or procedures, believing they have effectively addressed their issues. Unfortunately, they rarely realise the negative ripple effects their actions can have elsewhere. The cumulative consequences can be severe, ranging from decreased productivity and widespread frustration to a noticeable slowdown in overall business operations.

Ultimately, siloed thinking undermines the very corporation these departments aim to serve. Yet, because their perspective remains internal and insular, they seldom recognise the broader impact of their decisions. It’s the rest of the organisation that bears the brunt of these unintended consequences.

If you find yourself leading a powerful, influential department, take the time to fully consider the broader implications of your actions. Addressing your internal challenges should not come at the expense of organisational health. Remember, the decisions you make today can either uplift or inadvertently burden hundreds of your colleagues tomorrow.

1. which are departments or areas operating in isolated, self-contained mental bubbles [↩]