For some time now I've been using a personal wiki product, called TiddlyWiki — stupid name, great program — to do all the organization for my writing projects. My original approach for tracking all the stuff associated with a writing project was just to dump everything in a Word file, but over time that grew unwieldy, and having everything in a wiki makes it easier to search, cross-reference, organize, and reason about. I didn't like the closed-ended approach provided by apps like Scrivener, either, so I decided I'd use a wiki to hatch my own organizational system and see where that took me.
I've written about this before, but every so often I like to circle back and extract key pieces of wisdom about how to use such a system. Here's where my current thinking lies.
1. You're on your own
This is both the best and worst thing about using a wiki to organize a project. You have total control over the format, the organizational schema, all of it. But it also means you have no guidance. Scrivener provides you with built-in ways to organize your story and characters and such, but they're inflexible; they're more or less hard-wired into the app.
A recommendation: Find a schema that suits your thinking about your projects and evolve with it over each subsequent project.
In a way, this is the single hardest thing about working with a wiki. But if you can master it, it makes everything else far simpler.
The trick, I've found, is to simply start listing things — characters, story elements, physical things, what have you — and then adding tags to them to see how many larger buckets you come up with. In my case I have People, Places, Things, Themes (this isn't a total list, just examples).
In other words, start from the bottom, and work your way up to the categories you use.
Some of the categories you're going to adopt will be obvious, common-sense things, like characters or physical locations or in-universe slang/jargon. The others, though, will be more idiosyncratic. I have a "To do in next draft" wiki entry, for instance, that evolved out of my need to have a place to put more general instructions to myself about what to fix next time around.
2. But the effort pays off
The hard part about using a wiki is just figuring out how to use it. But the benefits pay off in the long run, because you now have mastery of a toolset that gives you unpredecented visibility into your story.
People who aren't in the habit of acquiring mastery of job-specific tools tend to resist this. They would rather find ways to force-fit their existing tools to the job. I see this a lot with, say, Microsoft Excel folks who use that spreadsheet as an impromptu database. It doesn't scale, but for most of what they're doing, it doesn't matter — at least until they reach the point where it does, and you never know when you're suddenly going to find yourself staring at just such a wall.
Writers are highly resistant to new tools. I'm familiar with this feeling; I don't want to use anything but Microsoft Word for writing because I'm familiar and comfortable with it. But I also get the impression writers are less resistant to new tools that are less for replacing existing workflows than for augmenting them. A wiki works side-by-side with whatever word processor you have running, so it's meant more to be a sidecar than an entirely new motorcycle.
3. Use the draft process to help fill things out
You don't need to put everything into your wiki up front. Repeat after me: You don't need to put everything into your wiki up front.
I suspect this is another reason people are reluctant to use such a new tool — they don't want to spend inordinate amounts of time with it, filling in their story's details. Nobody's asking you to do that. You can fill in what you need as you go along, and use the draft and revision process as a way to insert such details as they come up. I do this a lot with the plot skeleton I have stored in the wiki; instead of trying to come up with the whole thing ahead of time, I use the second draft revision process to itemize each scene and put it into the wiki.
The opposite of this is also a problem. Some people end up falling headfirst into the wiki, and spend so much time documenting everything that they forget that there's a story to be told. I call these folks "encyclopedists"; they're more interested in worldbuilding than storytelling. This isn't to say that worldbuilding is a necessary evil, only that it's a means to an end. You don't need to create something that's going to be eventually posted on Wikia.com as a portal for your universe; you just need to create enough supporting documentation for your story that it can be internally consistent and readily reasoned about.
* * *
When I first started writing longform projects, I did no formal planning. I was under the delusion — what better word for it, really? — that if I couldn't hold all of the details of a given project in my head at once, it was my fault, and I'd better get good at doing just that. I had to disabuse myself of all that when I started working on Flight of the Vajra, where the sheer complexity of the setting alone all but guaranteed I couldn't rely on my own memory. There was no shame in admitting the whole thing couldn't fit in my head at once. But for some time, that shame kept me from forming, and fully adopting, the habits I'd need to develop projects of that magnitude even with the right tools.
Want to see one of the longform projects in question? Check out my (new!) novel Welcome To The Fold, and showing your support for it by registering at Inkshares and adding the book to your "Follow" list! Failing that, you can always buy one of my existing books, available on Amazon Kindle and in dead-tree format.