1.0 Title: Google Drive projects
2.0 Purpose: These are a simplified pm4g projects which are completely contained in Google Drive and have no other Google services (gmail, calendar, sites, etc.. ) uniquely associated with them. They typically don't have their own Data Dictionary (i.e. no unique jargon) and rely of the hri07e SIG's for deliverable definitions and technology or business background information. (very lean...)
3.0 Usage: Most Project Club and many hri listed projects only exist as Google drive projects currently.
4.0 Frequency: Active 4gd projects (green - see 10.1.1) are continuously updated - or maybe, often;
- the orange and red and purple sites can languish for years.
5.0 References
6.0 Responsibility
The Project Manager (who may or may not be the Project Owner - usually not) is responsible for the project definition, resource recruitment and contracting and execution and quality control - except where she has delegated those duties to other with the consent of the Project Owner.
7.0 Ownership
The Project Owner owns the delivered products generated by the activities of the project team except as restricted by the contracts under which each team member signed up. In some cases Project Owners would be wise to ask for reusable methods or spreadsheets as deliverables rather than one-off reports. On the flip side - some team members may be wise to provide their work on a licensed basis - rather than a one time sale.
8.0 Effort
It is easy to underestimate the time, expense and number of people that it takes to bring even a very simple idea from concept to commercialization. It is especially easy to underestimate software projects - but also any manufactured product. (For example - if the Q-Tip did not already exist - start with the breaking even on the project and work backwards to imagine the simplest path to getting to that point - even by the patent/license route.)
Most pm04gd are basic ideas which must be developed into products. This means that design, manufacturing, marketing, legal, finance, logistics, accounting and regulatory resource people must play their part - and unless you are the superstar with all of those skill sets in place - you probably want to let them do their job and pay them for it.
Now imagine that those 8 different people each require a day to get started - 2 days to complete their job - and a day to wrap it up for you and you already have 32 person-days at perhaps $200/day - and you're starting to get the hang of it.
Now try to imagine a meaningful project that somebody can do in two days.
9.0 Risks
[1] "Google will steal my ideas because the Google EULA says they can".
- depending upon which current (14/02/21) article 8.1 vs 8.4 applies - yes they will and/or no they won't. However - there are no known examples of Google exploiting users ideas for their own products at time of writing; unless you invented Google Glasses or driverless cars maybe.
10.0 Contents
10.1 File folder/Directory structure
10.1.1 top (original gmail username owner org code <acc:code>
There will be an indeterminate number of file folders in the org folder - one for each top level work order.
Further Top level directories also may be created for a limited number of sub-work orders - although it is recommended that sub-work order projects be buried in the parent work order - in the same structure as the parent - to whatever level of sub work orders has been separated from the parent. (warning - this get really hard to navigate very quickly).
Smaller sub work order documents can often safely be tucked into the primary work order directories identified only by the final file name work order string at the end.
10.1.2 project number / work order number <pm:wo>
There will be three standard directories under in the
10.1.3.1 the Deliverables directory (as controlled by the km04 CDRL)
Typically these are various formal reports as required by the contract and are summations of project details or business or legal documents having little visible system organized structure. For most small projects there will be no sub-directory structure required.
10.1.3.2 the Data Sheets directory (as controlled by the km05 ISEL)
Most engineering projects have an (admittedly arbitrary) hierarchical top-down tree structure roughly along the lines of Project -> System -> Sub-System -> unit -> major equipment -> loop -> equipment -> assembly -> part.
For project under construction there will be mutually exclusive alternatives which may be in parallel development - and which both or all may have to be considered for design purposes until a "winner" is chosen. Even then - loosing alternatives have a way of sprning back to life on a moments notice and shouldn't be discarded.
The Data Sheets (km48) are spreadsheets with a summary of all of the quantitative and much of the qualitative data arranged by key code which - if the world lasts long enough - will (someday) allow for automated processing of much of the project data by yet to be thought-of systems. In the meantime they are meant to provide the source links for each of the data items in the Data Sheets as well as its status and history for future nastiness.
For smaller project all of the data sheets may be stored in one directory -
10.1.3.3 the Vendors directory (as controlled by the ils90 - preferred vendors list)
All un-characterized files and drawings supplied by vendors (and probably copyright by vendors) should be kept in vendor files if not permanently available online from the vendor. For very popular, reusable items - the information should be posted in the appropriate SIG vendors section.
note: Most suppliers do not often follow recognized standards for their equipment or software information and the content of these files can be quite unpredictable.
11.0 MetaData
12.0 File Handling Policy
13.0 Procedures
14.0 Tutorials
14.1 pmr8317's YouTube Playlist Google drive tips
- takeaway - share files NOT folders
14.2 Course Name: Google Sites
Duration: 1/2 day Cost: $50 University of Alberta Technology Training Centre