This document discusses transitioning from a traditional project-based software development model to a product-focused model. It outlines changes needed across several dimensions, including role definitions, taxonomy, culture, talent, funding models, and leadership. It then provides an example case study of transforming a bank's IT organization by starting with an experimental product team, establishing alignment between business and technology, shifting to a product taxonomy, moving to outcome-based funding, empowering teams, and focusing on cultural transformation. The goal is to transition from a "black box IT" project model to an agile, lean, product-oriented approach over 9-12 months.

1. Unique way of next generation software development
Project to Product

2. Traditional projects
“deliver features”
Delivery of features
Success measurement on
time and budget
Bounded context teams
Compartmentalized skills

3. Product thinking
“deliver for future”
Delivery of outcomes
Success measurement on
business impact, NPS etc.
Self empowered teams
T-Skill across areas

4. Change needed in 360 dimension
Need to re-write the rules of the role
Role definition
Enterprise common taxonomy must
be established
Taxonomy
Expand the sphere of influence
Sphere of influence
Cultural shift
(north-South/East-West)
Culture
One object with two dimension
Business/technology
unification
Talent transformation is inevitable
Talent
Leadership buy in, sponsorship
Leadership

5. Team aligned to north star goal
BA
Developers
Testers
BA
Developers
Testers
• Every member works for single NorthStar goal
• No squad or scrum level goals
Single NorthStar goal

6. Role definition
Break the wall
Analyst Project manager
Thinks Project
managers:
• Only cares about time &
budget
• Manages customer
relationship
• Keeps team morale of first line
reportee
Thinks Business
analyst:
• Converts requirements to
consumable documents
• Not required to know the
technical aspects of solution

7. Taxonomy
W h a t i s a n a c c o u n t
o p e n i n g s c r e e n
Business analyst
• Must happen in three minutes
Architect
• Must handle 300 concurrent users
UX designer
• Must happen with 7 clicks
Developer
• 2 angular screen and 40 Spring boot
classes
Project manager
• 1 man month effort with 200K budget
E n t i re t e a m m u s t u s e s t a n d a rd i z e d t o p o l o g y w i t h c o m m o n o b j e c t i v e s

8. Sphere of influence
Analyst Project manager
• Aligned on Customer
side
• Translation of
requirements
• Measured on containing
scope creep
• Aligned both customer
and organization side
• Managing delivery,
morale, customer
• Measured on cust. Sat.,
time, budget
In product world there is no fixed sphere of
influence, entire team is responsible for full life
cycle and work towards common NorthStar

9. Culture
Agile Open
Empowered Informed
Flat hierarchy
Stake in the game

10. Business / technology unification
Create self- organizing “product
networks.”
Network hierarchy
Drive a data-drivingorganization.
Data driven
Expanded focus on product-based
outcomes.
Outcome based
LEAN prioritizationprocess.
LEAN
Technology and business operate as one
team.
One team model
Introduce the concept of Lean Value
Streams.
Value stream
Product owners areauthoritative source
for priorities.
Ownership
Align to overall business strategy.
Strategy driven
Establish routinesaround discovery

11. Talent
Do not treat technology organization as
cost centers
Cost centres
Technology based and not project
based
Investment
Breakdown PMO organization
PMO
Elevate scrum master to coaching
roles
Scrum master
Start with agile, tech and domain
bootcamps
Enablement
All trainings tailored for product
management focus
Product focus
Less management layer and
optimized team sizes
Organization
Reduce non-technical roles to extent
possible
Non-technical roles

12. Leadership
Ensure resistance dealt effectively
Manage resistance
Augment teams with transformative leaders
Transformation leaders
Become influencers of the community
Influencers
Focus on establishing a community
Community
Implement bottom-up cultural change
Cultural
Establish incentive model, empowerment and
cohesion
Incentive
Learning is a continuous cycle for whole team
Learning

13. Case study
Lets take RP bank as our case study who is embarking upon a digital
transfo4rmation journey however still in the old style project based delivery
model.
Big bang approach of changing from project to product would be disastrous
and needs a progressive approach in the various dimension as explained
earlier:
• Transformation implementation
• Business and technology synchronicity
• Product taxonomy
• Workforce and talent
• Founding mode34l
• Architecture
• Coverture and leadership
Current setup:
• Project manager, business analysts, developers (FE and BE), testers
• 70% contractors and 30% in-house, totaling to 300
• Separate development and operations team
• 7 levels of hierarchy

14. Transformation implementation
Transformation implementation
• A small team of API design and build team was formed as an
experimentation.
• The following are the goals set to the team:
• Reduce account inquiry MIPS by 5%
• Reduce time to deploy new build to test environment by 20%
• A squad was established to bring full stack development philosophy
• The coaches educated the team members of the new roles
• An agile mindset and Devops was established
• These learnings and success were used to replicate for big bang
implementation
• Regular management meeting by CIO organization was setup to preach the
vision, intent and the reason for the model being implemented
• This time period would be anywhere between 9-12 months
• During this time frame the total projects also will be reduced to 10% over a
period of time
No more a “black box IT”
Agile Lean Product oriented

15. Business and technology synchronicity
Business and technology synchronicity
• Established product leadership roles spanned across business and IT to
ensure continuous alignment to products
• Shorter planning cycles across business and IT was established (Quarterly
product planning QPP)
• These QPP helped to establish roadmaps and OKR for the different
product teams
• OKR paved way of networking on inter product teams based on
common OKR’s
• Product owners and coaches were expected to work proactively on solving
future road blocks or show stoppers, dependencies rather than spending
more time on the current sprints
• Coach support was reduced over period of time to make the product
network self sufficient
OKR based QPP
Empowerment Collaboration

16. Product taxonomy
Product taxonomy
• An enterprise level product taxonomy structure was formulated
• The technology leaders were expected to map their product taxonomy to
the enterprise level taxonomy as part of the QPP
• The product teams were coached on the larger product taxonomy to
understand where their product sits in the enterprise
• When the mapping exercise matures product teams will realize the
positioning of their product in the value stream
Enterprise product taxonomy
Product mapping Value steam mapping

17. Workforce and talent
• Progressively move product owners from IT to business
• Traditional roles replaced by product owners, scrum masters, full-stack
engineers
• By above changes the hierarchy delayered to 2-3 layers
• The contractor's skew was reduced drastically as the ownership of existing
teams were increased to greater extent
• Implementing repeated agile bootcamps nurtured agile culture
Delayered hierarchy
Speed Quality Cost

18. Funding model
• Funding model moved from big bang approach to quarterly funding
• Funding model for project approach changed to products
• Funding was based on outcomes which in turn divided into OKR’s
• Every quarter leaders determine how many product team requires based on
the outcome, OKR and product roadmap
Outcome based funding
OKR Product roadmap Quarterly

19. Architecture
• Empowerment is one key factor for architecture. Engineers were provided
with power to participate and raise voice in the architecture decision or
design decision meetings
• The concept of governance slowly transitioned into value guidance where to
align architecture towards the OKR and outcome
• Automation first principle was adopted
• microservices and API become the norm and the teams were coached to
think on these lines rather than monolith.
• The architecture were designed in such as fashion so that it can be managed
by small, empowered, customer focusing, self-manning teams.
Value guidance over governance
Small teams Empowered teams Self managing teams

20. Culture and leadership
• Inner engineering culture was build to emphasis on int3rnal intellectual
capital and inner sourcing
• Cultural transformation were augmented buy hackathon, demo day, Devops
day, project engineering inner conference, which paved way for networking,
knowledge sharing, best practice etc.
• Every engineer was given opportunity to look at a creative solution to solve
customer problem rather than a continuous flow of requirement as in
waterfall
• Resistance to change need to be broken through coaching
• Culture and leadership transformation were never achieved in single iteration
and needed continuously learning optimization
Inner engineering culture
Break resistance Optimization as a way of life