IIIT Guest Talk 0512


Published on

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?

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

IIIT Guest Talk 0512

  1. 1. IT Project Management 1
  2. 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. 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. 4. Who am I?  https://www.facebook.com/vasantha.gullapalli  http://www.linkedin.com/profile/view?id =2574654&trk=tab_pro 4
  5. 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. 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. 7. Discussion College Projects – How well are the students getting prepared? 7
  8. 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. 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. 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. 11. Project Management Methodologies Waterfall Critical Path Management Iterative Extreme Program Management Agile, etc, etcMost discussions and debates are between Waterfall and Agile 11
  12. 12. Waterfall vs. Agile Waterfall  Agile 12
  13. 13. Methodologies – Pros and ConsPure 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. 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. 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. 16. The Real World – Not too far from this 16
  17. 17. Case Study A Website Renovation 17
  18. 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. 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. 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. 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. 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. 23. Phase DefinitionsPhase DeliverablesDiscovery  Business, Technology and Design Drivers  High Level Scope Prioritized  Prioritization Criteria Defined and Understood  Weekly plan for Design phase with trackable milestonesDesign  IA and Design Deliverables on a weekly basis  Technical Architecture Definition  Technical Design documents  Detail Sprint plan for Development and weekly milestonesDevelopment 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. 24. Phase Definitions - continuedPhase DeliverablesFinal End-to-End Testing  End-to-end scenario testing  Bug fixing sprints  Prioritization of any scope changes/additions with remaining bugsUAT  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. 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. 26. Questions? 26
  27. 27. Team Management Critical Aspect of IT Project Management 27
  28. 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. 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. 30. Discussion How to better prepare students for corporate world 30
  31. 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. 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. 33. Feedback/Questions More on my blog http://pmship.blogspot.com 33
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.