1. Why do we … Life cycle processes … simplified !!!

2. The background 2 Why do we v1.1  Studies indicate that when most of us do not do something, it’s not because we don’t want to do it, it is because 1. we do not know why we are being asked to do it and / or 2. we are not aware what its benefits are. Aug 2011

3. The rationale 3 Why do we v1.1  So, when doing something, if we know 1. how it benefits the project team / project performance and 2. how it adds value / competency to other projects thus raising the overall maturity of the organization  Then 1. we do these tasks / activities willingly (nobody has to force us) and 2. we do it correctly, thus maintaining the integrity of the data generated. E.g proper defect classification, proper risk identification, logging timer sheets under proper heads etc, Aug 2011

4. The solution 4 Why do we v1.1  These training modules “Why do we …” have been designed with this perspective. These aim to explain, in simple and lucid terms, how our life cycle processes help the project team members and the organization.  As project team members understand and appreciate the benefits of these processes, we get an automatic buy-in from them. The project gets more interested and committed to the processes. The project team starts owning these processes (rather than doing it for quality group). Aug 2011

5. Why do we … estimate efforts (1/3) 5 Why do we v1.1  Helps us know the number of people, resources and infrastructure needed for the project.  We can give a proper commitment to the customer regarding the efforts required.  So we plan, block and use these resources only as required. Team ramps up and down as per the required efforts.  Maintains the resource utilization / productivity of the project at a high level. Aug 2011

6. Why do we … estimate efforts (2/3) 6 Why do we v1.1  Based on the estimations of one project, other projects plan for their resources accordingly, hence resources do not remain idle or underutilized.  Maintains the resource utilization / productivity of the entire account / organization at a high level. Aug 2011

7. Why do we … estimate efforts (3/3) 7 Why do we v1.1  As estimation capability improves, it indicates the understanding and competence of the people has become better, organization is maturing.  As estimation capability improves, we can give more accurate effort projections to the customers, helps customers plan their budget better.  Overall helps the project and organization be more productive and profitable. Aug 2011

8. Why do we … capture efforts 8 Why do we v1.1  At phase end, helps quantify and understand the difference between actual and estimated efforts.  This helps us to re-estimate efforts better for the subsequent phases.  At organization level, this helps to do better estimation for similar technology projects which are ongoing or due to be taken up.  Helps quantify and understand organizational productivity.  Helps capture rework efforts. Aug 2011

9. Why do we … log review comments 9 Why do we v1.1  When we consolidate and study these review comments, they bring out better ways of doing something so helps us improve our work.  We incorporate such improvements in project standards and checklists, so subsequent deliverables improve.  Such findings are shared across the organization so this benefits similar on going projects and future projects across the organization. Aug 2011

10. Why do we … log defects 10 Why do we v1.1  Helps to properly communicate the defect between the reviewer / tester of the work product and the author of the work product.  When we study these defects, we understand what is wrong and rectify the same (correction).  During defect verification, the reviewer / tester will not have to depend upon memory to know what the defect was.  Help keep a track of which defects are closed and which are still open.  We maintain a log of all our defects so that later on we can then analyze our complete set of defects. Aug 2011

11. Why do we … classify defects (1/2) 11  Gives us a better understanding of defects, where are they injected, where are they detected, which components are more defect prone, what is the type and severity of the defects, who has detected them etc. We come to know how, when, where and to what extent we are failing.  Thus it helps us know in what component / activity / task we are more likely to get defects. So, going forward we conduct a thorough verification process in such areas, put in more efforts to identify these latent defects. Why do we v1.1 Aug 2011

12. Why do we … classify defects (2/2) 12  Once we understand the nature / distribution of defects, we are better prepared to detect them as well as prevent them.  Such improvements are shared across the organization so this benefits similar on going projects and future projects across the organization. Why do we v1.1 Aug 2011

13. Why do we … conduct defects causal analysis (1/2) 13 Why do we v1.1  Out of the multitude of defects we need to know which cause is leading to the most instances of defects - Pareto analysis.  To eliminate an entire set of similarly repeating defects, we need to go their root cause and eliminate the root cause, so we identify the root cause.  Knowing the root cause helps us come up with a corrective action that is more likely to succeed rather than taking a corrective action without really understanding the root cause of the defect.  When we take action to eliminate a root cause, all defects arising due to it get eliminated or reduced to a great extent (Corrective action). Aug 2011

14. Why do we … conduct defects causal analysis (2/2) 14 Why do we v1.1  We institutionalize this action as a process in the project, incorporate such improvements in project standards and checklists, so subsequent deliverables improve (Preventive action).  We share this process across the organization so prevent these defects in other projects also.  Saves rework efforts and delays later.  So overall lesser defects, lesser rework effort and time, leading to improved and timely deliveries, satisfied and happy project team, lesser complaints from customer, higher customer satisfaction. Aug 2011

15. Why do we … identify risks (1/2) 15 Why do we v1.1  Help us be aware of circumstances / situations that our project may face.  In case any these risks are due to client, he can be made aware, thus helping client identify and control the risks and costs at their end.  Project then identifies and takes action to mitigate the effects of the risks and / or takes contingency action in case the risks occur.  Adverse impact of the risk on the project is avoided / reduced, project meets the customer acceptance benchmarks / customer deadlines with minimum overshoot of effort and schedule. Aug 2011

16. Why do we … identify risks (2/2) 16 Why do we v1.1  As project is completed within minimum effort / schedule overrun despite risks occurring, the project team performance is exemplary, project team feels extremely productive and satisfied.  Helps projects be better prepared for such risks in future.  Risks identification and risk management help project team members understand the operational aspects better, helps build better project leaders / project managers within the organization who then consistently drive better project performance. Aug 2011

17. Why do we … (wrap up and evaluation) 17 Why do we v1.1  Towards the end – have a Q and A session with the participants, clarify doubts, make sure participants are clear on the basics etc.  At the end of the session we have a small quiz to evaluate the participants and also take training feedback, both of which will help further improve the module. Aug 2011

18. Why do we … further 18 Why do we v1.1  On similar lines, we can explain the basic purpose and benefits of many other life cycle processes like  Why do we…plan schedules  Why do we… capture timelines  Why do we… create baselines  Why do we… identify metrics etc etc. Aug 2011