This document summarizes topics around quality management and control. It discusses code management challenges like spaghetti code and how to prevent it through coding guidelines, code reviews, and change tracking. It also covers defining a clear prioritization process to manage competing demands. The document proposes ways to control quality such as gating processes and testing. Finally, it shares two personal case studies, one about clarifying vague requirements for a telecom project and another analyzing user behavior data to assess ROI and guide business decisions.

1. QualityQuality
Management &Management &
ControlControl
July 2014July 2014
Maia ReshefMaia Reshef

2. AgendaAgenda
 Code Management and ControlCode Management and Control
 Quality Management and ControlQuality Management and Control
 Personal Case StudiesPersonal Case Studies

3. Code Management andCode Management and
ControlControl

4. The Spaghetti Code ProblemThe Spaghetti Code Problem
 Waste of valuable R&D timeWaste of valuable R&D time::
 Rewrite old code instead of maintenance to existingRewrite old code instead of maintenance to existing
code (veterans leave, new people arrive)code (veterans leave, new people arrive)
 High cost to migrate old code to newHigh cost to migrate old code to new
platform/languageplatform/language
 Changes to code may step over old fixes that wereChanges to code may step over old fixes that were
donedone

5. CausesCauses
 Thousands of code lines in logic not familiar toThousands of code lines in logic not familiar to
all developers or multi logic environmentall developers or multi logic environment
 Quick & dirty code areas which need to be re-Quick & dirty code areas which need to be re-
written to match best practicewritten to match best practice
 Missing unified comments format in the codeMissing unified comments format in the code
 Missing guidelines for code documentationMissing guidelines for code documentation

6. How to PreventHow to Prevent
 Define coding guidelines (comments, structure etc)Define coding guidelines (comments, structure etc)
 Code reviews by peer developers to verify the format isCode reviews by peer developers to verify the format is
clear to allclear to all
 Code reviews to verify the quality of the code writingCode reviews to verify the quality of the code writing
 Keeping historical records: keeping track of whichKeeping historical records: keeping track of which
changes were made, who made them, when they werechanges were made, who made them, when they were
made and whymade and why
 Private developer workspaces ("sandboxes“) – unit testPrivate developer workspaces ("sandboxes“) – unit test
before integrating code into the main code linebefore integrating code into the main code line
 Server back up mechanism to keep track on check in’sServer back up mechanism to keep track on check in’s

7. Quality Management andQuality Management and
ControlControl

8. Development wants to provideDevelopment wants to provide
the best product butthe best product but……
The blanket is too short: sales want to add to the code
feature xyz, customers complain on abc functionality,
previous product release contains 2 critical bugs not
known yet to sales/customers, CTO wants to move to
new UI and to launch a mobile app…
What do we do?

9. Define a Clear PrioritizationDefine a Clear Prioritization
ProcessProcess
 Verify we are on the same page regarding the prioritiesVerify we are on the same page regarding the priorities
 Set a clear plan for the next week/monthSet a clear plan for the next week/month
 Set a plan for the next buildSet a plan for the next build
 Verify each player in the team knows his tasks andVerify each player in the team knows his tasks and
handshakeshandshakes

10. Cost of Poor QualityCost of Poor Quality

11. Cost of QualityCost of Quality

12. Ways to Control QualityWays to Control Quality
 Manage process gating :Manage process gating :
sales/product-> development-> testing-> integration->sales/product-> development-> testing-> integration->
deployment/customer supportdeployment/customer support
 Status reports to stakeholdersStatus reports to stakeholders
 Manage release notes for every new release deliveryManage release notes for every new release delivery
 Perform lessons learned to prevent repetition of pastPerform lessons learned to prevent repetition of past
failuresfailures
 Testing beyond the “lamplight” – extreme values tests,Testing beyond the “lamplight” – extreme values tests,
regression tests, load tests etcregression tests, load tests etc
 Monitor customers’ KPIs to learn where to invest valuableMonitor customers’ KPIs to learn where to invest valuable
effortsefforts

13. Personal Case studiesPersonal Case studies

14. Case study 1:Case study 1:
TMO project requiremTMO project requirementsts
 Telecom Mobile EU (TMO) requirements were defined by the customerTelecom Mobile EU (TMO) requirements were defined by the customer
representatives and sent over to the division after contract signaturerepresentatives and sent over to the division after contract signature
(management strategic decision).(management strategic decision).
 Acting as project manager for the delivery to TMO I analyzed whichActing as project manager for the delivery to TMO I analyzed which
team will develop which requirement in order to meet deliveryteam will develop which requirement in order to meet delivery
commitment. Analysis reached dead end due to vague customercommitment. Analysis reached dead end due to vague customer
requirements.requirements.
 Clarifications from the customer revealed major gaps from the productClarifications from the customer revealed major gaps from the product
roadmap and from the project scope as was perceived by the divisionroadmap and from the project scope as was perceived by the division
managers.managers.
 Project was managed from day 1 under a major risk to delivery datesProject was managed from day 1 under a major risk to delivery dates
and contents, risks were surfaced to customer representatives in orderand contents, risks were surfaced to customer representatives in order
to enable the customer to update TMO relevant campaigns.to enable the customer to update TMO relevant campaigns.

15. Case study 2:Case study 2:
AU buyers and sellers behaviors analysisAU buyers and sellers behaviors analysis
 Australia (AU) catalogs were created during 2013Australia (AU) catalogs were created during 2013
Q1,Q2,Q3.Q1,Q2,Q3.
 I was acting as AU project manager for the AUI was acting as AU project manager for the AU
structured data deliveries.structured data deliveries.
 In order to asses the ROI on the effort I ran analysis onIn order to asses the ROI on the effort I ran analysis on
users’ behaviors using different parameters.users’ behaviors using different parameters.
 Analysis revealed different aspects unknown to usAnalysis revealed different aspects unknown to us
regarding the AU market hence directing the businessregarding the AU market hence directing the business
where to go next.where to go next.