Savio Saldanha Consulting

Had a great time training and interacting with the participants of this one day session - PMP Refresher Course - July 22, 2017. # of participants = 45 Venue: St Francis Institute of Management and Research, Borivali Look forward to continue to educate people on effective project management and its best practices. For custom on-site training at your company and advice that will help you deal with real life situations and problems, send in an email at consultsavio@gmail.com or call on 09768349000. Topics Covered and Activities Performed: PM Process Framework - Process Groups and Knowledge Areas Inputs-Tools & Techniques - Outputs Practical hands-on use of techniques on real life PM scenarios Discussions on practical considerations of PM on large scale projects Sharing real life tips to better manage people and projects  PM bad practices through real life case studies Preparatory questions answered Certificate presentation

Here are some terms according to PMI that you should understand and distinguish as part of your PMP preparation. Terms grouped together are part of an umbrella concept and have their differences; so don't let them confuse you. Wishing you all the very best in your PMP endeavors. -SavioS ------------------------------ Apportioned Effort. An activity where effort is allotted proportionately across certain discrete efforts and not divisible into discrete efforts. Discrete Effort. An activity that can be planned and measured and that yields a specific output. ------------------------------ Analogous Estimating. A technique for estimating the duration or cost of an activity or a project using historical data from a similar activity or project. Bottom Up Estimating. A method of estimating project duration or cost by aggregating the estimates of the lower level components of the work break down structure(WBS) Parametric Estimating. An estimating technique in which an algorit...

It is with great joy and gratitude that I present to you my first ever self review, wherein I was evaluated by the members of my team at a leading IT major on multiple parameters. I have initiated this evaluation with a view to ensure that the teams that I guide and nurture truly benefit from my services, grow successfully and realize their capabilities. Given the encouraging response received, I intend to factor in the reviews and pursue my goals with continued zeal and excellence in mind. The team was polled for the following: Fair treatment Individual professional and personal development Trustworthiness  Recommend my services  And here are the results: 100% positive responses from my team on all counts. I am humbled. This result goes to show that it is through the attitude of servitude that we build great teams. And I shall continue to do so. NOTE: The poll was taken on paper and is ready for presentation upon request. God bless. SavioS

Be it a formal inspection or a guided informal peer review, reviews on average find around 60% of the defects in the system being built. And even though the evidence in favor of performing reviews is overwhelming, not many organizations practice this simple activity, and its mostly due to lack of management backing. So if you're in a team that doesn't review yet, be sure to propose the reviews as an activity that will surely help improve the quality of the software being built. Benefits of performing reviews: A. Lower cost of defect correction The longer a defect lies in a system, the more costlier it becomes to rectify it. A high severity defect found in production costs a 100 times more to resolve than if it were found during the requirements stage. A low severity defect found in production costs 2 times more to resolve than if it were found during the requirements stage. Since reviews can be performed as early as the requirements stage, the potential cost benefits ar...

This topic has been touched many times over on the internet; I'll leave out the advise of keeping simple, your test cases and the language of your test cases. Without going into methodologies and techniques used in testing, I'd like to outline a few principles of test case writing that you should bear in mind the next time you're writing test cases. 1. Design scenarios Firstly, don't think of writing test cases.. :) Or anything related to test cases. For the particular application / unit under test (AUT), take time to think through and identify possibilities of: Inputs - All possible inputs that can be given to the AUT. Your inputs can be data or a certain action to be performed, like clicking a button Outputs - All possible outcomes / behaviours of the AUT in response to the input  Trigger points - Conditions that when activated, cause the AUT to perform certain action(s) Alternate flows - When testing workflows, always ensure you identify flows other than t...

A friend and I were recently talking about the kind of common yet critical mistakes that are made quite unknowingly during the test phase of the SDLC. Some of the points mentioned below are the kind of processes mandated by companies for ages! It is not uncommon to see that test managers, along with the test leadership within companies making such blunders. And if you see such practices being followed at your company, let them know that they should be ridding themselves of these common mistakes. 1. Test cases are not traced back to the requirements One of essential artifacts of the testing phase is the Requirement Trace-ability Matrix. What this matrix does is help you link your requirements to your test cases. As a result, you would be aware of the coverage your test cases provide to your requirements. Not having an RTM puts you and your team at the risk of coming up with an incomplete coverage of the requirements  and the possibility of leaking defects. Her...