Difference between revisions of "My activities"

From Catglobe Wiki
Jump to: navigation, search
(jrfconvert import)
 
 
Line 1: Line 1:
[[Category:HelpBooks]]
+
[[Category:Tasks]]
 

 

  

Latest revision as of 09:27, 11 May 2011



My activities

The My activities page holds information on all the tasks you need to be aware of and take action on. Tasks in this sense is not only regular tasks, but also includes lists of coding jobs and workflows that has been assigned to you as well as shifts that you have been signed up for.

The My activities page can be reached through Tools -> Personal -> My activities

The following document primarily is focused on the use of My activities for Tasks. If you want to learn more about the other pages please click on any of the below links:

You will in the left side of the My activities screen see a number of main menus; including Operational Responsible, Supervisory role, and Observer, which all relate to the tasks of Catglobe.

MyActivities56-1

Whenever immediate attention needs to be directed towards any item in the menu it will turn read. This normally happens when task deadlines are overdue. For unassigned tasks (tasks where the responsible is not yet stated, it will turn read 3 days before latest acceptance date.

Operational role means that you are responsible or in a group which is responsible for the tasks listed here. Supervisory role means that you are the one who must approve that the task has been done satisfactorily when the responsible sets it to completed. Observer means that you have the right to see what is happening to the tasks in the list, but that you are not expected to take any actions. By clicking on any of these main headers you will get listed all of the tasks that fulfill these criteria independent of what state the task is in.

If you want to review only tasks with a certain status you can choose any of the sub menu elements under each of the three role types. The sub menus differ slightly due to some minor differences in the best way that each role type should be presented for tasks in different statuses. Below is a completed list of the different statuses a task can have and what the next step of each status potentially can be.

Once you click on a main menu item or sub menu item all the tasks that fulfill the menu item criteria will appear on the list on the right side of the screen together with a top menu. The top menu offers a number of actions that are available for the tasks in the list below. Depending on what menu item you choose the buttons available will differ. Once you highlight a task then any button that offers an action, which is not allowed for the chosen task, will be disabled. Before we introduce each of these button it is important that we understand the different statuses that tasks can have. If you look at the task lists you will see that a column with status is available.

Outcomes for task status: Need acceptance (being an operational responsible)

When a task has the status “Need acceptance”, the creator of the task is expecting the responsible of the task to go in and click the accept button. Normal procedure is then that all responsible users go through their My activities lists to check any tasks they have and accept those they agree that they indeed will or should do. If a user does not believe that the responsibility of a task should be his he can also choose to reject the task in which case the task will have its status changed to “Rejected”. If the user believes that the Task instead should be reassigned to a different user he can also do this by clicking the “Reassign” button. This will open a wizard that will lead the user through process of reassigning the task. We will explain this process further down in this document.

Outcomes for task status: Need acceptance (being in the supervisory role)

When you are specified as the supervisor of a task it is your responsibility to make sure that the task is properly done. Often the supervisor will be the person who created the task and will thus seldom want to do any action on a task needing acceptance. There may although be cases where the supervisor is informed of a newly assigned task created by others and has a better idea of whom should solve that task than the creator, and therefore wants to reassign the task. Other possible actions that supervisors are allowed to perform are cancelling the task and setting the task to completed. Both actions presume that the supervisor has a deeper knowledge of the task and therefore believes that the task needs not be accepted and completed by the responsible.

Outcomes for task status: Rejected (being an operational responsible)

When the responsible rejects a task he most likely will wait for the supervisor to choose what then to do with the task. If the responsible realizes that he rejected the task by mistake he can choose to reassign it. If he still wants to do it himself then he should reassign the task to himself and the task will change status to need acceptance. As will be shown later down in this document reassigning tasks will always convert any task, independent of prior status to the new status; “needs acceptance”.

Outcomes for task status: Rejected (being in the supervisory role)

When the responsible has rejected a task it is now the responsibility of the supervisor to choose what should happen with the task. There are 3 possible actions to take; he can choose to reject the responsible user’s rejection, in which case the task will be returned to the responsible with the supervisors explanation of why the rejection is not accepted; he can also choose to cancel the task in case he agrees with the responsible users’ reasoning for cancelling the task; finally he can choose to set the task to completed, if the responsible user rejected the task due to it already having been done.

Outcomes for task status: In progress (being an operational responsible)

When a user has a task in progress it normally means that he has accepted to do it and is working on having it done. Typically the user will at some point of time set the task to completed after which the supervisor will review the task and do the final approval. There may although also be other situations that occur. The responsible user may find, that he is not in reality able to finish the task and therefore reassigns it to a different user. In this case the other user will receive the task in his My activities list and the task will change its status to “Need acceptance”.

Outcomes for task status: In progress (being in the supervisory role)

When tasks are in progress the supervisor generally just waits for it to be done. If he for some reason finds that he will do it himself he can although also set the task to completed from the “tasks in progress” lists. If he finds that the task needs to be reassigned (maybe the responsible is not doing a good job) then he can also do this while the task is “In progress”. Tasks which are reassigned will need to be accepted by the new responsible.

Outcomes for task status: Awaiting approval (being an operational responsible)

When a responsible has set a task to completed it will be moved to the list showing tasks that are awaiting approval by a supervisor. If the responsible user suddenly realizes that the task is in fact not completed yet, then he can use the button “reassign” to give it to someone else who should complete the task or reassign it to himself, so that he can try one more time.

Outcomes for task status: Awaiting approval (being in the supervisory role)

The main task of any supervisor is to ensure that tasks are done in time and as expected. The supervisor should therefore try as quickly as possible to inspect all tasks that are awaiting approval. If the supervisor finds that that task has been solved satisfactorily he can approve the task. If the supervisor disapproves, the task will be returned to the responsible user with the status “In progress”. The user may also realize that the responsible does not have the skills to solve the task and reassign it completely. In this case the task will be need to be accepted by the new responsible user.

Outcomes for task status: Approved (being an operational responsible)

Generally, there is not much to do when a task is finally approved. A responsible user who found that he may have set the task completed even though this was not true, can reactivate this by reassigning it to himself or someone else.

Outcomes for task status: Approved (being in the supervisory role)

Generally, there is not much to do when a task is finally approved. If a supervisor finds that he may have been a little quick in approving the task he can reactivate this by reassigning it to the responsible user or someone else.

Outcomes for task status: Cancelled (being an operational responsible)

Generally, there is not much to do when a task is finally approved. A responsible user who found that he may have set the task completed even though this was not true, can reactivate this by reassigning it to himself or someone else.

Outcomes for task status: Cancelled (being in the supervisory role)

Generally, there is not much to do when a task is finally approved. If a supervisor finds that he may have been a little quick in approving the task he can reactivate this by reassigning it to the responsible user or someone else.

Actions on tasks: Accept

Tasks can be accepted by the responsible when they are in the status “Need acceptance”. Once they are accepted they will be changed to the status “In progress”. The responsible should always accept tasks as quickly as possible to inform the supervisor that the task is understood and will be taken care of.

Actions on tasks: Reject

Tasks can be rejected by the responsible when they are in the status “Need acceptance”. Once they are rejected they will be changed to the status “Rejected”. A responsible who does not feel that a task makes sense or perhaps that the task is already done, should as soon as possible reject the tasks so the supervisor will know that a reconsideration of the task needs to be done. When a task is rejected the rejecting responsible will need to specify a reason for this. Please read more below in the chapter on “Action Wizard Step: Stating a reason”.

Actions on tasks: Reject Rejection

A rejection can be rejected by the supervisor when it has the status “Rejected”. Once a rejected task is rejected by the supervisor it will change status back to “Need acceptance”. When a rejected task is rejected by the supervisor the rejecting supervisor will need to specify a reason for this. Please read more below in the chapter on “Action Wizard Step: Stating a reason”.

Actions on tasks: Set completed

A task can be set to completed by a both supervisors and responsible when it has the status “In progress”. Once it is completed, and a supervisor is specified for the task, it will change status to “Needs approval”. If the responsible and supervisor are the same person, or if the supervisor is not specified, then the task will change status to “Approved”. When a task is set to complete, the responsible will need to specify how the completion was carried out. Please read more below in the chapter on “Action Wizard Step: Stating a reason”.

Actions on tasks: Approve

A task can be set to approved by the supervisor of a task when it has the status “Needs approval”. Once it is approved it will change status to “Approved”. This is the step where the supervisor checks up on the fact that the task was carried out as expected. If not, the user can choose to “disapprove” the task instead. Notice that it is possible to highlight multiple tasks at the same time and click approve!

Actions on tasks: Disapprove

A task can be set to disapproved by the supervisor of a task when it has the status “Needs approval”. Once it is disapproved it will change status to “Needs acceptance”. The responsible will then once again have to accept or not accept the task by reading the supervisors additional reasons in the tasks journal and hopefully thereafter understand the task better. When a task is disapproved, the supervisor will need to specify why the completion is disapproved. Please read more below in the chapter on “Action Wizard Step: Stating a reason”.

Actions on tasks: Reassign

A task can be reassigned in all states by both the responsible and the supervisor. When a task is reassigned it receives a new responsible. The status of a task that is reassigned will always be “Needs acceptance”, since the new responsible may not agree that he should do this task. When a task is reassigned, the person reassigning will need to specify why this is done. Please read more below in the chapter on “Action Wizard Step: Stating a reason”.

Actions on tasks: Cancel

A supervisor may at any point of time in the process cancel a task if it turns out to be unsuitable to be carried out to completion (e.g. that it is already done). When a task is cancelled it will change status to “Cancelled”. A cancelled task can only be un-cancelled by using the “reassign” button. When a task is cancelled, the person cancelling will need to specify why this is done. Please read more below in the chapter on “Action Wizard Step: Stating a reason”.

Actions on tasks: Merge

If two tasks are the same then we may choose to merge these two tasks into one. This will in reality create a “parent” tasks and a “shadow” task. The shadow task will have the same status as the parent task and when then the parent task is completed so is the shadow task. Shadow tasks can be un-merged by opening the task and from the core information page selecting the shadow task and clicking the “un-merge” button. To read more about how the actual merge process proceeds, please click here.

Action Wizard Step: Stating a reason

Certain actions taken on a task will require the person taking the action to specify a reason. This is done through a small dialogue which will pop up when such a reason is needed. The dialogue may look something like below:

Task 3

The above asks you to state the reason for the reassignment, but it may as well have asked you the reason for a rejection, cancellation or how a task was completed. Whenever the system believes that it will be of value to add to the journal the reason a task changed status you will be asked to fill in a dialogue similar to above.

Action Wizard Step: Registering time

If a task is stated as being active for time registration you will in the wizard also be asked if you want to add any time registration on it, when taking the actions “Set complete” and “Reject” on it.

Task 4

The dialogue will look like above. You can register on more than one date simply by filling in one row and an additional row will appear. When you are happy with the hours set up, you will click the finish button to process both the wizard information as well as the status change that activated the wizard. A validation of your inserted hours will be done. You will e.g. not be allowed to register more than 24 hours in one day, you cannot register hours on time registration periods which you have already submitted for or for which you have no registered period. Whichever problem you incur that you do not find reasonable, please contact the time registration supervisor to fix the problem.