Experience

Opinion & Views expressed here are from my personal experience working in these firms. Purely subjective; intent is to collate personal experiences for posterity for my job interviews. 

WP

Projects 

DMOS - data management OS, DCMP - data control monitoring platform. 

ALEX business glossary business flows data lineage, JUNO enterprise risk platform, Snow for system data inc and problem mgt. 

Application inventory - ATLAS (what data app processes, who is the business owner)

- Account Name (DDEP)

- ATM Enrichment, DDEP - Data Driven Experience Platform

- EIG FusionGPP Tactical Solution, EIG only

- BEDS Transaction Threshold Reporting (EIG) - Informatica

- BDP018 Performance Fixes and Bug Fixes

- Quantexa - DDEP V1.0

- SELC is the SDLC lifecycle

SMR, TTR, FACE, NR case management tool, Quantexa detection enginer 16 scenarios including shell companies

1. Demand management

Demand management is via Jira Request driven through Confluence Page to capture, triage and assign requests to relevant teams. These are on top of the product backlog. 

2. Requirements elicitiation

Requests may be for new feature/ product, BAU bug, or request for a fix / CR.

During triage stage itself there are some high level estimates (T shirt sizes) made on the piece of work. The Fincrime leadership in other forums is already aware of the incoming requests even before they appear as a request thru frontdoor. So, the T shirt sizing would already have been done, but it now awaits a formal sizing in terms of man days and $ figures. 

Plan for requirements workshop, etc. as appropriate.

3. Cost Estimation

Technology estimation (TEP) is driven thru a predefined excel template. SO and Tech Lead liaise to fill the template - context, technology, solution diagram, assumptions and dependencies, resource count, allocation %age for each resource (SO, SM, TL, Solution Lead and Management), BAU Run team split between L2 and L3, etc.

These estimations are run past SDM and then presented to the estimation board. 

Timelines are drawn, negotiated with program and delivery plan shared. There is also a resource based estimation shared with business since when contingencies are met, they might lead to additional funding requirements. 

All estimations, resource based estimations, etc. are uploaded to the relevant epic. 

Once they are shared with the ITPM and Business, burn is monitored and tracked every month. 

4. Stakeholder Engagement

> SIT/SVP Teams

> Solution Design Team

> EIM Governance Teams

> Security Team

> OGate / Release Engg Team

> L2/L3 support teams

> Downstream / upstream application teams

> UAT Manager / Teams

> Change Manager

> Application Service Operation Managers (EIG/DDEP)

> Program Team (ITPM, Program Manager, SM for Business Teams)

> Dependency team

> Management reporting, Risk tracking, delivery statistics and quality

> WP manager overseeing work

> Vendor Delivery Manager and Engagement Manager

Technology vs Business Teams

Project delivery is done by technology team in liaison with buiness teams. Business teams are led by an ITPM (IT Project Manager) who engages with technology delivery team to ensure timely delivery. 

5. Team Formation

When finalizing the team structure (it is required sometimes when the required skills don't entirely match), other vendors may be taken in in consultation with WP management.

6. PI Planning

> Plan PI along with business stakeholders and team ahead of PI plan.

> Ensure there is sufficient work for all my teams and team members for the duration of PI

> Create / update epics and user stories.

> On the day of PI liaise with other teams, dependent teams, RTE and others - update boards accordingly. Ensure dependencies are raised on other team's boards.

> Discuss and raise ROAM risks on RAID board.

> Present the scope and talk thru the risks / mitigation plans. 

> Talk thru scope of PI in the DP internal meetings. Present plan and risks. 

> Commit to PI scope and plan. 

7. Project Delivery

> Ensure the below are there:

- Requirements clearly elicited.

- Enterprise design is approved by all stakeholders - there are no two thoughts on design appropriateness and business strategy. 

- Design documents are signed and available (For E2E solution)

- FSD is available.

> Start project delivery. 

> Ensure design team is onboarded, solutioninzed and discussed with team.

> Any exception scenarios are discussed with Design lead, and design is approved by both tech design team and business SME. 

> Any additional enterprise architecture approvals are sought and obtained (based on the current tech solution in scope).

> Tech solution of product has to align with the larger intent of product assimilation within the enterprise landscape.

> Ensure load assurance is adhered to. 

> Finalize design with help from design team, get it signed off.

> Start coding, UT, ST.

> Deploy solution to SIT/SVP, support SIT/SVP.

> Raise change for deployment. 

> Complete deployment preparedness activities

> Complete all approvals including BAO, EIM governance / data governance approvals.

> Raise all read access requests for carring out PIV in production. 

> On D day, deploy solution, carry out Tech PIV, support BPIV.

> Monitor jobs for scheduled duration, gather statistics.

> Prepare warranty doc. 

> After 4 weeks (for new jobs), run the observations past L2/L3 SOM, get their sign off on warranty. 

> Handover solution to L2/L3 to support BAU activities.

In case there is no data available to carry out SIT/SVP, or the available data is invalid or inadequate and there is a need for production data:

> Raise BAO request for copying masked production data to SIT/SVP.

> Get EIM governance approvals of masked data.

> Before that, liaise with TEMS team to identify the PI/PII fields, ensuring fields that can be exposed and those that cannot be exposed. BAO, EIM will have a say on this matter.

> Give TEMS SQL queries to get / source production data to lower environments.

> Once all approvals are in place, TEMS will ask L2/L3 to start running the queries and copy data to specific locations.

> Once data is copied to specific location, TEMS will run a masking algorithm (intelligent masking), which will equally mask data across tables in scope so the join conditions are able to work even when masked.

> Once data is masked, TEMS asks L2/L3 to copy data to desired location. 

> Dev and SIT/SVP teams can now start using the masked data.

8. Prod deployment preparation

> Release planning

- Liaise with business to finalise the release date. This is also important because if certain data has to start flowing from an upstream application, then our product release has to be timed to able to consume this data and make possible the relevant transformations required for downstream to feed upon.

- Get the release dates registered in a release register.

- Liaise with release manager for the release.

- Raise release epics, and follow up. This allows release visibility to other teams as well as to the management.

> Exception planning - eohy, eofy as appropriate, fill the templates and seek exemptions for the release as appropriate.

> Release visibility to management - release register

> Complete all release documentation. Get SIP (Impl plan) reviewed by the release manager.

> BAO approvals as required.

> Liaise with OGate engineer to get sign off on OGate (Release preparedness checklist which goes thru all the documentation - requirements, design, design sign off, security clearance, BAO approvals, EIM approvals, enterprise design sign offs etc.).

> Read permissions to production environment to carry out validations post deployment.

> L2/L3 walkthru of the release. (Including walkthru of the implementation plan).

> SOM support for weekend deployment.

9. Deployment and warranty support

> Start deployment

- Hold any jobs that may interfere with deployment (Instructions should be documented in the SIP)

- Ensure commit id is the same as in SIP. 

- Liaise with L3 to start deploying package. (For EIG, the code should have already been deployed to pre productions, since ddep doesn't have a pre prod, it's different).

- For any issues during deployment, if changes are to be made, raise INC against the change and follow through with support team accordingly.

- Once deployment is complete, carry out PIV

- Support BPIV

- Release jobs as appropriate.

- Monitor jobs during warranty

- Capture statistics and fill warranty checklist.

- Once warranty is complete set up meeting with L2/L3 teams SOMs and walk them thru the observations.

- Formally handover the solution to support team for them to continue with BAU. 

- For any defects during warranty, fix them in lower environment following the SELC process and redeploy code as appropriate after SIT regression, SVP as approrpriate.

10. Environment Management

Environment Strategy & Planning

• Understand requirements 
• S/W Test requirements (what all testing will be done, and is our environment capable of handling them all?)
• Types of Environments (Dev, SIT, SVP, UAT, and Calibration).
• Specific configurations, etc. (SVP should be able to handle BAU volumes) – batch ingestions, schedules, orchestration, file handling, 2-hour window polling, file handling, Error handling, custom script runs, etc.)
• Timelines and milestones.
• Governance approvals (Data Owner approvals, Platform approval / SOM/SDM approvals, Platform governance approvals).
• Data refresh requirements (Which environment needs production data, masked data, intelligent masking, which ones fields to mask – based on PI and PII data).
• Where will data be sourced – old archived data, new prod data masked/unmasked, etc. 
• Security approvals (Secure by Design approval from Security Lead).
• Deployment Plans, dates, etc based on timelines + milestones. 
• Ensure deployment tickets are created / CRQs. 
• Line up test teams to carry out testing, PIV – technical validations. 
• Risks, issues, and mitigation plans. 

Team Liaising 

• SIT, SVP, UAT, Security Testing teams for requirements for environment set up.
• Application teams / PMO function
• L3 Support team for infra deployment
• L3 SDM / Service Lead 
• Governance teams
• Security team
• Program Governance/ RTE.
• Change Manager
• Release Manager
• L2 Team for incident management and troubleshooting.
• SME support for incidents.
• Test Data management team for environment refresh. (Any approvals thereof).
• Coordination with other Dev teams for resource contention for Functional Testing.  

Risks, Issues, Mitigation…

• Non-production environments are of lower priority for the infra support teams. 
• A constant follow up is required, keeping in their delivery lead and service delivery manager in loop keeping abreast of the agreed timelines. 
• I ensured their participation in PI Planning and agreeing to the PI Goals + Timelines with Program.
• Agree on SLAs between the teams to ensure appropriate level of support.
• Availability: most of them are from offshore – ensure constant interaction with onshore counterpart and follow up with offshore. Ensure onshore to offshore and vice versa handover.  
• Ensure they can give an update end of each day / participate in daily stand ups to get a hang of their progress / delivery. 
• Support handover challenges – one resource did not properly hand over. 
• Missed deployment slots – again close coordination with change and release team to ensure the changes are deployed. 
• Missed deployment slot because they had not got the deviation approval during a maintenance window. 
• Changes are properly understood by the infra support team. 
• On one instance they had given access to one dataset only – Worldcheck, and BVD but not for other datasets. 
• Environment contention.
• Both Dev and SIT environments are used by many teams so there is always a resource contention during execution. We set up LoB level meetings with all the concerned teams and got a buy in for 1. Critical Data sets that should not be touched. 2. Particular execution windows for runs/ tests. 
• Prod data sitting in non-production systems (we had approvals). 

Steps to address environment contention

• There were multiple test teams using the environment. In our case, Dev was also being used by downstream Synapse to carry out their integration tests. 
• Multiple test teams were carrying out tests on the same datasets / tables and thus overwriting, corrupting data. 
• In some instances, they even deleted the tables and data backups. 

Prioritize and schedule access:

Identified those teams that had critical testing and business go live dates nearing / goals to meet. 

Jira based ticketing system to book test environment slots.

• Strict windows, and number of people who needed access to carry out tests.
• Book slots, triage and send out group emails before and after testing as part of vacating the environments.
• Also, strict communication on the do’s and don’ts of using the environments during weekends and on public holidays.  

Shift left:

• Encouraged test teams to incorporate testing earlier even while doing the dev. We made them co participants in design and solution related discussions so they could plan early and avoid late testing.

Environment usage monitoring:

We didn’t get to implement this. 

Challenges in WP

Demand management

No runway visibility, ad hoc work all leading to never-ending billability issues. There are multiple avenues for funding coming from business, however the big ones are lapped up by teams with influence, and rest . 

Onshore - Offshore time overlap

Conflict Resolution

1. AccountName delivery NR conflict. 

During an incident (INC) deployment, the NR delivery manager consistently pressured the EIG team. A face-to-face discussion was promptly arranged to clarify expectations and establish boundaries for acceptable behavior. The discussion focused on ensuring mutual understanding regarding technical constraints and maintaining respectful communication during critical incidents. Follow-up measures, including ongoing monitoring and feedback mechanisms, were implemented to reinforce these agreements and prevent similar conflicts in the future.

2. Tech lead from another team repeatedly bullying team members

Discussed with person to sensitise about avoidable behaviour. Escalated upon mutliple repeats. Escalated to management. 

3. Big data tech lead dragging feet in delivering solution. 

4. Tech Lead and SM not getting along.

AAG

Improvement Areas

Like most other companies, AAG too has been on the path to Enterprise Agility for several years, which is quite evident in the ways of working (Purple) of teams. Most teams have some sort of autonomy, are multi-skilled (full stack developers at least), and the deployment releases are fairly regular (with excellent CI/CD tool usage) and predictable. The feedback from the business too has been early, and adds value to the unit of work delivered. Encouragingly, it's fairly a widespread phenomenon, unlike in other companies where excellence is limited to certain pockets. 

While those are the positives, the negatives aren't too few, nor something that can be disregarded. Here I list some of the things that could still be improved with intent, right mindset and responsible leadership.

• Lack of demand funnel. 
• Program level prioritisation is cowboy-style individual feat (in that the heavyweights have significant say) than a collective exercise.
• Leadership may not be democratic and likely non-aligned with goals and aspirations of teams.
• Constant team flux, changes, team-movement.
• Frequent ways of working model changes. 
• Poorly defined feedback mechanisms for contractors. 
• Perception-based judgements. 
• Over-reliance on business analysts who double up as iteration managers.
• Not an open culture in some teams, and fear lurking on the flanks with respect to team bigwigs. 
• Last but not the least, Business agility is still in the stone age.

• IM / SM with NIIT. 
• IT Process and Tools consultant with TechM - was SM / IM in Telstra.
• Model and non-model (custom, ISO, CMMI, SPICE, etc.), frameworks
• Tool consulting - Rational Tools, HP QC / ALM
• Incident and problem management.
• Alert and escalation management.
• Last project was with IAG as IM/SM/TM. 

TFS

• Project manager dictating terms, taking statuses, attending daily stand-ups, derailing stuff.
• Third party testing team that didn't get along well with the development team. 
• Testing team didn't communicate about the "bugs" but would go and log them on Jira, and send out a bug status report in the evening. Those bugs ended up being discussed in the daily stand ups.
• Testing team refused to be collocated with the development team. 
• Line managers attending the daily stand ups.

WWC

We are scoring well on customer-centricity (first pillar), lean portfolio management (2^nd pillar – in the form of frontdoor request management / demand funnel management), Organizational design (third pillar)

Delivery framework and Agile mindset is broken. Funding has been a consistent challenge leading to unpredictability and anxiety among teams. As well as a never-ending restructuring in addition to lack of psychological safety (teams are summarily dismissed if something goes wrong). 

Leadership and Culture – we have gone back to waterfall ways of working and there has never been an Enterprise Agility drive aimed to promote agile mindset in Westpac leadership. 

6^th Pillar is not applicable as it is directly related to leadership & culture.

 We are also doing extremely well in terms of the last pillar – Adaptive Technology.

1. Lack of Enterprise Business Agility particularly, Executive Agility as well as Business Agility is lacking, therefore we are chasing anti-agile patterns like

                                                               i.      Freezing requirements instead of baselining and engaging with Business.

                                                             ii.      Over-Documentation

                                                           iii.      Increase in meetings with management for providing management updates.

                                                            iv.      Classical reporting and duplication of reporting at multiple places.

                                                             v.      Belief that process will fix things instead of an Inspect & Adapt way of working. (12 step process for example).

                                                            vi.      Chasing Agile Badges, achieving which does nothing to speed up delivery or increase efficiency or increase customer satisfaction.

                                                          vii.      Business doesn’t participate during initial project phases.

2. Lack of a defined funding model

                                                               i.      Every team is keen to “figure out its next meal”, which is sustaining by getting Clarity allocation. This survival mode ensures there is no scope for focus on improvements or better delivery.

3. Extremely slow delivery-to-market owing to following waterfall ways of working and lack of agility. Most projects take anywhere between 3 to 6 months or more to get into production. So the feedback loop is extremely delayed.
4. Rigid and few deployment slots available for DDEP. Therefore, automation or other ways to speed up delivery will be counterproductive until this bottleneck is resolved.
5. There is no pre-production environment.
6. There is no real SIT happening and the SIT that happens is simply a superset of ST, but not really an integration test.[Sudhakar, Vijay ]  SIT there is no scenario-based testing happening.
7. Lack of test data. Mocking of data is not always effective.
8. Sometimes end to end testing doesn’t happen or happens after prod deployment (TTR; there may be specific program challenges.)
9. There is no defined ways of working to engage Solution Teams. I have proposed a practice similar to how we engage Data governance team.

2. Impacted teams/technologies

All teams in are affected.

3. Solution

• Either implement Classical waterfall OR implement Agile, but not a combination of both.
• If it is Agile, then there is a need to have agile practitioners on the ground. However since both Agile Coaches and Scrum Masters have been removed from the teams, I am not sure whether this is even an option or what exactly Westpac intending to do.
• Reduce documentation:
• Based on the project budget, define the extent of documentation required by projects.
• Have extremely clear communication about teams offboarding/ onboarding instead of teams having to figure out themselves (for example, the entire Change Team from Financial crime will be taken over by the IBM team, however there was very poor and conflicting communication leading to confusion and chaos).
• Define ways to achieve agility in data space by defining how work can be broken down to manageable and deliverable entities.
• Have frequent deliveries to production to get faster feedback from business.
• Reduce practice of trying to document plans and having to keep them updating to reflect reality.  
• Reduce the culture of Risk (having to raise risk for everything) and escalation (notion that things will move if escalated).