Project Delivery Rules of Engagement

This page describes the rule of engagement by which Vertic’s team delivers its work, including project implementations and support. These rules must be followed consistently and are designed to bring efficiency and productivity to the process.

Rule Number	Engagement Rule	Detailed Description	Impacted Groups
1	Slack or email is not to be used for discussing requirements/specifications unless the outcomes are captured in an associated Jira ticket.	The purpose of this rule is to ensure all relevant details for any given ticket are captured within the ticket itself rather than in multiple channels.	All of Vertic and its contractors.
2	Detailed Ticket Content Creation	When creating tickets, the following information is mandatory: `Salesforce Org` details to ensure the technical team knows in which environment to work `Quick Overview` of the purpose of the ticket to ensure the technical team understands the context in which they are developing. This could include the greater solution and how this tickets fits into this. `Specific Instructions` on what needs to be developed including the following: Impacted Object References (API Names) Impacted Field Names (API Names) Detailed Field Mapping (API Names) where this is relevant Screen Mockups (or marked up screenshots) if the user interface is to be changed `Evaluation Conditions`, for example: `If <<field_name>> is greater than 120 then set <<field_name>> to Activ`e `Execution Logic` which could be documented as pseudo code or as a diagram	Vertic’s Consulting Team in Australia
3	Support/Defect Ticket Content Creation	Where a ticket is describing a defect, also add the following details: Description of the error/defect Loom video showing the error in action URL to the record causing the error	Vertic’s Consulting Team in Australia
4	Feasible Ticket Structure	When a ticket spans across multiple functional requirements/specifications, create subtasks for each logical piece of development so it can be better managed by the technical team. This is particularly important when a ticket covers work across multiple days.	Vertic’s Consulting Team in Australia
5	Comments on Tickets	Once a ticket is being worked on, comments must be provided at the end of the working day to ensure the managing consultant has the required knowledge to update/manage the client.	Technical Team in Europe
6	Ticket Review	In order to improve ticket quality, the following process will be performed for each ticket: All tickets, once created, will be initial placed into a swim lane called `Technical Review` within the project board. The technical team will undertake a review of all tickets within this swim lane within 48 hours and feedback will be provided via comments on the ticket. Any feedback will be incorporated into the ticket and then it will be moved to `Selected for Development` Only tickets from `Selected for Development` can be put into the planner for the technical team to be worked on.	All of Vertic and its contractors.
7	Clearly articulate Priorities	It is critical to clearly let the technical team know about priorities and expected timelines; this can be done via email with specific references to Jira tickets in the planner. Any issues with the documented timelines must be communicated by the technical team to the consulting team.	All of Vertic and its contractors.
8	Fortnightly Plan	The planner should be structured across a fortnight rather than a single week; this will allow for better planning and for managing workload much better.	All of Vertic and its contractors.