Collaboration Norms
Connect Care build is a team activity. There is no place for solo builders to work in isolation from others, or from the broader Builder and Analyst community.
Working with IT Analysts
Builders should heed the following precepts when working with their Analyst dyad:
Connect First; Reconnect Frequently
Builders must identify and approach or otherwise be linked with an appropriate IT Analyst for all build activities. Accordingly, a first task is always to name and confirm participants in a build project.
Builders cannot be Content Management "owners", a role reserved for Analysts. This highlights the importance of identifying an Analyst owner as soon as possible and confirming the availability of that Analyst for the collaborative work to be done.
Err on the side of more communication
Ensure ample opportunity (direct meetings and indirect messaging) for the communication that will be required to keep all collaborators well informed and engaged with the build project.
If in doubt, communicate more widely and deeply. It is not enough to rely on notes in JIRA tickets.
Track and Document Thoroughly
Ensure that all build work corresponds to a JIRA ticket and, ideally, one or more ServiceNow tickets referenced in the JIRA ticket.
Adopt Build Logs to keep a diary of important build decisions and actions as they occur. This can be attached (uploaded) to relevant JIRA design tickets, with high-level details added to the JIRA ticket content.
An Epic Content Management ticket is rarely sufficient build documentation for a significant project. All Content Management tickets must reference a JIRA ticket, which should in turn reference ServiceNow ticket(s) and build log(s).
Build logs should be visible to all collaborators during, not just after build.
Assure Appropriate Approvals
Analyst approval for build work is necessary but not sufficient. Builders must ensure that presentations or other informational interventions get to appropriate oversight groups (e.g., Area Councils) and that project build is reviewed by all relevant oversight and stakeholder groups.
Reviews and approvals should be listed within appropriate JIRA tickets.
Depending upon build type and complexity, different levels of change management and communications/training review may be required.
Test and Re-Test
Builder responsibilities do not end with build. In addition to facilitating review, approval, change management, communication and training processes, Builders should ensure that appropriate testing has occurred in pre-production environments (e.g., TST) and that the functions continue to work as intended in production (e.g., SUP then PRD).