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.
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.
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 (2nd 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.
6th Pillar is not applicable as it is directly related to leadership
& culture.
- 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.
- 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.
- 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.
- 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.
- There is no
pre-production environment.
- 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.
- Lack of test data.
Mocking of data is not always effective.
- Sometimes end to end
testing doesn’t happen or happens after prod deployment (TTR; there may
be specific program challenges.)
- There is no defined ways of working to engage Solution Teams. I have proposed a practice similar to how we engage Data governance team.
- Impacted teams/technologies
All teams in are affected.
- 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).
Westpac
No comments:
Post a Comment