Indaba: How it works

Indaba is a tool to manage projects that create information. In practice, that means text, numbers and files. An ideal Indaba project involves information — an essay, a scorecard, a photograph — that is created in distinct chunks at large scale by a team of creators and editors. Some examples of scaled projects:

• completing a scorecard (with numbers and commentary) of public policies in 100 governments,
• writing an overview on water rights in 20 provinces,
• reviewing and commenting on a strategic plan by 50 stakeholders,
• taking a photograph of and writing a caption for every primary school in Nairobi.

There are other uses for Indaba, but these scaled projects are ideal, because Indaba rewards repetition. The reason for this is the Design phase: we’ll take a complicated process and make it visible and repeatable. This allows the Builder application to keeping each piece of information moving along its workflow, even if individual editors or authors never see the whole picture. When the project is complete, the Publisher application gets the information onto Web sites or print documents.

Phase one: Designer

Technology won’t make your organization run better. But planning does.

Much of the first phase of an Indaba project happens with a pencil and paper. The Indaba project manager and her team will make a list of content objects (written text, scorecards, photos, or movies) that will comprise the finished product. Then she will list the targets of the project — the things that the objects are written about (places, government institutions, facilities, people). Then she’ll list the people who can help create this content (field staff, editors, peer reviewers, maybe the public).

Next, the designer will draw a flow chart, on paper, describing every step a piece of content takes between the first author and the final proofreader, including all the project managers, peer reviewers and editors who will need to see each piece along the way. While we do this, we’ll also list all of the non-content events that are triggered along the way, such as paying an author and telling him it’s time to log into the system again to review someone’s comments about his piece. In the process, our project manager and her team are starting to create many specific goals, which are linked into a workflow (or several parallel workflows) that will govern her project from start to finish.

This process takes implicit knowledge about a project — the stuff in the designer’s head — and makes it explicit, where other people can read it, follow it, reuse it, improve it. This process of transferring implicit knowledge to explicit knowledge — making the invisible visible — is essential to running large projects efficiently.

And we haven’t even turned on the software yet! Once we have all this figured out — the content, the targets, the people, and the workflow — we plug that information into Indaba’s Designer, which creates the custom code to define the ecosystem for the project that we’ve just planned. Compared to the hard work of developing a working business process, the rest is data entry.

Phase two: Builder

A reporter in Perth gets an invitation to write for you. Great! He uses the invitation email to create an Indaba account. On first log-in, he’ll update his contact information and tell Indaba how he’d like the system to contact him (email, usually). If the project is multilingual, he’ll choose his preferred working language.  From there, he’ll get an assignment list, with all the deliverables he’s contracted to send in. All content that he creates for the project is dumped directly into Indaba through its easy-to-use, low-bandwidth website. Text and scorecards are edited in a simple browser interface and stored on Indaba servers — if your reporter loses a laptop or the electricity cuts out, the work is safe. Photos or video are uploaded as attachments. When he’s done, he submits the work, receives a confirmation email from Indaba (the text for which you’ve written during the Designer process) and he’s done.

When that happens, a goal has been achieved. Goals can trigger the Builder application to run various events, like emailing an editor an alert that the reporter in Perth is done, or adding the Perth report to a queue of work that needs to be reviewed by peer reviewers. From there, a decision is usually made: someone decides to send it to editors, or send it back to the author for revision. In either case, this decision completes another workflow goal, and triggers more actions, such as an email to the reporter in Perth with a list of required revisions.

And so it goes, up the chain, with each step logged on the document’s history, creating a transparent trail of actions and events along the way.

For project managers, all of this information is available in a few clicks from a central Indaba dashboard that illustrates, visually, where each piece of content is and how it got there. When problems arise, there’s a case manager that lets associated users see the problem, discuss solutions, and respond.

Phase three: Publisher

When a project nears completion, all of the project content is already stored in a distribution-friendly database. This avoids all kinds of problems with version control, missing files, and getting the right people access to your hard earned content.

For the easiest possible production process, Indaba will embed content anywhere on the Web with a few lines of code. Since Indaba content is often text or scorecards, this works well, and will come marked up with HTML tags ready to inherit the text style of the embedding site. Alternatively, all content can be exported in a variety of formats which can then be added to an existing content management system, print publication, or data repository.

The techy details…

Indaba is being written in Java, and will be running on something like a LAMP stack. While we are using open-source code whenever possible, much of the code is new. Alternative approaches that were considered included Drupal, licensing a proprietary data engine, and integration with Salesforce.com. None met the requirements of robust workflow capability, broad programming community, and scalability.

On semantics: For discussion purposes, we consider Indaba’s data model and the hosted database to be the “platform,” which includes both the published content created with Indaba as well as operational libraries, like tag vocabularies or question archives, which are shared across organizations using Indaba. The platform runs several applications which get information in and out of the core database. The core applications are Designer, Builder and Publisher, which every project will likely use. Meanwhile, Indaba’s data model was designed with a high level of abstraction, which will allow new applications to be created in the future to design and execute innovative projects we can’t anticipate now.

Indaba does not have API access. Yet. But we’ll get there. If you’d like to work on building out the Indaba API, give us a ring. In the meantime, Publisher will allow users to post their content via a simple embedder, as well as export the complete content library in a variety of formats. It is a core principle of Indaba that all content created in Indaba can be migrated out at any time without cost or effort.