Expectations from IT Team Project Methodology - Why it is as important as the Technology for your Product Gaps in Recent Graduates How to bridge these gaps?

1. IT Project Management
1

2. Goals of this talk
 Expectations from Technologists
 Project Methodology – Why it is as
important (or more) as the Technology
Solution
 Employability of Recent Graduates –
Commonly Seen Gaps
2

3. Agenda
 Introduction – Who am I?
 Role of IT Teams in Companies
 Typical Web Projects
 Discussion– College Projects
 Project Methodologies
 Case Study – A Popular Website
Renovation
 Most common issues seen with ‘Freshers’
 Discussion – How to better prepare college
graduated
3

4. Who am I?
 https://www.facebook.com/vasantha.gullapalli
 http://www.linkedin.com/profile/view?id
=2574654&trk=tab_pro
4

5. Role of IT Teams in Companies
 1990s – Service Providers, Cost Center,
Necessary but, not critical
 Early 2000s – Recognized as being
business enablers
 Now
 Innovative use of Technology is a Business
Differentiator and Game Changer
 Lines blurring between product, business and
technology
 Technology teams expected to be more
Innovative, Independent and Strategic
 Strategic Thinkers, rather than just ‘Do’ers
5

6. Typical Web Projects
 Fast Paced: 4-16 weeks.
 Design, Scope, Priorities are all evolving throughout the
lifecycle based on user testing and other market conditions
 Fixed Dates: PR and Marketing plans made around the
launch date. Very difficult to move dates
 Date, Cost, Team are expected to be committed upfront 
 Unless the Delivery team and Business/Product team work
collaboratively, environment can easily become
confrontational
6

7. Discussion
College Projects – How well are
the students getting prepared?
7

8. Discussion – Student Projects
 Give me some examples
 Typical Duration, Team sizes
 Do they get to choose the software stack?
 How are the students expected to gather/define
requirements?
 Lifecycle that students are expected to follow?
 What are they expected to present in the end?
 What are they graded on?
 Working product?
 Is discipline about the lifecycle important?
 Are they expected to defend and debrief about their
project?
8

9. Discussion continued
 What are some challenges you see in
 Inculcating the right attitude in students
 Monitoring these projects?
 How well are the students making use of the
projects to better prepare for the real world?
9

10. IT Project Management
 Project management is the discipline of
planning, organizing, securing, and
managing resources to achieve specific
goals
 IT Projects tend to be less stringent than
those in other industries
 But, Good PMs will know how to inject
some Method to this Madness
10

11. Project Management Methodologies
 Waterfall
 Critical Path Management
 Iterative
 Extreme Program Management
 Agile, etc, etc
Most discussions and debates are between
Waterfall and Agile
11

12. Waterfall vs. Agile
 Waterfall  Agile
12

13. Methodologies – Pros and Cons
Pure Waterfall Pure Agile
 Works well when the  Works well when requirements are not
requirements/specifications are ‘ALL’ firmed up, but team can start on
some
well defined and stable
 Collaborative cultures prefer this – lot
 Traditional Business groups like more handshaking, working together,
this – responsibility shifts over trust in each other
the wall
 Not very deterministic on what gets
delivered on <x> date or when <y>
 Detailed planning helps map out feature gets delivered
all dependencies ahead of time –
especially important when team is  Assumes very high collaboration (co-
distributed and matrixed location) between the different teams
(product, design, tech, QA)
 Works well when team
management is highly structured  Equipped to handle changes with
and process oriented and know minimal disruption to overall flow
what they want
 Assumes a more experienced self-
managing team
 Not well suited to handle changes
along the way  Focus on QA from early on – good for
quality
 Testing in the very end is risky
13

14. The Real World
 None of the methodologies work as-is – Need to customize
based on
 Company Culture
 Collaboration between product/business and development team
 Project Context
 What is the main driver – Scope, Time, Budget? – Budget is
always fixed. Need to know which one trumps – Scope or
Time?
 Most of the projects start with a fluid product idea and a somewhat
firm launch date for marketing/PR reasons
 In order to commit to a date, we will need to do some upfront
scoping, estimating and planning to inform the team size,
dependencies, budget, etc – So, pure Agile doesn’t work.
 Too often, we have to start a phase before the previous one ends
(start development before design completes) – also need to be able
to absorb changes and additions to scope – So, pure Waterfall
doesn’t work.
14

15. The Real World continued
 Change Management Culture
 Change is always constant
 Team Strengths and Structure
 Multi-disciplinary?
 Multi-location: Not ideal for Agile. Agile emphasizes
face-to-face meetings vs. detailed documentation
 Experienced vs. Newbies: Team is not always
experienced at the same level - so, need to account
for ramp-up and varied degrees of team
management
15

16. The Real World – Not too far from this
16

17. Case Study
A Website Renovation
17

18. Website.com Renovation
 Project Conceptualized in Jan
 Project Definition, Feasibility, Budgeting
– Until April
 Fixed Live Date: Sept 16th
 Project Lifecycle – April to Sept
 Scope included complete Architecture Revamp
 Design
 Development
 QA
 Launch
18

19. Methodology in this context
 Needed to do waterfall like upfront scoping,
estimation and planning assuming lots of
unknowns to fix team size, inform business and
design team on high level scope constraints
 Needed to be agile enough to absorb changes
and shifts in priorities along the way
 Needed to focus on Quality early for better
quality
 Improved User Experience and Performance was one of
the project drivers
 Needed to tailor the methodologies to our context
19

20. Hybrid - Common Sense Methodology
 This is the Hybrid methodology that worked in
this context.
Final Design Drop
Detail Scope,
High Level Scope
Design Drop 1 Design Drop 2 Detail Estimate and Plan
Initial Estimate
Discovery UI Design UI Refinements
Demo
Demo Demo
Eval Changes
Evaluate changes Eval. Changes
Tech Evaluation Tech Design Sprint Sprint Sprint Sprint
Development and QA Sprints
Final Testing, UAT,
Launch
20

21. Overall Rules of the Engagement
 Focused early-on to clarify the What, Who and How
 What: What does Renovation mean?
 Key business, Design and Technology drivers identified and
documented.
 Design Criteria Documented
 Scope Prioritization Criteria Documented
 Who: Who are the decision makers – Business, Product,
Design and Technology
 Focused on Quick Decision-making
 Decision making de-centralized, very few decisions move up to
stakeholders
 How: Technical Solution should be practical to meet the
current timeline and in line with long term vision
 Technical Leads need to ok the designs based on feasibility –
emphasize partnership with technology team
 Daily checkpoints during design – emphasize quick decisions
 Technology owns overall PMO guiding the stakeholders’ decision
making keeping and eye on the timeline/milestones
 Product, Business and Design attend daily SCRUM to resolve issues
real time – emphasize high collaboration
21

22. Rules of Engagement - Themes
 Quick Decision Making and De-centralized
Decision Making
 Mutual Trust among Multi-Disciplinary
groups
 Collaborative Working Style
 Working software over comprehensive
documentation
 Continuous Prioritization of backlog,
change requests, bugs
 Laser Focus on Timeline, Milestones, No
room for slippage
22

23. Phase Definitions
Phase Deliverables
Discovery  Business, Technology and Design Drivers
 High Level Scope Prioritized
 Prioritization Criteria Defined and
Understood
 Weekly plan for Design phase with
trackable milestones
Design  IA and Design Deliverables on a weekly
basis
 Technical Architecture Definition
 Technical Design documents
 Detail Sprint plan for Development
and weekly milestones
Development and QA  Development and Continuous QA
 Weekly milestones review with all
stakeholders
 Regular Demos to stakeholders
 Review and prioritization of backlog,
scope changes before each sprint 23
planning

24. Phase Definitions - continued
Phase Deliverables
Final End-to-End Testing  End-to-end scenario testing
 Bug fixing sprints
 Prioritization of any scope
changes/additions with remaining
bugs
UAT  User Testing
 Continuous Prioritization of
remaining bugs as “Launch Gating” or
not.
Launch  Production Release
 Go Live !!
 Prioritization of remaining backlog for
post-launch releases
24

25. Recipe for Success
Successful Project Delivery =
Understand the ‘What, Who, How’
+
Lots of Common Sense and Discipline to pick the
right aspects from the prescribed ‘methodologies’
to cater to your context
+
Experienced, Focused Leadership, Managing the
Multi-disciplinary teams
+
* Disciplined, Committed,
Collaborative Teams *
25

26. Questions?
26

27. Team Management
Critical Aspect of IT Project
Management
27

28. Expectations from Technology Team
The 3 C’s
 Competence
 Thinkers vs. Do’ers’
 Need to hit the ground running – Very little room for training
 Innovation to help the business – not just for the sake of it
 Commitment
 Commitment around timelines, scope and budget
 Ownership, Be ready to make decisions
 Communication
 Discipline and Clarity in Communication
 Estimation
 Tracking
 Accurate Status Reporting
 Ask for help before it is too late
 And there is a 4th one – Courage
 Courage to do the right thing at all times
 Courage to accept mistakes and learn from them
28

29. Typical issues we see with Freshers
 Competence
 Aptitude vs. Attitude
 Too much focus on Technology
 Lack seriousness about Quality
 Need to be more self-starters
 Commitment
 Not serious about commitments
 Proper definition of ‘Done’
 Not taking the timelines seriously
 Communication
 Presentation of ideas
 Facilitation skills
29

30. Discussion
How to better prepare students
for corporate world
30

31. How do we better train the students?
 Get the Foundation Strong
 Projects to show how the concepts they learn are applicable in real-
world (algorithms applied in real world)
 Let them do some research on the various architectural choices
(software and hardware)
 Encourage ‘Smart’ Innovation
 Focus on outcomes
 Discipline around Software lifecycle
 Exposure to various methodologies
 Focus on choosing and following a lifecycle
 Get used to estimation and planning
 Ask to demonstrate intermediate milestones to instill discipline of
regular deliverables
 Quality Consciousness
 Simple test cases, Edge cases, browser compatibility
 Encourage Internships
 Pick the right environment, Big brands don’t always translate to good
experience
 Helps develop communication skills, professionalism and get used to
31
the rigor of real-world

32. Key Takeaways
 IT Teams are no longer just ‘Doers’
 The 4 C’s
 Competence
 Commitment
 Communication and
 Courage
 Just being smart technologists and innovators is not enough –
Discipline and Methodology are important to be able to deliver on
time and within budget
 Methodology has to be customized to fit the project and not the
other way round
 Graduation with an engineering degree alone doesn’t make one
Employable.
 Inculcate the right attitudes
 Life-long Learning
 Smart Innovation 32
 Strategic Thinking

33. Feedback/Questions
More on my blog
http://pmship.blogspot.com
33