How does the acceptance of input deliverables work?

Summary

Tasks in a project lead to deliverables, the so called 'output deliverables'. This output deliverable can be used as input for another task. The output deliverable is than the so called 'input deliverable' for that task. The people who are working on the second task can validate the input deliverable if it's complete and can be used by them. If so, they can 'Accept' the deliverable as input for the task and start working on the task. If not, they can 'Reject' the deliverable for the task. The people working on the first task will be notified and can adjust the deliverable. When they complete the deliverable, the process starts over again. The people working on the first task can also decide to overrule the rejection. In that case the person who rejected the input deliverable will  be notified and can decide to accept the deliverable (or of course reject again).

Configuration

In the project template, per task is defined which deliverable is the input deliverable. This is optional. For every input deliverable is indicated:

• Which deliverable is the input?
• Should the person working on this task be notified when the input deliverable is completed?
• Is input acceptance needed? No, Optional or Mandatory.

So for this Knowledge Base article, the configuration is:

• Task 1 'Create design brief' results in output deliverable 'Design briefing'.
• Task 2 'Create Master Design' has 'Design briefing' as input deliverable and leads to output deliverable 'Master Design'.

Process

The user creates the design brief, uploads it to the deliverable, completes the task and completes the deliverable.

The user working on the second task (for which this deliverable is the input) receives an email notification that the input deliverable is complete. This email notification has a fixed text & styling.

The user goes to the task 'Create Master Design' and notices the deliverable:

The user can decide to accept the input deliverable right away and start working on this task or to reject the input deliverable.

The user assigned to the first task (Create design briefing) get's an email notification that the input deliverable got rejected. This email notification has a fixed text & styling.

The deliverable status is set to 'In revision' (instead of Completed) and the lead task for this deliverable is re-opened as well.

The 'lead task' setting can be set in the Deliverable page, section 'Related tasks'. 

The user working on the first task can read the rejection reason in the task for the deliverable and can decide to either:

• Adjust the deliverable (upload a new file revision for example) or
• to Overrule the rejection.

When the user adjusts the deliverable and completes it again, the process starts over again. 

When the user overrules the rejection reason, (s)he can type in a reason for the overrule action.

The user who had rejected the input deliverable will be informed about the overrule action via email. This email notification has a fixed text & styling.

The process of rejecting an input deliverable can continue in multiple rounds. The history in these rounds are available by clicking the 'History' button in the Input deliverable section in the task.

When the user working on the second task accepts the input deliverable, the deliverable is marked as 'Accepted':