Difference between revisions of "GLMDB Project & Task Policies"

From GLMWiki
Jump to: navigation, search
(Housekeeping)
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This area of the Wiki will contain procedures for all action items that occur in GLMDB.
+
''* Current Project Supervisors: Steve, Chuck, Charis''
 +
== Housekeeping ==
 +
* Every Monday, before the status meeting, check whether any of your tasks are able to be taken off hold, or are better archived, or are duplicate, or finished, and change the status as per the guidelines below.
 +
* If a task is better to be reassigned to someone else and it's not for review, inform the relevant Project Supervisor and get permission to assign it to them instead.
  
TASK MANAGEMENT
+
== Informing the Team ==
 +
* If for any reason you place a high-priority task on hold, inform the relevant Project Supervisor - this is best done through GLM Webmail.
 +
* If you place a task on hold, inform anyone that depends on that task's completion - this is best done through GLM Webmail.
  
Proper logging procedures include:
+
== Notation ==
 +
* Every separate item added to a task must be prefaced with [] (closed square-brackets) so that it can be filled in upon task completion. This can be done with one's initials, or an X, or a ✔, o, ✕, ✗ or whatever as long as it's clear.
 +
* Every time you are told something in person or make notes during a meeting please '''note them''' in the appropriate task. Do not rely on your memory. Do not rely on others' memory. Keep record of everything you are told or asked to do, and everything you indeed do.
 +
* In that same thought, if you have a question it is better to pose it in writing than it is to convey in person.
 +
* If the box is filled like so [!] or so [?] it means there's something that needs to be addressed. Don't expect the reviewer to notice this, make note of it above ("See the box I filled with a question mark, do I still need to complete this item?")
 +
* Every time a new item is added, do so at the top so it does not get lost.
 +
* Every time the project status is changed, note at the top when it was changed, who changed it, and add a brief explanation. What follows are some examples, it need not look exactly like this as long as the information is preserved:
 +
4-21-2016 - Laury: Ready for review
 +
11-2-2015 - LGvR: On Hold because we need to finish the DiscoverKalamazoo member DB first
 +
1-1-2014 - Laury: Ian, could you please have a look at the marked items on this task?
 +
* The more clarity, the better! It can save a LOT of wasted time and effort if you use a few extra seconds/words to explain what part of the site you're referring to, and who you intend to have finish an item. Saying simply "This doesn't work" doesn't help.
 +
* The less clutter, the better! Try to avoid verbosity. Nobody has time to read your prose (unfortunately).
 +
* Keep your logs and notes professional, impartial and informative: No remarks on the intelligence of the creator of a plugin or a client are necessary - we likely already know and it is not the place.
 +
* Place notes in the Description, not in the Task Log - they will get lost down there and cannot be edited, and not everyone expects pertinent information to be down there.
 +
* Things of particular importance to the reviewer should be '''bolded''' using HTML tags. Use this sparingly.
 +
* It's friendly to wrap particularly lengthy links in anchor tags with target=_blank and named with where they go
  
Accounting for task by authorized contact/billing name, description of work to be performed, with full details, link references and follow up procedure required. 
+
== Project Status ==
Prior to work on task, begin log entry.  Your time of reading, logging and actually performing the task should be accounted for in your open log entry.  If you are managing a task assigned by email or phone - all time spent in reviewing, logging and performing work on task should be in your log time.
+
* BILLING
Logging to a task  - if you have a task in progress, please make sure you note in your last log generated on that task the percentage of the task you have complete.  This information would eliminate a lot of Gtalk conversations of "where are you at with this task".  The one unified aspect that we all share in logging to tasks is not giving a good description of the actual work that was already performed on a task, and the work left to be done.  Again, it might take you 5 or 10 more minutes to log this accurately - which is another 15 minutes of billable work  that adds up to PROFIT.
+
This should be set only by the second floor.
Phone call support - will be added automatically as a task and assigned to person phone call is going to be directed to.  This starts the process of logging and follow up on given support calls or client requests for work/help with their project.  Verify with person handing you support call that task has been created - if not - create one based on message past along before you pick up support call.  It is imperative that we all take into account what each of us have going on at any one given time.  We all tend to abuse Gtalk to get an instant answer from someone - Please be more mindful of other person  you are sending that instant message to and be considerate of their work space/time.
+
* BILLING REVIEW
 +
This should be set only by the second floor.
 +
* CLIENT APPROVED
 +
This should be set only by the second floor.
 +
* CLIENT REVIEW
 +
This should be set only by the second floor.
 +
* COMPLETE
 +
A task may only be set to this status if it has truly been fully completed. The relevant Project Supervisor is generally the one who will set this.
 +
* IN PROGRESS
 +
Any task that you have spent any time on should generally be set to this, if it isn't automatically already.
 +
* NEW / MODIFIED
 +
Set this status when a task has new items, or when a task is an ongoing task, or if the task is one that you cannot currently spend time on but that does not meet the requirements for ON HOLD (below).
 +
* ON HOLD
 +
Only when you are waiting for a team member, or a client, or another task to complete should a task be put on hold. If you are merely waiting for having time to work on this project, mark it as New / Modified instead.
 +
* NEEDS CLIENT REVIEW
 +
This should be set only by the second floor.
 +
* READY FOR REVIEW
 +
Any time you complete your given items in a task, set it to this when you are ready for it to be looked at by the relevant Project Supervisor or whomever assigned it to you.
 +
* ARCHIVED
 +
Only tasks that are of no more use, that are not billable, that are duplicate, mistaken, or hopelessly deprecated should be archived and even then the relevant Project Supervisor should be informed beforehand.
  
(Reminder:  Your time is accounted for when editing a task.  You can start a task direct from home page of GLMDB > Create new task > select client > select project)
+
== Projects vs Subprojects vs Tasks ==
 
+
* When to use them?
Authorizing Person of work being requested/performed/billed:
+
* A new project needs to be created when..
 
+
* A new subproject needs to be created when..
Name
+
* A new task needs to be created when..
Email Address
+
Phone Number
+
 
+
End of Week Task Management:
+
Friday's are a day of task check to prepare for Monday's staff meeting and new time schedules that need to be set for following week.
+

Latest revision as of 13:23, 16 May 2016

* Current Project Supervisors: Steve, Chuck, Charis

Housekeeping

  • Every Monday, before the status meeting, check whether any of your tasks are able to be taken off hold, or are better archived, or are duplicate, or finished, and change the status as per the guidelines below.
  • If a task is better to be reassigned to someone else and it's not for review, inform the relevant Project Supervisor and get permission to assign it to them instead.

Informing the Team

  • If for any reason you place a high-priority task on hold, inform the relevant Project Supervisor - this is best done through GLM Webmail.
  • If you place a task on hold, inform anyone that depends on that task's completion - this is best done through GLM Webmail.

Notation

  • Every separate item added to a task must be prefaced with [] (closed square-brackets) so that it can be filled in upon task completion. This can be done with one's initials, or an X, or a ✔, o, ✕, ✗ or whatever as long as it's clear.
  • Every time you are told something in person or make notes during a meeting please note them in the appropriate task. Do not rely on your memory. Do not rely on others' memory. Keep record of everything you are told or asked to do, and everything you indeed do.
  • In that same thought, if you have a question it is better to pose it in writing than it is to convey in person.
  • If the box is filled like so [!] or so [?] it means there's something that needs to be addressed. Don't expect the reviewer to notice this, make note of it above ("See the box I filled with a question mark, do I still need to complete this item?")
  • Every time a new item is added, do so at the top so it does not get lost.
  • Every time the project status is changed, note at the top when it was changed, who changed it, and add a brief explanation. What follows are some examples, it need not look exactly like this as long as the information is preserved:
4-21-2016 - Laury: Ready for review
11-2-2015 - LGvR: On Hold because we need to finish the DiscoverKalamazoo member DB first
1-1-2014 - Laury: Ian, could you please have a look at the marked items on this task?
  • The more clarity, the better! It can save a LOT of wasted time and effort if you use a few extra seconds/words to explain what part of the site you're referring to, and who you intend to have finish an item. Saying simply "This doesn't work" doesn't help.
  • The less clutter, the better! Try to avoid verbosity. Nobody has time to read your prose (unfortunately).
  • Keep your logs and notes professional, impartial and informative: No remarks on the intelligence of the creator of a plugin or a client are necessary - we likely already know and it is not the place.
  • Place notes in the Description, not in the Task Log - they will get lost down there and cannot be edited, and not everyone expects pertinent information to be down there.
  • Things of particular importance to the reviewer should be bolded using HTML tags. Use this sparingly.
  • It's friendly to wrap particularly lengthy links in anchor tags with target=_blank and named with where they go

Project Status

  • BILLING

This should be set only by the second floor.

  • BILLING REVIEW

This should be set only by the second floor.

  • CLIENT APPROVED

This should be set only by the second floor.

  • CLIENT REVIEW

This should be set only by the second floor.

  • COMPLETE

A task may only be set to this status if it has truly been fully completed. The relevant Project Supervisor is generally the one who will set this.

  • IN PROGRESS

Any task that you have spent any time on should generally be set to this, if it isn't automatically already.

  • NEW / MODIFIED

Set this status when a task has new items, or when a task is an ongoing task, or if the task is one that you cannot currently spend time on but that does not meet the requirements for ON HOLD (below).

  • ON HOLD

Only when you are waiting for a team member, or a client, or another task to complete should a task be put on hold. If you are merely waiting for having time to work on this project, mark it as New / Modified instead.

  • NEEDS CLIENT REVIEW

This should be set only by the second floor.

  • READY FOR REVIEW

Any time you complete your given items in a task, set it to this when you are ready for it to be looked at by the relevant Project Supervisor or whomever assigned it to you.

  • ARCHIVED

Only tasks that are of no more use, that are not billable, that are duplicate, mistaken, or hopelessly deprecated should be archived and even then the relevant Project Supervisor should be informed beforehand.

Projects vs Subprojects vs Tasks

  • When to use them?
  • A new project needs to be created when..
  • A new subproject needs to be created when..
  • A new task needs to be created when..