Q1 2024 TAP Planning 13/12/2023

Attendees

• Josh

• Laila

• Adriana

• Monica

• Polina

• Rommel

• Sankar

• Api

• John

• Alain

• Rizwan

• Liz

• Jess

• Demelza

Agenda

• Ways of Working Conversation

• Priorities for Q1

  • There will be a session early next year to work through the campaign objectives and ensure technology is supporting that pipeline

  • We also have an internal audit report that will come out early next year about what might need to change as well. This will ideally come out in Q1 and will dictate some short term and long term priorities. This is separate to the AAW donor journey consulting that has been in progress.

Opening comments

• Api's priorities

  • We've needed stability and foundation to get to the next level. Api wants us to move from foundational to transitional, the goal is transformational.

  • Api wants us to be conscious of overworking and underdelivering because we're spread too thin. We need to focus on foundational pieces of work that is going to set us up.

  • Api wants us to be proactive and put things on the table as early as possible so we can be prepared for the long term. We need to be comfortable with being multi-layered and have people across multiple priorities simultaneously instead of having people locked on one thing.

  • When we're delivering things as an MVP we need to be informing Api about what workarounds and additional work is required to accommodate until enhancement and optimisation can be conducted.

  • Api wants us to use 2024 to reexamine our why on everything. Laila also flagged we need to be conscious of when we need to say why not. Planning and exploring ideas may lead to us choosing not to pursue things.

• Demelza

  • Wants us to set milestones while acknowledging what resources need to be available at the right time to get the milestones passed.

• Jess

  • We know that there are milestones we need to meet eg campaign launch. We need to get things to completion but factor in optimisation down the track.

Q4 2023 Recap

• The exec update will eventually move to fortnightly then possibly monthly updates next year.

• Josh would eventually like to get back to an on demand release model. If there is something critical or urgent we will aim push it through with CIO approval. This requires high confidence that the fix won't break anything else.

• Testing

  • We should be revisiting what critical means frequently. Critical should be something that brings the business to an absolute stand still. This should be reassessed with every release as we increase functionality, new features might require testing automation. We need to reconsider the test cases throughout the story cycle to see what might need to be updated or escalated as critical. This needs to be built in throughout the development of new functionality.

  • Testing needs to focus on the most important business critical features that need to be assessed with every release. These should be automated. At Monash Josh had a slow down on development to prioritise pulling together an automated testing pack that accelerated development afterwards.

  • We will need hot fix pathways for fixing any bugs that make it through to production.

• Api says having the priorities is good and the challenge for the business is acknowledging what's in the backlog and what we're waiting on and the current pain points are with living with the backlog not being worked on.

Ways of Working - Key Definitions

• Incident - something is broken. An unplanned interruption to a service or reduction in the quality of a service

  • We need to discuss escalation etiquette. If someone is trying to escalate an incident because of external pressures that's worth sharing

  • Polina says the main challenge is not knowing how things are supposed to work in the first place. EG its not super clear to see whether something is an incident. It can be something unexpected but they don't know whether the thing is behaving as expected. A good example is we rarely have visibility of a flow so troubleshooting whether something is working correctly or incorrectly is difficult.

    • Monica says the validation is an important part of this. Gave a scenario where Monica was informed by someone that something wasn't working as expected. Monica doesn't know if it's not working as expected or whether it was never designed to work for that scenario in the first place. She advocates building in the validation and exploration of whether something is an incident.

    • Part of this is having strong regression testing to catch whether something is no longer working as expected. Regression testing should identify what is no longer working.

  • Requirements will come in from different people and ensuring that everyone is aligned on those needs to be more standardised. Some development has been designed with limited viewpoints which leaves some people interpreting how something should work differently. Josh proposes that we communicate with people internally to check how a button should be used internally and assume that it is working as expected. Cross-team validation about how people think things should behave as a first step before flagging something as an incident.

  • Finding a source of truth for how things were designed can be challenging. During the initial go live some tickets were quite light so Jira tickets can be difficult to extract the right information from.

  • Polina flagged that incident management can be frustrating because she'll log a jira ticket, then be told to add it in servicenow, then get told later that for XYZ reason it should have actually been a jira ticket.

  • Alain flagged that people have to check jira, confluence, and Jarvis knowledge all can be a 'source of truth' but that's a lot of different sources to check. Monica flagged that some of the broader TAP users will come to her because they also don't know how to understand whether something is a bug or not, they don't have access to most of this knowledge.

  • Demelza feels that having the feature owner on a ticket should play a key role as the first port of call when people have a question.

  • Alain wants a consolidated base of knowledge that helps define consistency of features. Part of this is getting everyone to agree on what and how something should be used in Jarvis.

  • Josh used the example of having an issue with Concur. People will reach out to someone who uses it more to ask questions about it first. The knowledge that we know we can keep customising Jarvis gets people to keep adding incidents. We have difficulty because we know there are some things that are out of our control such as AQ managed package.

  • As part of our validation of whether something is an incident we need to consider a layer of checking whether something is an AQ feature, a SF feature, or something USYD built.

  • We also need to have strategic reflections every couple of years about whether our products are meeting our needs and whether the limitations of the product are too much to continue working with

  • We should consider documenting the limitations of the products we're using. These can be helpful to determine how we should be building in these products.

  • If we had a weekly release would we be able to accommodate the change management? If we're doing large scale change then it's unlikely that we would be doing significant change management regularly. Frequency of change can lower the threshold and tolerance for issues. EG if the change is infrequent then not having something go in can be more challenging to live with. A weekly release cycle doesn't need to be huge changes every week, they can just be minor changes to picklist values etc. Monica agreed that if something is only going to be broken for a week it's easier to live with, but if it can be fixed in a week or two it's more palatable to live with.

  • How do we start driving a cultural change across TAP that SF will change and evolve through frequent releases. This can help ease some of the day to day discomfort around issues that exist in Jarvis. Things will go wrong and break and they will be fixed and evolve in the future.

    • Demelza raised that some teams don't have a baseline level of understanding of core business and activities which can be a barrier to the dynamism approach.

    • Polina thinks the business would be happier to have more frequent releases, what they're lacking is the trust that something will be fixed if its 'broken' in a release.

    • Josh wants TAP to explore how to drive that wider cultural change. Api flagged we need to build trust in ICT that we can operate on a faster release cycle, that trust isn't there yet. Josh asked what ICT can do to support that trust building. Adriana and John want to explore some lower risk changes and how those can be pushed through quicker.

      • Demelza wants consistency and clarity of processes is important. Setting standards around what is an incident etc helps streamline the way we communicate. Having a lack of continuity about how we do those things like flagging an incident. Api doesn't think the expectations around these are being managed, she doesn't understand why some things take so much longer in ICT than they did when they were managed by TAP. Demelza doesn't want to see a different process for raising things week by week. Api wants an ICT partnership where ICT know TAP's business. TAP has to reeducate ICT on a continuous cycle. Testing is always falling on TAP and Api doesn't want that to happen. Having TAP do full regression testing on things is painful. If ICT is trimming and streamlining its regression testing, does it put the burden of flagging incidents on TAP as opposed to ICT finding it in regression testing.

      • Polina also wants to see more accountability and responsibility. She feels that when TAP flags something to investigate often ICT will try and bring it back to TAP to do work on and Polina feels like its not her responsibility.

        • Josh flagged that there's a high volume of issues being raised and they can be flagged with ICT at different levels of investigation and validation. Api used Concur as an example where if she's having an issue with Concur and has an issue she'll just log an issue and expect someone else to investigate. Josh flagged that the product team we're working in should be aiming for a DevOps model where it is both building new features and monitoring and supporting incidents. Having a separate platform team that doesn't understand the product teams work is not going to be able to support the incident's that are reported as effectively.

        • Monica finds it challenging to track incidents that are flagged. Currently her team will log tickets and Monica doesn't have any visibility without her team manually tracking them in a separate excel.

        • Discussed who should be monitoring incidents. Ideally the product owner is monitoring the incidents that are coming in and it can be discussed in the stand up.

        • Demelza wants shared definitions, criteria, accountability, and responsibility for all the processes between ICT and TAP. For Demelza's teams she wants a process that is signed off and agreed upon. She also wants the absolute critical processes documented with the SLAs.

        • We need to get everyone to agree on the roles and definitions of the different feature owners.

        • We need a consolidated dashboard for what ServiceNow tickets are open for TAP.

Q1 2024 Priorities

•  Need to add a priority for 'defining the work that needs to happen from the AAW and campaign plan results'

• The pieces marked in bold are non-negotiable.

• Data fix following AQ consultation

  • AQ has recommended some data for soft credits and pledge soft credits.

• AQ Business recommendations (best practices)

  • AQ have made a number of recommendations that need to be prioritised and sized up. The focus is just on the matching gifts functionality. The matching gift functionality is about supporting workplace giving. This will involve changing our process and some functionality.

  • Demelza wants these tickets to be tagged as happening because of AQ recommendations or donor review or campaign planning

• Reimaging flows

  • There have been a lot of flows developed. We've done some analysis and this work will be to reduce some of these.

  • This is a tech debt ticket that needs to be sized and analysed

• Email consolidation

  • Prerequisite for preference centre work

  • This is the analysis, impact, and getting TAP to agree on the approach

• Donor relations enhancement uplift

  • The Donor Relations team have done pre-work for their strategy and how it operates in Jarvis. They're doing a lot of manual work outside of Jarvis. They need to have their processes incorporated into Jarvis. This will be analysis, sizing, and technical discovery.

• Pledge reminders

  • This is in the backlog. Laila recommended that not be considered in Q1. Some recommendations might arise in the donor journey

• Opportunity Optimisation project

  • This is a large initiative that directly leads into campaign 2.0 as a critical piece of work that's been greenlit by SLG. This is a 12-18 month project, potentially longer pending resources. There are tickets in the backlog that will need to occur in Q1.

  • In Q1 we'll do role hierarchy just for the Development Office team. Additional roles will be added for this group

• Activity reports vs Activity

  • This is a non-negotiable. It is the analysis work for work that would need to occur in Q2

• Security for profiles and roles

  • Everyone understood

• O2G project

  • Api is putting this on hold until the AAW review comes out.

  • One small portion of this is the research grant that Monica says is mandatory

• Chart of Account project

  • That's just data mapping for Monica and data changing is DRS

  • This isn't an ICT project and doesn't have any ICT involvement

• Pledge payments

  • There will be some field changes

• Multiple GIN analysis

  • Not a priority for Q1. Needs a lot of analysis work.

• Defining Non-Households

  • We don't have clear processes on creating non-households work and the picklists don't make a huge amount of business sense.

  • Monica flagged that parent account and naming conventions should be considered.

• SITS Integration

  • We're pulling the student API part is being moved under the WB exit priority

• iModules product fix

  • Everyone agrees that iMods isn't working and the vendor needs to do fixes.

  • Josh to do vendor negotiation

• Planned Giving

  • This is scrapped for Q1 as the expectation is PG won't have work requested.

• Alternate Channels

  • We've done UX changes and now we need to work on the archiving component

• Preference Centre tickets

  • Have been planned out as part of the project

  • Api asked that any CRM changes be discussed with the TAP business

• Overall

  • Api wants us to prioritise the core processes and who the feature owner is as it will help identify who is who in the RACI

• Rankings

  • Laila's rankings

    • Laila's 1 and 2 were merged as part of earlier discussions

  • Jess' rankings

    • Jess had an item called campaign readiness that wasn't on the candidate list. Some of this activity won't exist in the backlog/pipeline yet and we need to hold space for that to exist. This might be scoping out

    • Jess wants to hold space for localised BAU enhancements. Jess said there wasn't enough space for little picklist updates and email to case and we need space for that.

    • This led to us adding a priority to the candidate list called 'Campaign readiness activity'

  • Alain's rankings

    • We pulled COA out because it isn't an ICT related activity

    • Pledge payments, this is different to Pledge reminders

  • Monica's rankings

    • COA was pulled out and replaced with the AQ upgrade

Next steps

• ICT to go away and come back with a consolidated list of the priorities

• Holiday homework for the group is to consider reading Patrick Lencioni's The Five Dysfunctions of a Team