• Keeping documentation up to date: The team finishes the application and proudly delivers the related documentation. All is great in the world. Three releases later, a user opens the documentation and not even the screenshots match the application. This scenario is so frequent, the running  joke is that the documentation is obsolete the moment it is written. 
• Determining which version of the documentation to use: The team updates and publishes all documents. However, someone notices that the new version does not include the latest changes and may in fact have reverted to an older version in some areas. The team realizes some members used v3 of the documents for their updates while others used the newer v4.
• Keeping track of the documentation master copy: Documents that have more than one author sooner or later end up with multiple master copies. As people email documents, it is easy to loose track about who has the master. It is all fun and games until someone ends up drinking a few gallons of coffee at two AM, merging multiple documents and hoping that nobody notices how he skipped a whole section.
• The documentation graveyard:  It is unfortunately very common to be tasked to update an application just to find out all the documentation exists in an unmarked grave somewhere in a documentation graveyard on a corporate hard drive somewhere.  When the documentation is eventually found (if it is found at all), trying to go through it feels like being Indiana Jones in the Temple of Doom.  There are mummified code blocks chasing you, poisonous screenshot darts and overall evil forgotten library references that really make the hairs in the back of your hair stand. On the plus side, you get to feel like Indiana Jones, so I guess it is not all bad.
• Formatting hell: This is a typical scenario when trying to edit someone else's document. Surprisingly, the moment you add a simple bullet point, the formatting on the whole page just breaks. Little did you know the original author was a triple document processor black belt with a masters in nested tables. You hunker down, put on your helmet and hope for the best as you wade into the abyss of formatting hell. 

You are probably thinking: what does that have to do with word processors, these are all just bad processes. And you would be partially right, these are consequences of bad processes but the root cause is using the wrong tool for the job.  While word processors are great for many tasks, they are not good for projects because:

• They are meant to be used to write single documents: You write a document save it and move on to the next one. There is no real concept of these documents being part of a project.
• They help us write shareable documents. These documents are expected to be easy to share and email. Unfortunately, this means that very quickly there is no single source of truth.
• They provide no real way to track changes. Yes, it is true that word processors have document change tracking. But, it is way too easy to accept all changes, disable the tracking or even copy the document . At that point all history is lost.
• They allow us to  store files anywhere. Users can store documents anywhere they want, and I mean anywhere: Laptop, server, usb drive, google drive. Finding the right files becomes...well...a bit of a challenge, if you find them at all.
• They provide endless set of features. These features are meant to make documents look great. However, does documentation need to look like a tribute to Michelangelo and his Sistine chapel? Not really. While they should look professional, they do not need to have  flashy formatting. More importantly, the team maintaining the documents nowadays  is the same team doing development on the project and does not have the time for endless formatting matches. They need a simple tool to write documentation as fast and accurately as possible.