Category: Documentation & Technical Writing Information Management Professional Communication Plain English & Clarity

Why Most Information Management Systems Fail?

Most information management systems do not fail because of the technology. They fail because organisations place the wrong people in charge of them.

It might sound tough, but I’ve seen the same issues over and over in documentation, governance, migration, and digital transformation projects for years.

A company buys a shiny new platform. Perhaps it is SharePoint, Asite, OpenText, Confluence, or some other enterprise repository promising collaboration, governance, and a “single source of truth.” Senior management signs off on the budget. Consultants arrive. Workshops take place. PowerPoint slides appear with words like transformation, efficiency, and digitisation.

Then reality arrives.

The people tasked with implementing the system often do not understand:

      • Information architecture
      • Metadata strategy
      • Document lifecycle management
      • Governance
      • Retention
      • Taxonomy
      • Search behaviour
      • Classification
      • User behaviour
      • Migration risk
      • Audit requirements

Instead, the responsibility falls to:

      • Project managers are trying to keep timelines alive
      • Administrators are learning the system as they go
      • Engineers or operational staff are given “document duties”
      • Junior analysts following configuration guides
      • Contractors brought in late with no authority
      • Teams follow instructions without understanding why the rules exist

The result is predictable.

Folders become dumping grounds. Metadata becomes inconsistent. Naming conventions collapse within months. Nobody owns review cycles. Duplicate files spread everywhere. Obsolete documents survive for years. Search becomes unreliable. Staff stop trusting the repository and return to shared drives, desktops, Teams chats, and email attachments.

The system technically works.
The information ecosystem does not.

One of the biggest problems is the culture of “learning on the job” without experienced guidance. There is nothing wrong with learning. Every profession requires it. The danger appears when organisations assume complex information governance can be improvised by whoever is available.

Information management is not merely administration.
It is a discipline.

A proper information manager understands:

      • Governance structures
      • Risk
      • Regulatory obligations
      • User behaviour
      • Retrieval logic
      • Version control
      • Controlled publishing
      • Retention schedules
      • Audit defensibility
      • Migration integrity
      • Operational continuity

Without that knowledge, teams often follow instructions mechanically.

“Upload the files.”

“Apply metadata.”

“Move everything into SharePoint.”

“Create the folders.”

“Archive old material.”

But few stop to ask:

      • Why are we storing this?
      • Who owns it?
      • Who reviews it?
      • Is it duplicated elsewhere?
      • Is it authoritative?
      • What is the retention requirement?
      • What business process depends on this information?
      • What happens if somebody follows the wrong version?

That lack of understanding is where many systems quietly begin to decay.

The harsh truth is that some organisations confuse software knowledge with information management expertise. Knowing how to create a SharePoint library does not make someone an Information Manager, just as knowing how to use Word does not make someone a technical author.

Technology alone cannot compensate for weak governance.

Another recurring issue is leadership detachment. Senior management often sees Information Management as an IT deployment rather than an operational control mechanism. Once the platform is installed, they assume the job is complete.

It is not.

The difficult work starts afterwards:

      • Governance
      • Ownership
      • Review enforcement
      • Classification
      • Rationalisation
      • Training
      • Audit checks
      • Lifecycle management
      • Repository discipline

Without these controls, entropy takes over.

This is why many migrations fail to improve anything. Organisations transfer chaos from one platform to another. The old shared drive becomes a badly organised SharePoint site. The same ROT — redundant, obsolete, and trivial information — survives the migration untouched.

A poorly governed system can often outperform an excellent platform without it.

The uncomfortable conclusion is this:

Most information management failures are not technical failures.
They are failures of leadership, governance, experience, and understanding.

Until organisations place experienced people in charge of their information estates — people who understand both systems and governance — many so-called digital transformations will continue to become expensive storage exercises disguised as progress.

Why Technical Authors are disappearing from IT Projects

Technical authors are vanishing from many IT projects.

Project managers, hire a technical author
Hiring a suitable Technical Author

Not because documentation is no longer needed.

But because organisations convinced themselves that:

      • Agile removed the need for documentation
      • SMEs could “just write it”
      • Developers could document as they build
      • Wikis replaced structured information management
      • AI can now generate everything automatically

The result?

Documentation did not disappear. Ownership disappeared.

The Agile Misinterpretation

IT misunderstood Agile, believing it meant:

Less documentation.

What Agile challenged was:

      • Excessive bureaucracy
      • Huge unused specification sets
      • Documentation written for sign-off instead of operational value

But somewhere along the line, many organisations translated this into:

We no longer need technical authors.

So documentation responsibilities were fragmented across:

      • Developers
      • Business analysts
      • Product owners
      • Service managers
      • Support teams

Everyone became partially responsible.

Which usually means nobody became fully accountable.

IT Projects Still Produce Complexity

Modern IT environments are not simpler but more complex than they were 20 years ago.

Today’s projects involve:

      • Cloud platforms
      • APIs
      • Identity management
      • Cybersecurity controls
      • SaaS integrations
      • DevOps pipelines
      • Automation
      • Data governance
      • Compliance obligations
      • Hybrid infrastructure
      • AI systems

Yet many projects still assume documentation can “emerge naturally.”

What usually emerges is:

      • Scattered Confluence pages
      • Outdated SharePoint libraries
      • Tribal knowledge
      • Slack conversations acting as operational memory
      • Contradictory procedures
      • Uncontrolled revisions

Eventually, operational support inherits the chaos.

The “SMEs Will Write It” Fantasy

Subject Matter Experts are essential.

But SMEs are not usually:

      • Information architects
      • Editors
      • Audience analysts
      • Metadata specialists
      • Structured writing professionals
      • Governance specialists

Most SMEs focus on:

      • Delivering systems
      • Solving technical problems
      • Meeting deadlines

Documentation becomes secondary.

Postponed until the last phase of a project — when schedules collapse, and budgets tighten.

That is where technical authors historically added value:

      • Extracting knowledge
      • Structuring information
      • Standardising terminology
      • Identifying gaps
      • Challenging ambiguity
      • Creating usable operational guidance

Without that role, knowledge quality declines rapidly.

Documentation became Invisible Work.

In many IT organisations, documentation is now treated as:

      • Administrative overhead
      • Non-billable effort
      • A project afterthought
      • Something AI can “tidy up later”

Yet the same organisations later struggle with:

      • Failed handovers
      • Poor onboarding
      • Repeated incidents
      • Knowledge loss
      • Service desk dependency
      • Operational inconsistency
      • Audit failures

Because undocumented systems create operational drag.

The irony is simple:
The more complex IT becomes, the more valuable structured information becomes.

AI is speeding up the illusion

AI has amplified the belief that technical writing is “generating text.”

But experienced technical authors are not typists.

They managed:

      • Information quality
      • Knowledge structures
      • Content governance
      • Audience interpretation
      • Process consistency
      • Lifecycle control
      • Information retrieval
      • Operational usability

While AI can produce drafts quickly, it does not inherently:

      • Understand organisational risk
      • Detect conflicting operational procedures
      • Validate technical accuracy
      • Govern document lifecycles
      • Manage controlled information environments

Many times, AI speeds up the production of unmanaged content.

The Hidden Shift

Interestingly, technical authors have not entirely disappeared. We have changed titles:

Across IT projects, former technical authors now operate as:

      • Information managers
      • Knowledge managers
      • Content strategists
      • Service transition analysts
      • Governance specialists
      • Digital adoption consultants
      • Documentation engineers
      • Information architects

The writing component became only one part of a broader information role.

The Long-Term Risk

IT projects can survive in the short term without dedicated technical authors.

Until:

      • Key staff leave
      • Systems fail
      • Audits occur
      • Services scale
      • Migrations happen
      • Security incidents arise
      • Regulatory scrutiny increases

Then organisations rediscover the same truth:

      • Operational resilience depends on reliable information.
      • And reliable information rarely happens accidentally.
      • The disappearance of technical authors from IT projects may save money on a spreadsheet.
      • But over time, many organisations discover that they have not removed the need for technical authors.
      • They merely removed the people responsible for keeping organisational knowledge usable.

From Complexity to Clarity: The Technical Authoring Way

Technical authors bridge the gap between complexity and clarity. Learn how structure, empathy, and plain English create documentation people actually use.

Tweet
Pin
Share
0 Shares

Every organisation wrestles with complexity. Systems evolve, processes multiply, and acronyms breed faster than understanding. Technical authoring becomes crucial in such scenarios. Somewhere in that tangle, people stop reading, stop following, and start guessing. That’s when errors creep in, efficiency drops, and the documentation everyone thought existed suddenly becomes “that thing we’ll fix later.”

That’s where the technical author steps in, uniquely skilled in technical authoring to bridge these gaps.

A technical author’s purpose is not only to write — it’s translating complexity into clarity. We work at the intersection of engineering, IT, and communication, ensuring that processes, systems, and knowledge are usable, repeatable, and understood. Our craft is part detective work, part design thinking, and entirely focused on the reader.

Understanding the Reader’s World

Clarity begins with empathy. Technical authors spend much of their time understanding the user’s context — their goals, frustrations, and level of technical knowledge. Whether we’re documenting an API, a SharePoint governance plan, or a safety-critical engineering process, our first question is always the same:

“Who needs this information, and what do they need to do with it?”

That question shapes everything that follows — the structure, language, and format. It’s how we transform information from a data dump into a valuable and actionable resource.

Structure Is Strategy

Good documentation doesn’t happen by chance. Behind every clear paragraph lies a strategy: a taxonomy that defines where information lives, a naming convention that ensures consistency, and metadata that keeps documents findable long after the author moves on.

We know that clarity isn’t just what’s written — it’s how information is organised. That’s why technical authors create templates, workflows, and metadata standards to keep projects aligned. Without that structure, documentation collapses under its own weight.

Plain English Is Powerful English

There’s a common misconception that plain English means dumbing things down. In reality, it’s about respecting the reader’s time, a critical aspect of effective technical authoring.

Technical authors strip away unnecessary jargon, long sentences, and layered clauses. We use verbs instead of nouns, bullets instead of paragraphs, and examples instead of assumptions. Every word earns its place. When you write clearly, you make expertise accessible — and that’s where value lies.

Bringing Order to Chaos

Many projects underestimate the effort required to manage documents. Policies change, templates evolve, and revisions accumulate. The result? Duplicated content, mismatched titles, and version confusion.

Technical authors bring order to this chaos. We align document titles with content, maintain traceability, and ensure that every document serves a defined purpose. When audits come — ISO 27001, PCI DSS, or client compliance — that clarity is the difference between approval and failure, all thanks to proficient technical authoring.

The Hidden ROI of Clarity

Clear documentation saves time, reduces risk, and improves quality. It prevents engineers from reinventing the wheel and keeps managers aligned with process changes. But beyond efficiency, clarity builds trust. When users see well-structured, accessible documentation, they gain confidence in the system and the organisation behind it.

The Technical Authoring Way

The “technical authoring way” isn’t about words — it’s about outcomes. It’s about helping people do their jobs more effectively, efficiently, and with fewer errors. It’s about ensuring that complex systems can be understood, maintained, and improved long after the project closes.

In a world that rewards speed, clarity is still the ultimate accelerator.

Reflective question:

When was the last time your organisation reviewed whether its documentation informs or merely describes?

#TechnicalAuthoring #PlainEnglish #InformationManagement #DocumentationStrategy #ClarityInCommunication #KnowledgeManagement #TechWriting