1.0 Title: Collaborative "Google Apps" Project
2.0 Purpose: To use the low cost, accessible and relatively robust Google cloud applications - primarily Google Sites, Google Documents, Google Calendar and Gmail - to host and coordinate engineering and business projects to a point where they can be successfully funded for a "higher end" platform such as BIM or PTC - or for smaller projects - completed entirely within the Google framework.
3.0 Usage: This is an hri07e project deliverable definition but can be used by any organization as a guideline for setting up a collaborative project. For hri07e formatted projects it should be used verbatim. For non-hri projects it can be tailored to suit.
4.0 Frequency: Once a project site has been setup it becomes an active, more or less "real time" collection that will be changed frequently and will be subject to all sorts of inconsistencies if proper configuration management principles are not followed. The Dashboard is designed to manage the information and the Calendar should be used to coordinate and sequence the activities.
When the project is complete two things should happen:
- the sites, docs, calendars, emails, logs (especially the logs) should be archived <somewhere??>
- the site should be reviewed by the Knowledge Management SIG for publishable knowledge that will benefit future projects.
5.0 References
6.0 Responsibility
The general upkeep and compliance of a pm4g project site is the primary responsibility of the Project Manager (not the Owner) as delegated to the Webmaster if there is one.
7.0 Ownership
The Project Owner - whether it be a person or an organization - should be assumed to own all of "deliverables" of the project - which will normally include an archive of the project sites and documents. This will not include information borrowed from other projects or the SIG CDID's - but will include any new CDID's and procedures paid for by the project. It also does not include items which must be copied to the project but are copyright by others or expressly included in the project contract by the resource person who owns the contract.
The ownership - and hence the project number and the file numbers - will NOT be HRI unless the project
owner is Hammond River Institute, which it normally won't be for collaborative projects. While many of the resources and the Owner may be HRI members - an account (org) ID must be identified - which forms the basis of the project number (a.k.a. work order number or wo#).
In general all files ending with the wo# belong to the project - and all files ending with other wo#'s such as "hri07e" do not.
NOTE: Contractors (a.k.a. resources) who are required to deliver documents to the project that they do not wish to be owned by the project (even if the project must retain a copy) should use their own contract number as the wo# on any documents they submit to indicate that they retain the rights to the IP in the deliverable - outside of the "license" for its use within the project.
recommended practice:
The project owner should create a gmail account for the project and copy the format from the hri07e pm4g template. The Project Manager (if from HRI) will be responsible for hri07e compliance from the projects side and the hri07e QA manager will be responsible for telling her why it isn't (compliant) - and what she should fix.
8.0 Effort
The overheads of creating a pm4g projects are a small. A Gmail account and a clone of the template website are relatively quick to setup - perhaps a couple of days for somebody who has never used it before - a couple of hours for those who have. While some resources may complain about the formality of the site and the time to log in and upload - the faster way is to do nothing - which really takes very little time, but won't get the resource paid either.
The actual project effort could be enormous - but that is not because of the pm4g process.
9.0 Risks
There are a number of risks associated with using the pm4g approach to collaborative projects. In rough descending order of consequence they are:
Google policy change:
Nobody knows when Google might announce that an important element of pm4g might be discontinued - as they have done with Labs and Wave and numerous other services. One assumes that Gmail is solid - and that since sites and docs are part of Google's basic business cloud offering that "nothing bad will happen" but they could. Backups of all items are a must.
Google service interruptions
Google data farms and communications are as solid as they come - but who knows what cyberwar might come down the pipe and wipe out everything. If that happens your ability to collaborate will be gone too so you may have to resort to carrier pigeon if any of them are still alive.
Google security breach
- yeah maybe - but smart money would be on Google's security team over your security team any day of the week.
Team Sloppy
The easiest and most likely (90% maybe) security breach will be the resource who uploads a document and "shares" it with the world - which is the default in Google for everything. Aside from nagging about it - it will probably happen. Fortunately most project documents are incredibly dull reading and require other documents to be useful.
10.0 Contents
There a four primary Google applications that make up a project being carried under CDID pm4g hri07e:
- Gmail https://mail.google.com/
- Google Sites (you're looking at it) https://sites.google.com/
- Google Drive https://drive.google.com/
- Google Calendar https://www.google.com/calendar/
and pray that Google doesn't change their structures during the life of your project:
10.1 Gmail
A new gmail account may be created if the Project Owner does not have an existing account they wish to use. In that case the wo# should be assumed to be the "webmaster" for the site.
Since all pm4g project are "role based" - the following pattern should be used (eg: where hri07e is the project / wo#)
hri07e = webmaster (email: hri07e@gmail.com)
po-hri07e = project owner
pm-hri07e = project manager
arch-hri07e = system architect
dev1-hri07e = developer 1
se-hri07e = systems engineer
10.1.1 Subject Headers for pm4g project emails
To facilitate the automated segregation of incoming general purpose emails - the subject header should always start with the work order no:
eg: "hri07e project update"
if the email is about a single deliverable - or a single key code
<what happens?>
10.2 Google Sites project elements
- home page
1 - Dashboard
The Dashboard should indicate the approved current total estimate of the project versus its current status. It should also allow "drill-down" into details and "roll-up" into summary levels (not a trivial thing to accomplish).
Elements to consider are:
- Project Plan revision number & date. (also - "days since revision", also note - "plan" implies "budget")
- Total number of tasks + status (future, active, next, hold, complete)
- Total number of resources + status (future, active, next, hold, complete)
- Today's tasks (open, late, complete)
- Today's budget (used, remaining, over-spent, under-spent)
- Total Budget, Future Budget (funded, unfunded)
- Tomorrow's Tasks
- Burndown rate
2 - Task Description
Objectives
Statement of Work
3- Project Deliverbales
List of deliverables (CDRL)
deliverable definitions (CDIDs)
primary source: project hri07e
project cdid’s: none (usualy)
Integrated Systems & Equipment List (ISEL)
4- Resources
Human Resources
Financial Resources
Hardware Resources
Software Resources
5- References
Bibliography
6 -Procedures
7 -Vendors
8 -archives
10.3 Google Drive project elements
The bulk of real project documentation and deliverables will be contained in "docs" for most projects, including some files which are cannot be processed by the docs (such as dwg and zip files) and which may have to be "zipped" to be uploaded. (photo and video files can be uploaded to YouTube and Photos or Picassa but this requires new permission links to be sent and needs to be noted in the dashboard and CDRL.)
note: pm4g files in Google Drive
USE THE Google Drive Details/Definition fields for project management
every project file document "should" have
pm:
pm:status - document status
pm:statdate - document status date
pm:owner - document owner
pm:planstart- planned start date
pm:planend - planned end date
pm:actstart- actual start date
pm:actend- actual end date
pm:res - resource code
pm:resincumb - incumbent resource
pm:plannedhrs - resource code hrs
pm:actualhrs - resource code hrs
pm:forecasthrs - resource code hrs
km:docsum - document summary
km:tag- semantic tag
pm:cdrl
pm:cdrlitemno
To execute a project using Google Docs/ Google Sites
- the pm4g Google Docs template is (NO LONGER) the recommended structure.
- project hri07i1 kinect PC controller is a better model
The structure is a series of sub-directories under the parent directory which should be named in the format:
<wo#> <project code name> (pm4g)
NOTE:
all of the "tagged" files that are part of the project (and which haven't been paid for by some other project) should be named in the format:
<cdid> <cdrl title> <wo#>.<DOS file extension>
all of the "tagged" files (those which have a "tag" - typically equipment or physical connectors such as pipe or cable)
:<sys:partag>:<sys:tag> <cdid> <this part varies> <wo#>.<DOS file extension>
The sub-directories are:only 1 - archive (for obsolete or undefined files)
calculations: All files for calculations for a pm4g project should be located in this directory. If Intellectual Property is a concern to the point where individual file sharing privileges are insufficient then sub-directories with separate sharing list access can be created - but this may make linking rather awkward.
10.4 Google Calendar
11.0 MetaData
The current version of project ri07e (infosys2) is not advanced enough to produce dependable RDF outputs and data sheets as per SIG:KM's wish list. In fact - it may be a long time before that happens.
11.x File Hashtags {pm:filehashtag}
CDRL deliverables and Data Sheets for project should (in the future) generate a hashtag for the file every time it is edited as a means to check against secret or unauthorised changes to the files.
12.0 File Handling Policy
For pm4g projects
- do not send documents as email attachments
- do not post documents in the work order site (if there is one)
- always use km3 hri07e nomenclature - if there is not appropriate CDID, reserve one in the appropriate SIG. (see 13.0 km3)
- create a "collection" using the wo# reference in Google docs (now Google "drive") and share each document as required. Do not share the folder.
NOTES:
[1] How far do Google Drive's terms go in 'owning' your files?
Summary: Google Drive's terms of service allows you to still own your own files, but grants the company a license to do 'as it wants' with your uploaded content.
By Zack Whittaker for Between the Lines | April 24, 2012 -- 17:52 GMT (10:52 PDT)
[2] (excerpt) Google moves forward towards a more perfect SSL
Summary: Google's enthusiasm two years ago for Forward Secrecy makes a lot of sense considering all the revelations in the last several months about NSA monitoring of everyone and everything.
By Larry Seltzer for Zero Day | November 20, 2013 -- 13:30 GMT (05:30 PST)
".....Whenever I write about all that Google does to protect its users I get snark-back about how they're digging through your private content in order to sell you things. Well, yeah. That's what you agree to in exchange for all those cool free services and the best protection of your data they can give against those with whom you have not agreed to trust your data. If the prospect of seeing an advertisement that has been tailored to your interests is that scary to you, take your business elsewhere...."
13.0 Procedures
To setup a pm4g project on Google sites - copy the example site that was prepared for another project and use that format which is supposed to follow section 10.0, but may "evolve" somewhat as it gets used. "Somebody" (i.e. the author of this CDID) should make sure the two match each other as this happens. "Somebody Else" - i.e. the QA crew - should ensure that that happens.
14.0 Tutorials