Lessons Learned: Managing Intelligence Projects And Producing Intelligence Products With Wikis (The Good, The Bad, The Reality)

Since late 2006 we here at Mercyhurst have been using wikis to manage intelligence projects and produce intelligence products.  To date, we have done well over 100 wiki-based projects for real world customers in the national security, law enforcement, business and NGO sectors.

Note I am not talking about using wikis to produce wikipedia/intellipedia-like  descriptive articles.  I am using wikis in groups as small as 4-5 and as large as 50 to produce an intelligence estimate similar in scope and format to a National Intelligence Estimate.  You can see an early example of our work here and some later examples here and here.

Not only have we worked for many different clients, we have used a variety of different wiki platforms such as MediaWiki (the platform that supports both Wikipedia and Intellipedia), Wikispaces and Google Sites.

As a result, we have learned a few things about both wikis and collaboration.

One of my goals during my sabbatical (I am on sabbatical now) is to finalize a "How-to" book on managing intelligence projects with wikis I co-authored a few years (!) ago with one of the best teams of students I have ever had the pleasure of working with.

Given my track record of getting stuff done (sigh...), I decided to post some of the more interesting findings in advance of getting the book completed.

Finally, just to make my own position clear:  I am overwhelmingly in favor of using wiki software to manage and produce intelligence products.  However, as the title to this post indicates, there is going to be both good and bad here.  Both our experience and our more formal studies indicate pretty clearly that the "good" is significant.  That said, it would be wrong to claim that using wikis to produce intelligence is a perfect solution and that there is no corresponding "bad" that needs to be identified, managed and minimized.

Without further ado, then, here is a slightly abridged list of the good, the bad and the reality (I will let you figure out which is which...) of using wikis to manage and produce intelligence products:

1.  Wikis don't make me faster, they make us faster...

One of the most frustrating things for many novice users is that a wiki can actually be slower for the individual, in many cases, than doing comparable work more traditionally.  Even when comfortable with the wiki software and the new workflow it often requires, many wiki users believe -- and quite rightly -- that they could go faster if they were just allowed to do it "my way".   

The significant increases in productivity do not come in most wiki work by making the individual faster.  Instead, the key to a wiki's success lies in eliminating many of the transaction costs of doing collaborative work.  

Wikis make an intelligence team faster by streamlining communication, storing data in one easily accessible location, and allowing a team to work together in a near real-time environment. The seconds required to open, edit, save and send a file, are all removed from this process, adding up over the course of the project and saving the team valuable time and ending confusion. Team members can operate on multiple tasks simultaneously and once a task is done -- once a paragraph is written or a file uploaded -- it can be easily referenced and copied by others; it never has to be done again. 

2. You can't break a wiki...

... or, at least, most wiki software makes it really hard to do so.  Unlike an installed computer program, where you can corrupt a file or create the need to enact a complicated series of actions to fix a mistake, a wiki has built-in safeguards to protect against loss of information.

For example, a blank page can serve as a "sandbox" where those new to the technology can practice uploading pictures or try their hand at formatting text.

Poor edits or erased information are also easily undone or recreated by the "revert" function common to most wiki platforms. Wikis typically save a history of changes made to it, so when a first time user attempts to correct a spelling error and finds that they erased an entire paragraph, all is not lost. Reverts allow users to restore the wiki to its last saved version.

Most importantly, however, wikis encourage "play". This means that users, once they overcome the technological learning curve, are empowered to try new things. This type of empowerment is what leads to new and innovative uses of the technology that can enhance the intelligence process.

3. Wikis reflect the reality of the intelligence process

As I have been discussing in my "Let's Kill The Intelligence Cycle" posts, the modern intelligence process requires analysts to perform many tasks in parallel rather than completing individual tasks in sequence. Wikis accommodate this more accurate depiction of the intelligence process. 

One action performed in a wiki simultaneously accomplishes several other goals. The decision to create and the act of creating a page, for example, is also a decision and act of modeling, collecting, analysis and shaping the final product. Wikis complement the real intelligence process almost perfectly. 

4.  Wikis remove the "box"

The new realities of intelligence require that analysts think "outside the box" with regards to threats and opportunities. This means breaking out of mental traps such as "mindset" and "groupthink", and to challenge one's biases.

Wikis help in that they provide a number of ways for many different contributors to participate.  From the full time team member to the casual reviewer, there are many simple ways for new information, differing opinions and alternative analysis to work their way into the wiki format.

Wiki discussion pages, for example, encourage analysts to question both method and process. The instant updates to information can inspire an analyst to reconsider a thought or follow a new lead without confrontations or lengthy meetings.

Many wikis feature wikimail or wikichat features so that contributors can have both private discussions and real-time interaction.  Most wiki platforms also have notification services that allow users to watch key pages or even the entire wiki for substantive changes.  Likewise, many modern wki platforms have a number of "membership" options allowing some people to contribute but not administer the wiki, some people to administer and contribute to the project and others to merely access the final product. 

All these options (and others) serve to enlarge and deepen the intellectual space in which the intelligence unit can work, without giving up control of the core aspects of the process or product.

5. Wikis make managers more efficient

Wikis give managers an unprecedented window into the intelligence process.  They can track progress, deal with problems, and assess results from the receipt of the requirement to the delivery of the final product.  This allows managers to provide more timely feedback or even redirect the project as needed.

A manager can be involved as little or as much as required without having to call a physical meeting, pick up a phone or write an email. Discussion pages, chat functions, and access to direct editing of the wiki allow managers to help analysts refine and shape the product as it progresses and maintain contact with the analytic team without taking up time better spent elsewhere.

At the end of the project, the wiki serves as an incredibly complete audit trail for evaluating the results of the analysis and for implementing changes with regard to future projects.

6. Wikis answer the intelligence requirement better

An intelligence product on a wiki that is well-structured, well-designed, optimizes hyper-linking and takes maximum advantage of relevant multimedia achieves a level of transparency and depth that traditional intelligence products simply can not provide.

A decisionmaker can immediately click a link to discern where information came from, check the history of a page, or read over discussion pages to see how a train of thought evolved throughout the project.

A wiki provides more readily available information than the standard printed final product. Moreover, the wiki can even be formatted to produce a printed product to accommodate the preferences of the decisionmaker.

7.  Wikis have a learning curve

With wikis, there is not only a technological learning curve but a social dynamic learning curve as well.  The collaborative environment that wikis create can be an unsettling experience for some people. 

Analysts used to a certain working environment or working alone at a desk with the occasional meeting must now learn to work with other analysts in an online environment in which every sentence that is posted is immediately available for all to see and comment upon. A shift in thinking and work habits is required to absorb, what is for some, a radical change in how they perform their duties.

As far as the technological curve, since most wikis work similarly to a word processing application, many may adapt to the technology with relative ease.  Still, it is one more application for intelligence professionals to learn. 

Likewise, the internet or intranet nature of wikis makes it virtually certain that they are not as sophisticated as standalone word processing or presentation software packages.  The frustration that accompanies the sense that "I can't do what I want to with this damn thing" is real and often underlies the dissatisfaction intelligence professionals sometimes have when using wikis.

The solution for both issues is immersion and most successful wiki-based intelligence projects insist that users put everything on the wiki from the very start of the project.  Wikis need a critical mass of information on them in order for their utility to become obvious to a team new to working with a wiki. 

Casual or hybrid approaches to using the wiki may work but often do so in spite of the team's use of a wiki rather than because of it.  The wiki learning curve is steepest at the beginning of the project and the sooner and more aggressively the team begins to climb it, the better.  Managers that insist their teams climb this curve are likely to be unpopular at first but the benefits of the hard line approach will typically become evident to all well before the mid-point of the project.

8.  Not all wikis are created equal

All wikis allow a user to easily create and edit a page.  However, some software packages are easier on the user than others and this adds to the difficulties inherent in the learning curve.

More importantly, a truly great final product on a wiki doesn't just happen. Words are not magically fed into an online machine that automatically creates a relevant and substantial report.

A good and creative analytical team can craft a visually appealing, cohesive and insightful final intelligence product using a wiki -- but it takes work.  Even good software can't fix poor analysis, sloppy editing and unappealing formatting.

9.  More interaction ≠ peaceful collaboration

Enhanced interaction amongst analysts does not always mean that emotions and good manners will be kept in check. Written communication is easily misconstrued and, unfortunately, some people will find it easier to write scathing criticisms than speak it aloud.

Some wikis have developed their own sense of culture and social norms. Wikipedia, for example, maintains a strict code of civility which contributors and editors are expected to follow.  Just because some wikis have such rules and social norms does not mean that your wiki will have such rules or social norms, though. 

Nor might they emerge from the routine interactions of the participants in the wiki.  Establishing rules of the online workspace and good management can overcome poor social dynamics that threaten the success of the wiki.

10.  Wikis permit micro-managing

The transparency and usability of wikis allow managers to follow a project from start to finish. This can make managing one or more teams infinitely more efficient, but some managers take it as an opportunity to micro-manage.

Managers who comment on every post and every analytical statement, or continuously edit work are considered disruptive editors. This kind of behavior hinders analysts' progress and discourages them from using the wiki.

It can be difficult to know how much managerial involvement is too much, but an invasive manager or a "do-it-all" can prevent analytic wikis from evolving past a place to store information or the personal insights of the manager.

 11.  Wikis lack a substantive look and feel

Instead of dropping a thick report on a decisionmaker's desk (accompanied, of course by an "Executive Summary", a final product based on a wiki is merely a link to what looks like a single web page. The decisionmaker is deprived of the tactile feeling of depth of thought that a printed report can inspire.

In the book, we discuss more fully some of the details regarding the preparation of a wiki for delivery as a final product to a decisionmaker. No matter how it is structured, however, it is very difficult to convey the depth of a wiki-based product.  While this effect may become less acute with the passing of the generations, for many readers it will continue to look like a single page.

12.  There are times when you shouldn't use a wiki

• Reconsider using a wiki when the technology will not be available to all members of the analytical team. Two or more people who do not have consistent access to the wiki on a small team during the course of the project can hinder work flow and positive group dynamics.
• Reconsider using a wiki if anyone on the team is in a position such that they can refuse to adopt the technology. While wikis are easy to learn and employ, some people may not be sold on their benefits and people operating outside of the group workspace will make it much harder to create a successful wiki-based intelligence product.
• In the case of simply needing to create a database or other highly specialized product, consider that the project may be better served with specialized software.

There's lots more, of course, and I hope to be able to get to it in the next few months.

(Many thanks, again Kathleen, Kevin, Stephanie, Joe Ellen, Ethan, Emily and Emily!  I promise -- I am working on it!)