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 method creates document management work that must be performed by each receiver.
• It does not enable convenient and rapid access to previously published information.
• It probably loses project information that should be placed into a library of project intelligence that could be valuable to other projects.
• This problem is far larger than just the communication of status reports.
• The big conclusion: information that will be needed for reference (which I call ‘persistent information’) is not served well by email; a document publishing mechanism is much more effective.

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

• Use of project portals and document repositories, not email, should used for storing and sharing information.  Standardized flows of information that make use of well-designed project portals, reducing a dependency upon email as a primary means of disseminating information, are necessary for efficient team operation.
• The senders of information will have greater success in communicating essential and routine information if they structure their information flows and make effective use of well-organized project portal.  Email is simply not a reliable method of ensuring that recipients will actual see your mail, and is wholly inadequate and ineffective in ensuring that persistent information is retained by recipients.  Recipients should never have the burden placed upon them of filing (for later retrieval or reference) routine or standard information (e.g., status reports, process descriptions, policies, schedules).
• The recipients of information will have greater success in managing their information flows if they develop a discipline of pulling information (e.g., status reports) from project portals.
• Seekers of information will have better chances in obtaining project information by looking on a project portal.  A mature project portal will have not only that sought information, but also related information that can supplement the desired information.

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

• You really can’t be certain that the intended receiver will retain your important information carried via an email message.
• In effect, you may feel that you’ve communicated information, but in fact communication has not occurred.

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:

• They have an easy-to-access (via the portal) library of information to which all information seekers can be directed
• This information is available even when the original publisher is not available
• They have a natural location to publish their materials
• Getting this important information off their PC’s hard drive & making it easily available to team members
• Retention of previous document versions is an automatic function of the repository
• Turnover to their successor is vastly simplified
• Essential project information is organized and readily available

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

• The URL of the portal
• A schedule to use in retrieving and using periodically published documents (e.g., remembering to look at status reports each Monday at Noon)

 Receivers never have to:

• Maintain a folder structure on their PC’s hard drive to store all the documents that arrive via email
• Maintain an elaborate folder structure in their email system for filing and saving all of the seemingly important information (“I’ll need to keep that email”) that arrives
• Keep a long list of repository pointers to document or folder URLs; this pointer information is all on the portal.
• Ask people to wait during a conference call while they search their email and file system for an important document
• Organize their local collection of files & emails as part of a hand-over package to their successor

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:

• Publishers of widely used materials (e.g., processes, status reports) take on the responsibility of designing
  • An initial version of their portal (e.g., WIKI).  Limit your time in designing the portal format; just get an initial set of information published.  This is a portal that is used by all parties seeking project information; you’ll want to structure the portal so that commonly asked questions about the project can be easily answered by a visitor to the portal.  
    • Don’t go into analysis paralysis on the intitial portal design, you’ll never get it right the first time anyway.  Put into place a basic structure and start using it right away.
    • After a month or so, then take time to reflect on how publishers and seekers are actually using the portal.  A well-organized portal will have a higher probability of being used.  You’ll need to wrestle with the question of whether all projects must use a ‘standard portal format’ or is each project free to establish its own format.
  • A structured repository (e.g., MS-SharePoint, LiveLink, iLink), or shared file system so that their valuable materials are available to all team members.  This becomes the only place that this information resides.  Some teams will elect to keep working versions of documents in the repository, while others will choose to place only final materials to be published.
  • An organization web site, containing links to all project portals in that organization.  This web site might also include other information relevant to the organization (e.g., a Blog from the organization director, links to company sites that are relevant for daily activities on the organization), organization charts)
• Training.  There will be a need to train team members on the location and use of the information.  For most people, this should be as trivial as explaining the easy-to-use portal.  For Publishers, there may be needed training in use of the Portal and Repository.
• If there is a ‘subscription’ or ‘alert’ feature, then team members can be alerted by the portal when updated materials are published.  If a subscription feature is not available, then the publisher may find it necessary (hopefully for only a temporary period of time) to send email alerts that updated information is available.

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

• Less time spent by everyone in filing and managing the persistent information that has been arriving in their email inbox.
• A greater amount of your organization’s intellectual property and methods operation are freed from the boundaries of your each team member’s email filing system and are more broadly available to the team.
• Consistent, rapid access by all team members of current process descriptions, status reports, and other project documentation.

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

• Reduction in email messages that have project documents as attachments (it’s just fine if the email messages are still being sent with helpful links to the portal)
• Multiple team members are publishing their information onto the portal.  Publishing is not a job that is constrained to the project manager.
• The portal is used by individuals, during team meetings, and during status reviews
• A ‘Portal Culture’ or 'WIKI Culture' starts to take root.
  • You can ask someone on the project for information and they point you to the proper location on the portal to get that info.  
  • Better yet, your first destination for project information is the portal, and you are successful most times in finding exactly what you want on the first attempt.
  • Creators of project information naturally look to publish their information onto the project portal.
  • Individuals that are creating a process or supplemental guidance information about a process naturally publish this persistent information is in a well-organized portal, not in everyone’s email inbox.

• Here’s one way to assess the usability of your project portal and get feedback.  Ask some people (a mix of project team members as well as those who are not on the project team)  a few of these questions (or others that are more relevant for your project) while they are seated at their computer:

  • How do you access the project portal web site?
  • The Team:
    • Who is the project manager or agile coach? 
    • Who is on the project team?
  • The Project Description
    • What is the definition of the project?
    • What is the committed achievement or result for this project?
  • Accomplishing the Work
    • What is the project schedule?  What is the critical path?
    • What dependencies does this project have(work done by other teams)?
    • What projects are dependent upon the work of this project?
  • Technical
    • What is the logical product/system architecture?
    • What is the logical interfaces/connections with other systems?
  • Independent Testing
    • What organization is testing the product/system?  Who is the primary testing contact?
    • What is the status of testing activities?
    • What are the test results?
  • Status
    • Is the project projected to complete successfully?
    • What is the status being reported by the project?  Who else reports status (e.g., an overall program office or the customer) and what are they reporting?
    • What are some of the most significant issues that are hindering project progress?
  • Management Approach
    • What is the schedule for standing/periodic project meetings (and the objectives for those meetings)?
    • How is quality assured?
    • How are project documents approved and baselined?