How the Fear of Detail Can Derail Your M365 Implementation
I came across a recent LinkedIn survey showing that 70–80% of organizations feel the need to redesign their SharePoint and Microsoft 365 environments. Unfortunately, that’s not all that surprising to me. Especially over the pandemic, many organizations rushed into deployment, ignoring the changing landscape of SharePoint best practices. But one of the biggest culprits behind poor implementations? A lack of solution detail. Without a proper design, even the best tools will fall short.
Fun image to illustrate my point.
Being in this business for almost two decades, I’ve noticed a recurring theme: Multiple stakeholders voicing concerns about missing solution details. Sure, budget constraints play a role, but they’re rarely the whole story. In fact, I’ve seen a major enterprise walk away from a poorly implemented SharePoint and M365 setup, blaming the platform. They switched to a competitor, only to run into the same issues again. Why? Because the root problem wasn’t the technology—it was the lack of a thoughtful, well-structured design and implementation.
Why We’re Sometimes Scared of the Detail in IT Systems
IT departments, software developers, testers, project managers, and end-to end users… what would you guess they all have in common? These teams have learned—sometimes the hard way—that adding more detail to systems typically brings more risk, more issues, more bugs and more frustration. Every extra field, button, or screen, layered onto a custom solution adds complexity that tends to show up in all the wrong places.
More bugs discovered
More testing cycles required
More help-desk tickets logged
More frustrated users
More maintenance effort over time
Adding SharePoint to the Mix
Fun fact: I began my career as a software developer and still code to this day.
Back in the day, many SharePoint projects were built by software developers, web developers and solution architects. Sure, you could configure SharePoint, but enterprise-scale solutions often meant diving into CAML, C#, ASP.NET, HTML, and CSS to provide missing and advanced functionality as well as to enable teams to deploy the solution to multiple environments. These were packaged up as WSP files and deployed across farms, making SharePoint just as vulnerable to overengineering and ‘too much detail’ as any other custom-built system.
Because we were working so close to the codebase, it was tempting to tweak out-of-the-box behavior. And with fewer native web parts available, we often had no choice but to extend the platform just to deliver basic functionality. If only I had a dime for every weather web part I built!
But those customisations:
Often conflicted with future platform updates
Needed ongoing tweaks to keep up with browser changes
Sometimes prevented organisations from upgrading to the next version of SharePoint (I know multi-million-dollar upgrade projects that still failed after several attempts)
Details also surfaced in the architecture itself:
Subsites: Moving content between subsites was effectively a mini-migration project.
Site collections: Scaling out meant more databases to back up, restore, and keep in sync.
Multiple environments: Every extra container multiplied the effort of promoting content through dev, test, and prod.
The net effect? Higher costs, longer timelines and more issues.
The Resulting Pushback
Given that history, it’s perfectly rational for stakeholders to hesitate when someone proposes adding “just a bit more detail” to any M365 project. They instinctively equate detail with those pain points, but many of these issues no longer apply to modern M365 implementations.
Understanding that fear is the first step; addressing it with modern practices and disciplined information architecture is how you keep your M365 rollout on track without falling into the detail = disaster trap. Because, quite simply, that’s no longer the case.
Things are Changing
Today, in M365 and SharePoint Online:
Large implementations are mostly configured rather than coded
Most solutions rely on out-of-box functionality, with light extensions via Power Apps and Power Automate (still not risk-free, but lower risk)
Microsoft keeps adding templates, AI helpers, and built-in components, reducing the need for custom code
Many organisations now run with one production tenant (and perhaps a small test tenant)
Microsoft manages the cloud infrastructure, so we no longer patch servers or back up databases ourselves—even if we wanted to
Customisations are far less frequent, and we when we need them we can generate the code through AI and generate testing code through AI
The result is typically fewer issues, fewer bugs, and less maintenance. But only if you build on a well-structured SharePoint foundation.
Why Good Design Still Matters
Paradoxically, the riskiest M365 projects today are the ones launched with little or no design at all. Think, dumping an entire department into a single document library and relying on deep folder trees or handing the keys over to departments and letting them loose on the platform. I will neither confirm nor deny if these are real-world example I have experienced.
By contrast, taking the time to thoughtfully structure your SharePoint and M365 environment—might take more effort up front, but it pays off in big ways. My take: spread content across sites and libraries, favour content types and thoughtful metadata instead of folders, and plan with scalability, security, compliance, and usability in mind. Here’s why:
-
Often bringing it down to near zero.
-
Like workflows, records management, privacy, and business system integrations. All instead of constantly up a messy M365 implementation.
-
By reducing oversharing and improving content clarity.
When SharePoint or M365 is poorly structured (or worse, left ungoverned) teams often find themselves spending time and budget downstream just to fix what wasn’t planned for upfront. Scalability issues, security gaps, and compliance risks don’t go away on their own. They resurface later, usually when it’s more expensive and disruptive to solve them.
The upside? When your foundation is solid, your support team gets to focus on what actually moves the needle—enhancing the solution, delighting users, and delivering real value. Instead of constantly untangling messy implementations, they’re building momentum and trust across the organization.
Key Points to Remember
Detail is no longer bad. Well-designed detail is good, really good!
Modern M365 tools reduce the need for custom code, but they still require deliberate information architecture.
Investing in design up front saves significant effort later and unlocks the true potential of workflows, records management, and AI.
