What products do you use for your project repository/PMIS? Do you use live forms for items like risks, issues and change control? Or do you store documents in a library/folder structure? If so, where

Hi Kiron. Thanks for your thoughtful comments.

I have seen many benefits from online, collaborative project repositories, such as "single source of truth", stellar version control, highly manageable security that is sufficiently sophisticated as to link into a business's username directory, role-based security to stop the mish-mash that can occur when people assign permissions to individuals, clarity around works in progress and signed off deliverables stored in read-only areas, project contact information all in one place, and lists, such as risk and issue lists in a forms format, where they can be entered one at a time or bulk in what looks very much like a spreadsheet, but on steroids, as they say.

I have found that except when I need a powerful mathematical engine, I prefer SharePoint lists, for example, over spreadsheets. There are many similarities, and the collaborative abilities have caused me to move away from spreadsheets and more toward linked lists.

I believe a tool could be developed to handle many items, even requirements, in a list format. On one project, for example, I created a form for the project charter and PM plan. That had the advantage of being able to show selected parts of these items in views for specific needs, and also allowed one to view items from multiple projects using filtering and sorting methods.

Quality is a tough nut to crack. Processes and guidelines have to be melded with permissions, visibility, access and alerts to maintain or at the very least monitor integrity.

This is also what I am most familiar with, Peter. I have also used other products, such as some open source products for creating web sites, but they are far more difficult to set up as they lack the structure and functionality of SharePoint. Thanks for the input. I knew someone would bring it up.

I agree, Elizabeth. Paper is nice, tactile, easy to read and hold.

But even paper documents these days begin their lives as electronic bits and bytes, to be printed by some and filed in various places.

The electronic versions of documents frequently are sent around in emails as attachments, ending up in a proliferation of versions and/or stored on individual machines in revised states or woefully out of date over time. Even when stored in collaborative portals or shared drives, intended or unintended authors can overwrite each others' work in the absence of versioning controls.

As a project team member, finding what you need can be difficult if you have not had input to the structure of the project repository, or if it is a standard, not having the training on its intent and structure.

A collaborative session with a project team to discuss the types of materials that can be found in the project repository can help with that, and if flexible, the creation of an agreed structure.

Lately, I have found that libraries with folders with the usual sometimes complex hierarchies can be an impediment to understanding and discovery. I've started leaning toward definition of content so that material can be brought up in lists that can be sorted and filtered.

I'm with you, Maricel. I have also used SharePoint for issue and risk tracking, test results, and lessons learned. Have you looked into Content Types for ease of sorting an filtering?

I have found that an action log showing on the project repository's home page is an effective way to raise visibility, and engender action. I usually sort and group them (collapsed) by name and show the number of open items with expandable lists to view the individual items.

Hi Sante. Yes - I agree that sloppiness and lack of productivity can be an unexpected result.

The credo "Start as you mean to go on" has guided me in the set up of project repositories. Agreed structure and processes coupled with effective permissions can reduce sloppiness and even put it to a stop and even lead to higher productivity as people easily find the "single source" and most recent versions.

Careful forethought and collaboration is the order of the day in setting up a project repository.

Absolutely agree, Andrew, except perhaps in the case of a work in progress that the author deems not ready for public viewing.

SharePoint has some very good automatic versioning and multi-author collaboration features, too, that can be used to bar against some of the issues that can arise in document control.