Psychologists Daniel Kahneman and Amos Tversky coined the term "planning fallacy" in 1979 to describe a specific, consistent human tendency: we underestimate the time, cost, and risk of a task, while overestimating its benefits, and we do this even when we have direct personal experience of being wrong about the exact same kind of task before. Kahneman later won the Nobel Prize in economics in part for this body of work.

The classic study illustrating it is almost funny. Psychology students were asked to estimate how long their senior thesis would take. The average guess was under 34 days. Only around 30% of them actually finished within their own predicted timeframe, despite having written papers before and knowing, going in, that they tend to run long. Knowing the pattern didn't stop them from repeating it.

The mechanism researchers point to is what's called the "inside view." When people plan, they focus on the specifics of the project in front of them, the exact steps, the specific team, the particular timeline, rather than on how similar projects have actually gone in the past. That inside view feels more rigorous, because it's detailed and specific to your situation. It's also exactly what produces the underestimate, because it quietly excludes all the ways things went wrong on comparable projects that weren't yours.

The documented fix is called the "outside view," deliberately setting the specifics of your project aside and asking instead: how did this category of project actually go, across everyone who's attempted it. That's a harder habit than it sounds, because the inside view always feels more relevant to your case. It rarely is.

This is what a genuine reference class looks like in practice, rather than an abstract idea. Based on GTconsult's own migration work, rough timelines by environment size: under 50 users and 500GB of data sits at around a couple of weeks. 50 to 300 users, 500GB to 5TB, runs 1 to 3 months. 300 or more users, 5TB or more, runs 3 to 6 months minimum, and that's before accounting for custom functionality, classic web parts, or on-premises workflows that need rebuilding into Power Automate.

None of those numbers come from guessing at your specific project. They come from having run enough migrations to know what actually tends to happen, which is exactly the outside view this whole piece is about.

The planning fallacy doesn't go away because you've heard of it, the psychology students knew they tended to run long and still underestimated. What actually helps is building the outside view into the plan deliberately, asking someone who's run this category of project many times what actually tends to happen, rather than reasoning from your own specific case alone. That's most of what a good delivery partner is actually for: not extra hands, a reference class of every time this has gone wrong before, applied to your project before it does.

The same pattern shows up well beyond SharePoint migrations. It's just as true of a Power Apps build, a Microsoft Fabric implementation, or an agentic AI rollout, teams plan from the specific project in front of them rather than from how similar projects in that category have actually gone. Our Copilot Readiness Checklist is built entirely from that outside view for Copilot and Microsoft 365 adoption specifically, and it's the same discipline we bring to Power Apps, Fabric, and agentic AI builds too.

Planning a migration and want the outside view before you start? Get in touch and we'll tell you what actually tends to happen.

Independent research through 2026 keeps landing in the same place. MIT's NANDA initiative reviewed hundreds of enterprise generative AI deployments and found that the overwhelming majority delivered no measurable financial return, not a small return, none. RAND's analysis puts the overall AI project failure rate above 80%, roughly double the failure rate of a conventional IT project. Multiple independent studies through the year converge on an AI pilot-to-production failure rate sitting between 86% and 95%, depending on how strictly "production" gets defined.

The detail that matters most in all of that research: the model is almost never the reason. The demos work. The reviews are positive. Then the pilot meets the actual environment, real data, real authentication, real workflow dependencies, and quietly stalls.

This pattern is especially visible in Microsoft Copilot Studio, and that's not a coincidence. Copilot Studio is genuinely good at getting a working demo up fast, low-code, drag-and-drop, connected to a sample data source in an afternoon. That's a real strength. It's also exactly why the demo-to-production gap catches so many Microsoft 365 organisations off guard: the barrier to an impressive first version is so low that it's easy to mistake "the agent works in the demo" for "the agent is ready."

What Copilot Studio's interface doesn't show you is everything sitting just underneath: which knowledge sources the agent should actually be allowed to draw from, whether general model knowledge needs to be switched off to stop it hallucinating, how it authenticates against your real CRM or SharePoint data instead of a sample connection, and who owns it once it's live in Teams and someone's actually relying on it. None of that is a Copilot Studio limitation. It's the same demo-to-production gap this whole piece is about, just wearing a Microsoft 365 badge.

Microsoft's own product design draws this exact line, which is a useful confirmation that the distinction is real rather than something vendors gloss over. Copilot Studio's self-service trial lets you build and test an agent internally, but agents on that tier can't be published externally at all. That's a sensible guardrail, not a flaw: it's Microsoft drawing the same boundary this whole piece is about, a working demo and a production-ready agent clear two different bars, and the platform is built to reflect that rather than blur it.

A demo runs on curated data, in a controlled setting, answering a question someone already knew the answer to. None of that is dishonest, it's just a different exercise entirely from production. Production means messy data nobody's cleaned up, systems that were never designed to talk to each other, and edge cases nobody scripted for.

The organisations that make it through share a specific pattern: they treat the gap between demo and production AI as the actual project, not as an afterthought once the demo gets approved.

It's tempting to assume this gap closes on its own as AI tools mature. It hasn't. The models genuinely have gotten better, faster, cheaper, easier to plug in. But the failure points research keeps identifying, dirty data with no clear owner, systems that were never built to talk to each other, no agreed definition of what "working" actually means, missing governance, are organisational problems, not model problems. A better model doesn't clean up your data for you. It doesn't decide who owns a broken integration. If anything, faster model progress has made this worse in one specific way: it's now easier than ever to stand up an impressive demo, which means more organisations are reaching the demo stage, discovering the same gap, and being surprised by it all over again.

A few honest questions tend to surface the gap early, before it costs you a quarter:

None of these questions are exotic. They're just rarely asked before the demo gets approved, which is exactly when they're cheapest to answer.

Thinking about moving an AI pilot toward something that actually runs in production? Get in touch and we'll help you scope what that really takes.

By the time a risk is obvious to everyone in a room, it's usually already been a risk for a while. Obvious is late. The people who actually understand a system, a contract, or a process can typically see a problem taking shape long before it's loud enough for everyone else to notice from the outside.

That gap, between when a real risk starts and when it becomes visible to a non-specialist, is exactly where the damage happens. Waiting for the visible version of a problem before acting on it isn't caution, it's just later.

A good partner isn't the one who reacts fastest once something's on fire. It's the one who was already watching, who flagged the issue before it needed flagging urgently, and who already had a plan in place before you needed one.

That's a genuinely different skill from incident response. It's not about being fast when things go wrong. It's about noticing quietly, consistently, before things go wrong, and being trusted enough that "this needs attention" is taken seriously the first time it's said, not the third.

Here's the part worth sitting with: nothing about the vulnerability changed between January and March. The danger was exactly as real in January as it was in March. The only thing that changed was that by March, it was finally visible enough to make headlines.

Acting on it in January meant taking it seriously before it looked dangerous. Acting on it in March meant taking it seriously once everyone else already had to.

This pattern isn't specific to SharePoint, or to security. It shows up anywhere risk quietly builds before it's acknowledged: a contract clause nobody double-checked, a permission structure that's grown looser over years, a process that's one departure away from breaking. In every case, the actual danger and the visible danger arrive at different times, and the gap between them is where a good partner earns their keep.

The standard worth holding any technology or security partner to isn't "how quickly do you respond when something breaks." It's "what have you already flagged that hasn't broken yet."

Want a partner who's watching before things get loud? Get in touch and we'll show you what we're already keeping an eye on.

Passkeys replace a code you type with a credential tied to your device or biometric, like a fingerprint, face scan, or security key. There's no code to intercept, no number to SIM-swap, and nothing that can be phished over a call or text.

This is what "phishing-resistant authentication" actually means in practice: the credential itself can't be tricked out of a user, because there's nothing to hand over.

Every user still on SMS or voice MFA needs to move to a phishing-resistant method, and Microsoft recommends passkeys, before Microsoft-provided SMS and voice retire on 1 February 2027. Acting before 1 September 2026 means your organisation controls the rollout. Waiting means Entra ID controls it for you, one blocking prompt at a time.

Copilot has always been a prompt-and-response tool. You ask it something, it responds. Useful, but reactive.

Cowork changes the model. Instead of prompting Copilot with a question, you delegate a goal.

'Compile a risk summary from the last three quarterly reports.'

'Review these 40 supplier contracts and flag anything that doesn't match our standard terms.'

'Pull together a briefing note on this client from our SharePoint files and recent email threads.'

Cowork plans the work, executes it across your Microsoft 365 environment, and delivers the output. You don't have to stay at your keyboard while it runs. It runs on GPT-5.5

 Thinking and Anthropic's Claude Opus 4.8, with an Auto mode that picks the right model for each task.

This is the part that caught some organisations off guard at the end of July. And it's worth being very direct about it.

Cowork doesn't run on your per-seat Copilot licence alone. It uses Copilot Credits on top of it.

Credits are billed at $0.01 (R0.18 / £0.008) per credit. Every Cowork task consumes credits based on the model used, the volume of context retrieved, the number of tool calls made, and how long the task runs.

To give you a sense of what that looks like in practice:

Those numbers are per task. For a team running Cowork heavily, costs can accumulate quickly.

Teams that configured spend alerts and usage caps before expanding access managed their costs without surprises. Teams that enabled Cowork broadly without billing controls had an uncomfortable finance conversation at the end of July.

Configure spend alerts and usage caps in the Microsoft 365 admin centre before you expand Cowork access beyond a small pilot group. This is not optional. It's five minutes of setup that prevents a much longer conversation later.

Two billing options exist: pay-as-you-go at the standard rate, and prepaid annual credits at a lower per-credit rate. Pay-as-you-go is the right starting point for most organisations. Two to three weeks of pilot data tells you what your actual usage pattern looks like. Then you can make an informed decision about whether prepaid credits make economic sense.

Cowork executes tasks using the permissions of whoever initiates them. It reads email, accesses SharePoint, generates documents, and takes actions in connected apps — all based on whatever access the user already has.

This is why the permissions work that should precede any Copilot deployment matters even more before scaling Cowork. An overshared SharePoint environment doesn't become safer when Cowork starts running in it. It becomes a more efficiently exploited one.

Two things to have in place before you expand access:

•  Purview audit logging for Cowork activity — this is included in the GA baseline, but needs to be verified as active. It's what gives you the ability to see what Cowork actually did on behalf of a user.

•  Agent 365 governance — if you're using Agent 365, Cowork activity falls under the same governance framework. Agent 365 gives you visibility into Cowork as a managed agent alongside any others in your environment.

GTconsult helps organisations across South Africa, the UK, and the US get more from Microsoft 365 and SharePoint — from custom development and migrations to security, support, and AI solutions.

This is not a Copilot problem. Copilot works. The problem is almost always what happened — or didn't happen — before anyone pressed enable.

Here are the five things that separate a Copilot deployment that delivers from one that quietly becomes expensive shelfware.

Think of Copilot as an amplifier. It takes what's in your Microsoft 365 environment and makes it faster to find, easier to use, and more accessible.

If your data is well-organised and current, that amplification is genuinely powerful.

If your SharePoint looks like a digital filing cabinet that hasn't been touched since 2018 — inconsistent folder structures, outdated documents, no metadata, no content types — Copilot will amplify that too.

Garbage in. Garbage out. Except now it happens at AI speed.

The data hygiene work — archiving what's obsolete, applying sensitivity labels, enforcing consistent content types — is unglamorous. It's also the single thing that most determines whether your Copilot deployment succeeds.

Enabling Copilot for 500 people on day one is the fastest way to ensure that 500 people try it once, get inconsistent results, and decide it's not worth the effort.

The organisations that see strong Copilot adoption do it differently. They pick one team with a specific, measurable workflow. A finance team that produces a weekly report. A procurement team that reviews the same document types every month. An HR team with a predictable onboarding process.

Deploy to that team. Train them on that specific workflow. Measure whether it saves time. Document what worked. Then use that as the blueprint for everyone else.

This sounds obvious. Most organisations skip it.

If you don't define what success looks like before a Copilot deployment, you can't tell whether it's working three months in. You can't identify problems early. You can't justify the investment to leadership when they ask.

Your success metrics don't need to be complicated. Weekly active usage versus licences assigned. Time saved on a specific recurring task. User satisfaction score from the pilot team. The Microsoft 365 admin centre has a Copilot Dashboard that gives you adoption data across every application. Use it from day one, not after things start going wrong.

The pattern is consistent enough that it has a name in the industry: "shelfware." Licences that are paid for, assigned, and barely used.

It usually unfolds the same way: licences purchased, announcement made, training session held, adoption flatlines, leadership asks why ROI is low, nobody has a good answer because nobody measured anything, the investment is hard to justify at the next renewal.

None of that is inevitable. It's the result of skipping the preparation that sits between procurement and deployment.

The good news: all of it is fixable. Even if you've already deployed.

If your Copilot adoption is lower than you'd hoped, start with the Copilot Dashboard in the admin centre. It will show you exactly where usage is and where it's not. That data tells you which of the five steps above to address first.

GTconsult works with organisations across South Africa, the UK, and the US on Microsoft 365 planning, deployment, governance, and adoption. Get in touch for a free consultation.

In July 2026, Microsoft launched the Agent Store's governed publishing flow. Teams can now build agents in Copilot Studio, submit them for admin review, and publish them under a 'Built by your org' section that anyone in the organisation can find and use.

This is genuinely useful. Internal tools that were previously invisible are now discoverable.

But here's the governance implication: an agent built by one team — with permissions that made sense for that team's specific use case — is now accessible to everyone in the business. An agent with broader data access than it needs, that was previously used by three people, can now be triggered by anyone who finds it in the Agent Store.

Agent 365 is the control layer that lets IT see, govern, and apply policies to everything in that Agent Store catalogue. Without it, you're publishing without visibility.

If you haven't opened Agent 365 yet, here's the sequence that makes sense:

1.  Open the Microsoft 365 admin centre and navigate to Agent 365. Review the registry. Most organisations find agents they weren't aware of — including some deployed by teams without IT involvement. That discovery alone is worth the five minutes it takes.

2.  Check the Agent Store under 'Built by your org.' These agents are now discoverable org-wide. Verify that everything published has been through a proper review and is appropriately scoped.

3.  Use Defender's asset context mapping to go beyond a list of agent names. Understand what identities and cloud resources each agent can actually reach. That's the question that matters for a real security posture assessment.

4.  Set a governance baseline — before the list of agents grows any longer. Decide what data access is permitted by default for new agents, when admin approval is required for publishing, and how permissions will be reviewed over time.

The last step is the important one. It's much easier to establish governance standards before there are 50 agents to manage than after.

AI agents are no longer a future consideration for enterprise IT. They're running now, in your environment, whether IT knows about them or not.

Agent 365 gives you the visibility to see what's there, the controls to govern how agents behave, and the security integration to respond when something goes wrong.

The organisations that will manage AI agents well are the ones that set up the governance layer before the list of agents gets unmanageable. That moment is now.

GTconsult works with organisations across South Africa, the UK, and the US on Microsoft 365 planning, deployment, governance, and adoption. Whether you’re just getting started or trying to unlock value from licences you’ve already bought, we can help.

CISA confirmed that four separate SharePoint vulnerabilities are being actively exploited in the wild, not just one. That matters because CVEs are sometimes discovered and patched quietly, well before attackers pick them up. Having four confirmed under active exploitation at once, in the same year, signals a much more concentrated wave of attacker interest in SharePoint specifically.

These aren't new bugs introduced by a recent update. They sit in subsystems that have been part of SharePoint since 2016, and they affect every version built on that foundation, including the latest Subscription Edition. AI-assisted vulnerability research is a big part of why these older, previously overlooked issues are surfacing now: it's simply become faster to fuzz code and find these combinations of bugs.

Beyond the initial breach, attackers behind these exploits have been stealing IIS machine keys and using them to deploy malware that persists inside the same service that serves your SharePoint environment to your users. In practice, that means malicious code can live in a trusted location and be pushed out to your users directly, potentially harvesting credentials that grant access to completely separate systems beyond SharePoint itself.

SharePoint Online is not affected by these vulnerabilities. Microsoft has already patched the online service. This issue is specific to SharePoint on-premise deployments, including SharePoint 2016, 2019, and Subscription Edition. If you're running a version older than 2013, you're already dealing with a separate set of unpatched, unsupported risks.

Log in to your SharePoint service and confirm which version and build you're currently running. Then check your Windows Update history for the relevant security KB:

●  SharePoint Subscription Edition: KB5002873

●  SharePoint 2019: KB5002874

●  SharePoint 2016: KB5002880

Microsoft's Security Update Guide also lets you search by CVE number to see exactly which patch resolves which vulnerability for your version.

Microsoft released security updates for SharePoint 2016 and 2019 on 14 July 2026 that address these vulnerabilities, even though both versions are officially out of support. Patch immediately using the KB references above. Once patched, start planning your upgrade path, since these platforms won't receive fixes indefinitely.

Beyond patching, review whether your SharePoint environment needs to be publicly accessible at all. If it doesn't need to be reachable from anywhere on the internet, put it behind a VPN. Reducing unnecessary exposure shrinks your attack surface regardless of how quickly you can patch.

If you want help reviewing your current email security configuration against these specific vectors, get in touch and we can help.