Print
Hits: 23992

Email  Creates Documentation Clerks; A Portal/WIKI Creates Valuable Information Stores

Bill Hoberecht - This email address is being protected from spambots. You need JavaScript enabled to view it.    

It is nearly impossible to make good use of project information that lives on private stores (e.g., a PC’s hard drive) or in email.  Project information that is sent via email can easily turn the recipients into document management clerks; truth is, few of us are good at that, and our feeble attempts at keeping track of documents will almost always result in misplacing our outdated information.  Creating a project portal (e.g., a project WIKI) provides a natural place to publish information, and it is also a convenient place to look when project information is needed.  This article builds a compelling case for establishing a project portal and document repository. 

 

My Story - Too Many Documents

I dread Tuesdays.  At various times leading up to noon my inbox fills with weekly status reports from a dozen project managers.  These status reports are sprinkled amongst all the other email traffic I have arriving on Monday and Tuesday, with inconsistent subject lines and originators that change from week to week (due to vacations, sick days, changing responsibilities); as well, I am the first person that ever has visibility to the entire collection reports, so I am the first to notice that the breadth & depth of content varies widely between projects. 

My review of status information is a scheduling activity on my calendar, so I rarely read a status report when I first see it arrive in my inbox, thus I need to have a way to find that report later it is time to review all of the reports.  I tried to file the reports within my email system, but soon discovered an email allocation limit that prevented this from working well.  Next I went to using a folder on my PC’s hard drive, extracting the reports from email and storing them on my PC. 

Just a few weeks into using this method I found myself managing status reports, planning documents, issues lists, risk plans and numerous other project documents for a dozen projects.  Then the epiphany: I had become a centralized document management clerk for my organization (which is quite different from the leadership role I was hired to perform!).   Here’s what I concluded about this method of distributing documents via email:

 

This article is aimed at increasing the effectiveness of project and company communication of written materials:

If you have relatively small volumes of email traffic, then this article will likely be of little value to you.  However, the rest of us are often overwhelmed by the absurdly high volume of information that is cascading to us, and the remainder of this note article may prove useful. 

 

The Pitfalls of Using Email to Send Information That Must Persist

Email is fast and easy to employ and is universally used – these strengths make it natural as the only choice when distributing persistent information and documents – for a ‘sender’ there is no apparent need to investigate and learn other methods that can be more effective. 

 

However, email fails as a medium for publishing materials that provide lasting value to an organization.  This use of email creates two fundamental problems:

  1. Reference Information will not be Available to Everyone. That information sent via email yesterday will probably be misplaced by a few people, so they will not have any lasting benefit from that email.  Also, with the dynamic nature of project teams and organizations, email cannot assure that all team members will have that reference information - how does the person who joined your team today learn about that important information that was sent via email yesterday?
  2. Information Receivers Become Document Management Clerks.  The reference information that you (and many others) send via email must be handled by each recipient.  Each receiver, must invent a way to organize (for later retrieval) all of that persistent information that comes their inbox.  Once they take the time to build a filing method they still must process each received document.  Most recipients don’t have an effective filing method; as result, subsequent retrieval of documents is inefficient and unreliable

 These flaws in using email to send Persistent Information causes the method to be rather unreliable

  

Organize Information in a Portal, Store Documents in a Repository

It’s not just a matter of sending your information with high priority or using other flagging/reminder techniques.  Those methods will not address either of the fundamental failings – for that, an entirely different publishing mechanism must be identified, implemented and used.

Here’s a much better method of publishing materials that will persist, be readily available to current and future team members, and can help people rapidly locate the information that they need:  publish materials in a document repository to which all team members have access and create a web-based portal that organizes information and makes it easily accessible. 

Team members in search of information will use the portal to locate the information they seek.  For a smaller project, this might be as simple as a single web page that presents and organized view of the project information; this could be a mix of text coupled with an assortment of published documents.  For large projects, there could be a hierarchy of pages that contain project information and pointers to project documents that are stored in the repository.  Create the portal so that it is intuitive, structured to meet the needs of information seekers, and easily accessed. 

The repository contains the project documents and provides version control, access logging, and also security & access controls. I’ve implemented these methods in various companies using technology solutions that were already in place.  Here are three example implementations:

  1. MS-Office tools/Shared Network Folders.  15 years ago, before the wealth of web-based solutions were even a concept,  I created this basic implementation:
    • Portal.  A standard MS-Word document used by each project.  It was published in a known location on a network server.  Anyone in search of project information would open that document (read-only) from that network location; the document was essentially a project plan outline.  Each section of the document was the path to a file stored in the repository.
    • Repository.  A system of folders on a network shared drive.  We elected not to use the version control system (that was used by software developers), but it was available if needed. 
  2. MS-Sharepoint.  Using an early version of MS-SharePoint as a single solution.  (The current version of MS-SharePoint is a very powerful option that you should consider if you have that technology available to your project team).
    • Portal.  In this version of MS-SharePoint, we had basic abilities to create a hierarchy of web pages, including text and URL’s for project documents in the repository.
    • Repository.  MS-SharePoint had a sufficiently rich set of controls on access, with retention of previous versions.
  3. WIKI and LiveLink.  Easy to use WIKI publication coupled with industrial-strength LiveLink content management.
    • Portal.  WIKI pages for organizing project information, providing an easy way for project team members to find relevant project information.  WIKIs are straightforward & easy to use.  (Most WIKI products have document storage capabilities, but these lag significantly behind enterprise content management  or knowledge management systems)
    • Repository.  LiveLink provides a full set of version control and security features.

  

Extraordinary Benefits to a Portal & Repository Solution

I’ve seen that the advantages to implementing a portal and repository for project teams is compelling, and most project managers who have starting using this method have agreed.  Document management is much easier for those who create and publish persistent information, is much more complete for those on the receiving end of that publication, and seekers have an easier means of fulfilling their information needs.

Document Management is easier for publishers:

 Receivers have few details to remember (and no more set of documents to continually manage):

 Receivers never have to:

   

Objections to the Portal and Repository model

Every organization that I’ve directed has had resistance to abandoning email for distributing persistent information.  As with any small or large change to an organization, it is wise to have an approach that recognizes and responds to the likely objections.  Here are few challenges you may encounter: 

  1. “I don’t have time to learn how to use the tools.”
    • This is the most frequently encountered objection, and it speaks to the fears that some individuals have about learning something new.  For them, it just seems easier to continue sending information via email
    • Make it easy for everyone to learn how to use the portal and repository: publish (on your Portal) helpful guides for first-time users, conduct group or individual hands-on training sessions – you can probably cover all of the key points in an hour or less.
  2. Repositories are slow sometimes
    • If the slowness is intolerable, then this could be a show-stopper.  You’ll need to ensure that the implementation is based upon a usable repository.
  3. Access permissions prevent team members from getting the information
    • Until access permissions for the repository are sorted out, there may be annoying instances when a publisher or recipient cannot use the repository.
    • Ensure that your information publishers are well aware of how to set access permissions; ensure they all have published a method so that information seekers can contact the proper publisher when access rights are needed.
  4. Lack of an easy-to-use portal technology
    • If your company/organization does not have MS-SharePoint or WIKI Web tools, then establishing a portal can be a non-trivial activity.  The best case is to find tools that the company already owns and has deployed.  Other approaches (purchasing the technology, subscribing to a outsourced service providers) all can be complex endeavors.

One fear, often unstated, is that the transparent publication and sharing of project information can put a spotlight on the shortcomings of the project manager, the project team, or the project.  I have seen many cases where the published project information has given me a newfound visibility to these problems:

  1. Little or no organization of project information.  Just a mess of information and files.
  2. Overly complex organization of information.  Takes too long to find anything.
  3. Lack of clear project leadership.  The efforts of the project team are not focused properly.
  4. The only person publishing is the project manager.  Others, even those with assigned lead responsibilities, are passive participants in the project.
  5. Unclear communication.  Inability to articulate project information project (e.g., description, charter, scope statement) clearly.
  6. No ongoing management of information.  Following the initial publication of the portal, the level of chaos increases in the absence of ongoing portal management actions – the portal or portal become a tangled mess.

 

While these were problem areas before, the Portal/Repository implementation served to bring these issues to the surface.  If you are a project manager who is considering moving to a Portal/Repository method, your implementation plan will probably need to have multiple iterations as issues, like those listed above, are discovered and correction actions are identified.

    

What's Next?  Getting started on a Portal and Repository Implementation

Improving the flow of electronic information in a program or project is a never-ending task.  The key is this: publishers are originators of information – as owners, they have the responsibility to structure their information.  Recipients must have a responsibility of learning about portals and pulling information from repositories via portals.

 

If you are not using portals now, here are a few steps you can take to get started on a portal and repository implementation:

 

That’s it!  Once your portal is up and running, you should start seeing these benefits:

  

A few weeks following the inauguration of the portal, evaluate how well the implementation is working – here are some indicators: