A large part of project management is communication, and it is clear that a website is the best way to implement this. Status Reports, Requirements definition and tracking, project planning, deliverables, discussions and decisions are much more easily developed and made available using web techniques.
Question to ponder: If you implement a comprehensive website, are formal reviews even necessary?
I have used Sharepoint for multiproject management, and experimented with Google sites enough to realize that they both do a pretty good job. Basecamp and Hyperoffice offer a similar set of features, but I do not have much experience with them.
Here is how to design your site so the users know where to find the info they need.
Identify your stakeholders and their needs. Some examples:
Executive - Status - progress, problems, and financial outputs
Sales - problems, assessments, scope change negotiation, contacts
Technical team - pre release or in work documents and links, customer documentation, policy and exact revisions, technical links
Program - contracts, legal, financial data, bid
Browser interface
File system with checkin/checkout, history and change collection
Wikis
Document Change notifications by email
Point and shoot interface for developing database forms and reports
Integration with contacts data base
Discussion boards:
Sharepoint has discussion boards, fully integrated with the sites and Outlook.
Google Sites can implement something similar, but it is not a full discussion board, and it is not integrated.
Security:
Sharepoint is on your network and uses your security,
Google Sites and Basecamp hold and manage the info in their cloud, using their security system.
Here is how I used Sharepoint. I created a site for each project consisting of the parts below:
Status Reports: Project definition, Wikis, test plans - history was very useful to see changes, and multiple users could update. A company status was possible by combining the wikis. But it was easier to just click through them.
Action Items: List
Customers wanted to have access to our action list, but I emailed them reports. We could have set it up so they could see it, but decided the system was not mature enough for this yet.
Requirements Changes: List - so we could figure out whether the customer owed us money.
Project Documents - Library for each type of document, prior to formal release
Contract docs, test procedures, test results, customer provided docs, component info, Design to Cost runs, internal specs, were each a separate library. This allowed documents to be found quickly.
Reviews: Kickoff, Preproduction ,etc. I created a review document, which contributors would update. Then we would meet as a group to discuss the contents.
Since libraries had check, in/out and notification, it was useful for development of specs, test plans, procedures and other documents before official release.
The active document, and working update were listed. If someone wanted to see an older one, they would have to look at the history file
VCRM - should be able to use a List, but I never did.
Customer contact information
Schedules - Library. I published as a graphics file. I did this for several reasons:
I used Microsoft Project, and most people did not have a viewer
I was using a shared resource pool, and Microsoft Project would not do this if the files were in the Sharepoint system. Perhaps the more capable enterprise version of MSProject would. I chose to keep all the Project Files in one directory with a resource pool, and publish GIF files perodically the program sites.
After doing this, I can't imagine doing it any other way. The next project I do will work discussion boards into the weekly status meetings - the format seems to support this. I am going to try to breadboard this to see if I can get it to work.
Sharepoint
Drag and drop doesn't really work, and operation across domains is pretty immature.
To use a browser, all outputs must be published in a format that is compatible with the browser - so you end up converting or publishing a lot of things just so people can see them.
The integration of Sharepoint with Outlook, although advertised, did not go very well.
Google Sites
The document function is pretty primitive
Notifications by email are intermittent - I may get them, may not.
One Site was shut down to external users for a week, due to "violation of terms". Came back up, no explanation on what happened.
Can't link into pages without editing HTML
Sharepoint allows you to control your data and keep it on your servers, and integrates with outlook. Google requires you to use their security. Their apps are better integrated, but far more primitive than the Microsoft products.
Decide what elements you need in your project, and which will be lists, libraries, link directories, or wikis. Design this away from the site. Get this together before kickoff!!!! Then build your site, and present it at the kickoff. Use the libraries to build large documents like design reviews and test procedures.
Could the release system replace the hardware and software release mechanisms that are in place now? I don't think so, tools like Agile and Sourcesafe are pretty sophisticated, and have solved all sorts of problems and integrate with ERP systems. But for all the other documents on a program, and the databases (VCRM, etc) Sharepoint or Google Sites release system should be just fine.
Management in the internet age is very different than when I started. Click here for an insight into where we are going.