Attention: Confluence is not suitable for the storage of highly confidential data. Please ensure that any data classified as Highly Protected is stored using a more secure platform.
If you have any questions, please refer to the University's data classification guide or contact ict.askcyber@sydney.edu.au
TAPSS-1780 Role Hierarchy Enhancement for Development
- Liz Enright
- laila.valterio
Summary |
|---|
Role hierarchy is a Salesforce feature that supports data visibility and reporting. The Development team need a role hierarchy that reflects their team structures to support KPI tracking, manager oversight, and campaign counting. |
Problem statement
Development Officers do not have the system functionality to support their team structures.
For DO managers, this means they cannot “see their teams work”, hindering constructive coaching conversations.
For DOs themselves, this means many teams are populating their opportunity data into a central excel that their manager uses to get team oversight.
Research insights
The role hierarchy used in Jarvis has a single role used for all Development Officers. No other Salesforce feature in use identifies what team a DO is in.
Reporting for teams can currently be achieved manually by filtering for the names of each DO in the team. When staff changes occur, these reports must be refiltered manually.
Solution hypothesis
Expanding the role hierarchy branches for the Development teams will support easier reporting.
The time saved in administering a more detailed role hierarchy will be more than the time spent manually maintaining the reports and dashboards for DOs.
Design options
| Team-based hierarchy | Manager-based hierarchy |
|---|---|---|
Overview | This option would add additional roles for each of the development teams falling under the Executive Directors. There will be 9 team based roles:
Refer to the diagram below this table. | This option would add additional roles for each of the development teams AND add additional layers to support the manager hierarchy within those teams.
Refer to the diagram below this table. |
Pros and Cons | Improves report filtering experience as the user can select ‘Faculty of Medicine & Health team’ and see results for the team Removes the manual maintenance of DO based reports as filters can be based on role instead of user name Mid-level managers will still need manual reporting as the role hierarchy won’t support them in filtering to their director reports | Improves report filtering experience as the user can select ‘Faculty of Medicine & Health team’ and see results for the team Provides more support for mid-level managers as they can filter reports to see roles under them easily Increased complexity and maintenance which will benefit less than 20% of DOs. Most will be supported by option 1 |
Team-based hierarchy diagram
Manager-based hierarchy diagram
Design considerations
Role hierarchy should be a dynamic feature that can be updated frequently. While the role hierarchy shouldn’t attempt to replicate an organisational hierarchy, it will be updated as reporting lines change. Whenever teams are updated/added/removed in TAP, the role hierarchy should be updated to reflect those changes as needed to support ongoing reporting.
Using role hierarchy for reporting will impact numbers whenever a team member is changed in the role hierarchy. An example would be if a DO moved from the Faculty of Medicine & Health team to the Arts & Culture team in the middle of the year. There is no way to report on that DOs results in FMH for the first half of the year and Arts & Culture in the second half of the year. The report will show their full totals in whatever team they are currently in under the role hierarchy.
Additional documentation
The Customer Success team has captured Voice of Customer feedback in their SharePoint site here. This customer feedback highlights the need for an enhanced set of roles for the Development team and will be used as a baseline for comparison after implementation.
The initial analysis for the proposed changes to the role hierarchy can be found here.
The FAQs document provided to all users after the change went live can be found here.
Decision
The Customer Success team has confirmed that we’ll use a Pilot approach and implement the Team-based Hierarchy. We’ll then check in 3-6 months after implementation to confirm whether additional enhancements would add business value or whether the Team-based hierarchy meets business needs.
Role Hierarchy Changes Required
Level | Role to be created | Reports to | Users to be assigned |
|---|---|---|---|
Level 1 | Executive Director, Health & Medical Sciences | Development Office Team | Peta Magee |
Level 2 | Director, Faculty of Medicine & Health | Executive Director, Health & Medical Sciences | Henry Shelford |
Level 3 | Faculty of Medicine & Health Team | Director, Faculty of Medicine & Health | Rachel Love, Shayan Quinlan, Debra Almeida, Kristy Trimboli, Stephanie Young, Coco Gouws, Sadie Moore, Karina Roberts |
Level 2 | Director, Multi-Disciplinary Initiatives | Executive Director, Health & Medical Sciences | N/A - this position is currently vacant |
Level 3 | Multi-Disciplinary Initiative Team | Director, Multi-Disciplinary Initiatives | Francys Arancibia, Lauren Swift, Harkeet Sandhu, Lewis Blomfield, Lachlan Cahill, Emily Hickman, Clare Hughes, Caziza Ahmed, Adrian Sanchez |
Level 2 | Campaign Partnerships Team | Executive Director, Health & Medical Sciences | Laura Albanese |
Level 1 | Director, Principal Gifts | Development Office Team | Flora Grant |
Level 2 | International Foundations Team | Director, Principal Gifts | Barnaby Caddy, Monika Wadolowski, Gwenllian Towart |
Level 2 | Development Writers Team | Director, Principal Gifts | Jemima Rohekar, Justin Noble, Jessie McGill |
Level 2 | Principal Gifts Team | Director, Principal Gifts | Ciara Timlin, Katie Booth |
Level 1 | Executive Director, Faculties | Development Office Team (Office & Writers) | Victoria Sloan |
Level 2 | Director, Arts & Culture | Executive Director, Faculties | Monique Harper-Richardson |
Level 3 | Arts & Culture Team | Director, Arts & Culture | Lilian Nicol-Ford, Matthew Young, Sarah Gho, Iona Chu, Rekha Patel, Guy Houghton, Isobella Brun, Rachel Proctor, Veronica Francken |
Level 2 | Director, STEM & Business | Executive Director, Faculties | Evan Morgan |
Level 3 | STEM & Business Team | Director, STEM & Business | Claudia Rowe, Rebecca Bland, Dylan Loru, Ybrahim Camero, Anna Parente, Georgina Coutts, Chloe Cai, Patricia Babalis, Mark Alcorn, Bianca Andreacchio, Lavinia Liclican |
Level 2 | Rural & Regional Team | Executive Director, Faculties | Charly Brown |
Level 2 | Deputy Director, Planned Giving | Executive Director, Health & Medical Sciences | Alexandra Miller |
Level 3 | Planned Giving Team | Deputy Director, Planned Giving | Isabella Andrews, Philippa Paull, Jennifer Bligh, Natasha Griffin, Vicky Mayer, Anne Marie Leo, Ashleigh Goodfellow |
Level 2 | Deputy Director, Indigenous Philanthropy | Executive Director, Faculties | Penelope Sinton |
Level 3 | Indigenous Philanthropy Team | Deputy Director, Indigenous Philanthropy | N/A - this position is currently vacant |
Timeline for Implementation
The Customer Success team is leading the communication for Role Hierarchy and their in progress plans can be found on their SharePoint site here. The communication plan will guide when Role Hierarchy will be implemented (likely mid/late-March) to ensure that users are aware and educated about the change.
The new roles were created and pushed into Jarvis Production without users assigned on 5/4/24 to allow time for change management to occur. Development users were assigned to their new roles in Production on 15/4/24. On the same day Debra Almeida identified that she could no longer access dashboards, this was due to dashboard folders being shared via Public Groups that were only referring to the old Development Office role. 16/4/24 a hot-fix to Production was made (SFPT-852) to change the Development Office Public Group to include the new Development Office Roles, this then resolved the reporting and dashboard visibility issues for all Development users.