Zero Defect Client Satisfaction: Software Development Success is a Team Sport

Zero Defect Client Satisfaction: Software Development Success is a Team Sport

There is no silver bullet to successful software delivery, no one person or team, but to get zero defects, you must do ALL of the following with excellence using multiple teams.

1. Engage senior business management monthly 
2. Engage business users daily 
3. Discernment with business users and developers to clarify the requirements for on-demand
4. Reasonable estimate range for business effective dates and system delivery dates
5. Pay for premium software and hardware support. Obstacles will arise, and you will need vendor support based on your chosen technologies.
6. Design for User Experience and UX. This is the only contact point the user has with the system. They will never see the engineering design principles.
7. Design engineering principles to adhere to a flexible design that permits speed in business development and operational performance.
8. Set up testing data “Lead vs. Gold” and test case coverage of both business and code, supported by automation tools and knowledgeable QAs.
9. Automate Performance testing for scalability and memory leaks.
10. Beta testing by the friends and family of the business for critical pre-production feedback.
11. Communicate Risk, quickly hot fix issues with proper Software Configuration Management (SCM), and do the necessary user training.
12. Document Feedback and pending Issues back for a GO/No GO decision
13. Do a Well-executed implementation, cutover, and validation plan
14. Timely production triage, superior defect capture, and hotfix management will keep clients happy and show you are in control of the software.

There are two significant teams the Business team and the Technical Development team. Both must be equally engaged and accountable for the desirable outcome. The best teams know both the application and the technology for the domain.

Aggressive calculated risk is part of a successful strategy on the business and technical sides. There must be a keen understanding of the current and future strategy gap and time and ability to convey it to all team members.

Good decision-makers are critical to overcoming obstacles on both the business and technical sides. Good decisions will require a mastery of the details. Technical sub-teams of User Design, web services, Business Services, reporting tools, data integration, and Data architecture of both transactional and reporting will need Subject Matter Experts (SMEs)/ team leads.

Including two horizontal services, user design and QA testing, are instrumental in project success. It is essential to have SMEs in both domains and automated tools to expedite success. Technical leads with solid domain expertise compensate for mediocre business requirements.

Control over complexity and standardizing complexity measuring across substream will allow comparsions in development and draw correlations. Value changes are simple while structural changes drives complexity.

Business or data changes can force structural changes. Here are a few circumstances to consider:

1. New data is added via a new data feed or an expanded existing feed.
2. Storage changes by adding new tables or enriching the existing ones for new or derived data.
3. Business rules or calculation changes in the current business service or new components added.
4. Application functionality to select, filter, or sort the display data and the UI at run time.

Value changes are data value changes without code changes like global constants, config initialized, or application maps that store key-value pairs like tier values.

Software metrics are semantics for software measures. The measure is the only scientific way to prove software quality. The software can be scientifically measured by setting goals and tracking continuous quantitative improvement.

Key Performance Indicators (KPIs) of software development

1. Overall productivity (size in FP/ effort)
2. Schedule deviation % – how many standard deviations are you from the communicated deadline? Ideally, you want to be within 10% or, better yet, one standard deviation.
3. Effort Distribution %
   1. Design
   2. Construction
   3. Testing
   4. PM
   5. SCM
   6. QM
   7. Organizational
4. Effort deviation % – you may hit the scheduled business delivery date, notwithstanding working weekends and late nights for containment of the schedule and depleting team health.
5. Process compliance – if you want to go fast, you must go well. Skipping steps will impact quality and introduce more defects.
6. Defect Density (% defects per development phase)
7. % defects – this must be measured at dev, UAT, and prod to see how hard and soft factors impact delivery.
8. Rework effort – % of total effort. Rework is the cost of poor quality.

Soft factors are hard to quantify but correlate to successful outcomes. Soft factors are also leading indicators of KPIs. Soft influencing factors of productivity, quality, and schedule are as follows:

1. Hardware and software environment, these choices impact the developer’s productivity e.g., Stored procs are faster than SPARK for development.
2. The complexity of code and the volume of complex code
3. Experience of the developer team
4. Size of the project
5. Impact of automation
6. Impact of hardware speed
7. Speed of software deployment
8. Customer-imposed constraints like a hard delivery date without fixed requirements
9. Inaccurate sizing and estimation
10. Unplanned activities
11. Inadequate training
12. infrastructure delays for hardware or data context setup for software
13. Delay in resource allocation
14. Attrition 

The bulk of work lies in the design, construction, and testing phases but the PM bulk (Software Config Management (SCM), Project Tracking, Quality Management, Organization Activities) varies by project size ie minor enhancements vs major build.

1. The initial estimate should be as precise as possible to prevent doing a re-estimate later.
2. I am locking scope changes as much as possible and preventing last-minute changes.
3. Utilize experienced resources with business domain knowledge, not junior resources. Expect gaps if not peer-reviewed by senior members of the business and technical sides.
4. Get training as needed
5. do cross-pipeline interface design to agree on handshake protocols.
6. Peer review often by git Pull Requests code reviews
7. Defect detection and removal by team reviews
8. Get actual testing data from business analysts to reduce false assumptions.
9. Employ automated testing tools and lead vs. gold comparisons using different tables, code bases, and reporting tools.
10. Frequent show and tell to certify the product is aligned with customer expectations.
11. Organizational activities like CDP upgrades should be escalated and facilitated ASAP by the timeline.
12. Know your lead times for each origin phase for the organization’s partners to get approvals.
13. At cutover, use lead vs. gold with the original system for validation. Run both in parallel.
14. Strong UAT and production triage, capturing metrics for private defects in Dev and UAT and public defects from production
15. Closure Metrics with Root Cause Analysis (RCA) by category and create preventative steps.

Release Stability and Deployment Master Checklist