The presentation gives a glance on the software quality analysts who has to take up the full responsibility to ensure compliance. It inspires the analysts with different methods and examples for a successful delivery.

1. Effective Quality Facilitation – Beyond Normal
By
Ramkumar Ramachandran
Head – Quality
Renault Nissan Technology & Business Centre India Pvt Ltd,
Chengelpet

2.  Quality Facilitators – A Breed by themselves
 Eye for Delivery
 Tech Savvy Facilitator – An oxymoron?
 Eye for Engineering
 Eye for finer aspects
 The All-Friends-World
 Fear Vs. Fate Vs. Professional Respect
 Escalation for lunch
 Success = ƒ (Interactions with project team)
 Do-This-Do-That Syndrome
 Facilitation Success Indicators
 Case Studies
Contents

3. What this session is all about

4. Quality Facilitators – The Normal Breed
• Software Quality Analysts – SQAs are a breed by themselves.
• Have full responsibility to ensure compliance.
• Have less authority to enforce compliance.
• Is seen as threat in project or threatened by project.
• Hit by Project team and by QA Seniors.
• Always wants to make a point but makes enemies.
• World View  Compliance is PM’s capability, non-compliance is
Facilitator’s inability.

5. Quality Facilitators – A Class Breed
• Facilitator is always visible to the delivery team
• PM ensures Facilitator’s presence in all status review meeting
• Facilitator conducts training on processes
• Project schedule is closely tracked by Facilitator
• Facilitator has planned reviews with PMs
• Networks to bring best practices from others
• Is also visible to the customer
• Is contacted by delivery team for any change in delivery methodology
• Knows to make a point without making enemies

6. My Mantras
I’m going to talk about my Mantras. The Mantras that I’ve practiced over
a period of time and have yielded results.
Yes, there is no rocket science in this, but it is pure distilled common sense.
I guarantee you results by following these Golden Rules with near nil exception.
Believe in me and start this journey…!

7. Mantra # 1 – Eye for Delivery
• All the processes are for successful delivery – never lose this focus
• All the facilitation has to converge into delivery success
• Bother more about contract, cost sheet, effort over run, design, code
quality etc
• Never harp upon documents for document-sake
• Be equipped to relate a compliance to successful project delivery. For
eg. Why code review?
• Resist short-term process violations with justifications on long-term
benefits

8. Eye for Delivery (contd.)
• Never force a consistently successful project to shed its result
yielding practices
• Remember, wherever a project makes consistent quality
deliveries, there is definitely a ‘system’ working for them –
Analyze it
• This ‘system’ could be ‘set of practices’ by individuals in the
project or the organization’s QMS
• When ‘set of practices’ is outside QMS, help the project to: -
– Comply to organization QMS and tailor their needs (OR)
– Enrich QMS with their local best practices (OR)
– Share them as ‘Best Practices’ to SEPG

9. Mantra # 2 – Tech Savvy Facilitator – An Oxymoron?
• Remember – we are in Information Technology Industry
• Being tech savvy is a need for everyone in IT
• Tech Savvy Facilitator need not be tech wizard
• It is important to
– Know various technologies (Client Server, Web based, Multi-tier,
SOA etc.)
– Their strengths and weaknesses, broadly
– How an architecture fits into a business solution
– How design fits the architecture

10. Tech Savvy Facilitator – An Oxymoron? (contd.)

11. Tech Savvy Facilitator – An Oxymoron? (contd.)

12. Tech Savvy Facilitator – An Oxymoron? (contd.)

13. Exercise – 1
A bank has decided to automate in a major scale. The broad goals to be
achieved are: -
- Availability of central customer database
- Branches should be able to retrieve & update
customer information
- Customers should be able bank in any branches
How do you want the architecture to look like?
(10 minutes to discuss 5 minutes to present per group)

14. Mantra # 3 – Eye for engineering
• Facilitators should ensure that engineering artifacts are reviewed
• Facilitators should have gone through RS Pressman fully atleast once
• As Facilitator, one should get a hold of: -
• Application Architecture
• High level design
• Coding standards availability
• Facilitators should refer to LLD and verify the implemented code
• Facilitators should be able to appreciate that ‘design’ has to finalized
and then implemented in the code
• A deep glance into design and getting a good hold of the same is
always good
• Facilitator is not a Technical Architect, but still should have an
engineering ‘flair’

15. Eye for engineering (contd.)
• Indicators for Engineering ‘flair’: -
o Check coding standards for current technology
o Understand the application architecture
o Glance through the HLD / LLD
o Ensure code review is a ‘scheduled activity’
o Ensure an ‘effective’ code review – effort proportional to defects
o Sample passed test cases and run the application to confirm the
same
o Study requirement and confirm that traced test cases are
adequate

16. Mantra # 4 – Eye for finer aspects
• Verify activities in its ‘natural’ flow
• For eg. Design baseline – how many activities to be verified?
o Check first baseline of requirements in CM repository
o Check design document baseline date > Requirements baseline
date in CM repository
o Check design review date <= design baseline date
o Check for timesheet effort in and around corresponding activity
o Review defects count proportional to review effort
o Update of RTM after design baseline date

17. Eye for finer aspects (contd.)
• Eg. Project with ‘crunched’ effort
• Ask the PM whether he/she can ‘really deliver the project in this
duration / effort’
• In the event of predicted delay, check for dependencies on the
client’s side
• Is there prioritization of the features, so critical ones get
delivered first
• Are the skill levels of team members good enough to do delivery
‘right the first time’?
• If any of the above is a ‘NO’, has the same identified as risk?
• Has this risk been discussed with appropriate Seniors and/or in
appropriate forums?
• Seasoned SQAs can take it up with their senior or with PM’s
senior and discuss the issue

18. Eye for finer aspects (contd.)
Requirements sign off
Skill fitment
Test Case Adequacy
Effort / Size Estimation
Testing Efficiency
Effective CM practices
Design effectiveness
Metrics collection & analysis
Effective Defect TrackingProject Scheduling

19. Exercise – 2
Form groups, and let each group take one of the scenarios of
above slide and provide the maximum finer ‘verifiable activities’
that can be done to confirm it’s compliance
(5 minutes to discuss 3 minutes to present per group)

20. Mantra # 5 – The All-Friends-World
• Pointing out issues is not pointing out enemies
• Facilitators always talk about ‘systemic-problems’
• Reporting process gap is professional and not an ‘un-
friendly act’
• Facilitator reporting issues is NOT the same as reporting
NC reported in PCR / IQA
• Have ‘clinical-detachment’ to the issues you report into
the
project
• Do not ‘grade’ a person based on issues reported in their
project
• You can always report huge process issues and still have
coffee with the Project Manager

21. The All-Friends-World (contd.)
• Points to ponder
o Why should the SQAs not be emotionally attached to their
findings?
o Why is the facilitation not like an audit?
o Why should the SQAs harmonize with an ever-erring PM?

22. Exercise – 3
The PM of a project where the effort estimate has no relation to the
schedule with no consistent monitoring mechanism has to be told
about the same.
o Participants to write down the risks
o Do a role play on how they will communicate the same to PO
o Trainer will act as the PM
( 5 minutes / group)

23. Mantra # 6 – Fear Vs. Fate Vs. Professional Respect
• Fear
o ‘How will it sound if I tell code review is not done?’
o ‘I very well know that design is not base lined, but can
I stop the coding activity?’
o ‘If I report that person ‘X’ has not closed all defects,
will it harm him/her’
o ‘This is new technology, and project team tells UML
addresses both requirements & design. I’m not sure
how to facilitate’
o ‘The PL wants me to prepare the plans. If I escalate
this I will lose the rapport’

24. Fear Vs. Fate Vs. Professional Respect (contd.)
• Fate
o ‘Never does the project hear me. It is always like this, cooking
documents is a way of life’
o ‘Whatever I tell will be vetoed by Seniors, better let me not use my
energy is such things’
o ‘The culture is not pro-process. My effort will only be futile in such
environment’
o ‘I get hit from both sides. This is a donkey’s job’
o ‘If only I was a developer, the job would’ve been more cushy’

25. Fear Vs. Fate Vs. Professional Respect (contd.)
• Professional Respect
o Mr. PM, please understand that I’ve got equal concern about
project’s quality delivery
o New technology, ok, but did you see any need for change in
processes?
o Coding started, ok, but what is the logic you are going implement,
without a baselined LLD?
o You are creating a local practice, but have you formally tailored it
o I can prepare the plans for you the first time, but remember that
you have to ‘own’ it

26. Mantra # 7 – Escalation for lunch
• Rapport with the project is key for successful process rollout
• Any process violations has to be discussed, accepted and
implemented
• Any ‘undue’ delay in closing the identified gaps has to be reported
‘formally’
• Non-escalation and subsequent project bombing would reflect bad on
facilitation
• Escalation without enough project handholding will as well look like
passing-the-buck

27. Escalation for lunch (contd.)
• Points to ponder
o What should the SQAs do when the PM is requesting not to
escalate?
o What should the SQAs do when it is clear that nothing can be done
even if escalated?
o High possibilities of soured relationship post – escalation, how to
handle this?

28. Exercise – 4
• What are the scenarios that you would escalate?
• How will you do the escalation?
(5 minutes to discuss 5 minutes to present per group)

29. Mantra # 8 – Success = ƒ (Interactions with project team)
• SQAs is a key stakeholder in the project
• SQAs should bother about successful deliveries by projects that they
facilitate
• SQAs to be treated as ‘Delivery Team Member’
• SQAs should know majority of the project team members by name, not
just PM
• Majority of the project team members should know the SQAs too
• SQAs should have ‘planned interactions’ with the project team

30. Success = ƒ (Interactions with project team) (cont)
• SQAs should follow a 40:40:20 interaction philosophy
• 40% of the time personal in-place interactions
• 40% of the time desktop reviews
• 20% of the time generic QA activities
• This is more rule-of-thumb may vary based on project’s nature
• Interact with every role players in the project
• SQAs should approach everyone with clear agenda

31. Success = ƒ (Interactions with project team) (contd)
• Roles whom the SQAs should interact
Project Lead
Developers
Business Analyst
Customer
Testers
Project Manager
DBA
Delivery HeadPre-Sales team
memberPMO team member
On-site coordinator

32. Points to ponder
• How does the SQAs get to know the team members?
• Should the SQAs keep meeting the Developers / Testers often?
• SQAs gets all the info from PM, still is it required to interact with other?

33. Exercise – 5
What are the questions that has to be put to Developer / Tester?
• Participants should list out the questions
• Trainer will play the role of Developer / Tester
• Participants to play the role of SQA’s
( 5 minutes / group)

34. Mantra # 9 – Do-This-Do-That Syndrome
• SQAs should NEVER ever tell the project ‘Do this, because that’s what
QMS wants’
• SQAs should only ‘reason out’ the need for QMS practice
• SQAs should also take the ‘risk mitigation’ route of process compliance
o ‘If you don’t plan for code-review, then…’
o ‘If you don’t use the design template, then…’
• As a pre-requisite, SQAs should have a thorough knowledge on QMS
• SQAs should be able to answer any needs of QMS

35. Exercise – 6
• Reason out the need for the following: -
– Need for SDLC
– Need for templates
– Need for metrics / quality goals
– Need for traceability matrix
– Need for CAR meeting
– Need for IPP
– Need for design
– Need for baselining CI
– Need for release audit
– Need for code reviews
(10 minutes – Free-for-all)

36. Facilitation Success Indicators
Under normal circumstances: -
• Smooth deliveries of the project
• Defect decrease across shipments
• SQAs involved in all critical project reviews
• SQAs is consulted for any change in practice
• SQAs is invited to present in client meetings
• SQAs is able to tell easily the current ongoing activity of the project
• SQAs is well aware of the current project challenges on various fronts
• SQAs is invited for project celebrations…!
Note: The ownership of project delivery is always with PM. SQAs is an enabler for good project
deliveries

37. Case Study – 1
The story of a complicated technology and
compliance challenges

38. Case Study – 1
A project with an effort of 350 person years of effort for modernizing
sea port handling. This involves complicated solutions for logistic
companies, customers, sea farers, governmental bodies etc.
The technology was mixture of n-tier, mobile based and web-based
solution. Government used it from their desktop, customer from web
and few others from their handhelds.
The Delivery Head felt that there should be strict process compliance
from day one. What are the key activities for project’s success that an
SQA should be looking into?
(15 minutes for discussion & preparation / 5 minutes for presentation)

39. Case Study – 2
The dilemma of a diluted estimation

40. Case Study – 2
• Arjun work for ‘Astra Teksolutions’. He is not a very happy soul these
days. After taking up the current project as PM for a Belgian client, life
has become too hectic. This project was to develop a focused solution
for Belgium diamond factory.
• Arjun’s organization, with a zeal to get the first diamond domain deal,
bent backwards. The initial effort Arjun provided with around 5%
cushion, was 73 person months.
• The Belgium client’s CIO was a great negotiator. He informed ’43
person months. Take it or leave it’. Astra never had an inclination to
leave this project. Arjun’s boss was considerate and told Arjun that 12
person months cost would be borne by the company. Still, Arjun has to
manage with the 55 person months of effort

41. Case Study – 2 (cont)
• Arjun has lost his sleep. His dreams are nightmares of ‘Death March’
projects. Normally, a systematic guy, Arjun wants to induct a good SQA
so that the final product does not have bombs.
• You are the SQA for this ambitious and effort-starved project. What will
you do to minimize the damage and maximize success?
(15 minutes for discussion & preparation / 5 minutes for presentation)

42. Summary
• Facilitator is a major stakeholder
• Technical knowledge is an asset
• Never worry about escalation
• Meet more
• Command professional respect
• Success Indictors

43. Before Signing Off

44. Queries
The floor is yours…..!

45. Thank You