Don’t ever let it happen to your software development story!!

Don’t ever let it happen to your software development story!!

Shipping on Schedule is a priority and one who works the most, gets a pay raise!! In the rat race and incentives to quickly develop, Quality takes a second seat.. Only goal is to be able to ship it before time!!

Testing Team had asked for 5 days, as one of their Team Members was on MEDICAL Leave... The Project Manager gave them only 3 days because on an urgent need to ship out the product, before deadline. Result – was a chaotic, pressure filled weekend for the Testing Team in office, with only Monday left to give Test reports to Project Manager. The Team Member who was on leave was asked to join on Weekend but his mind was not there as he was very weak, and he again went on leave. Tests showed 120 defects... but the figure was shot down by Project Manager as he said they will work only on the major defects which were 35. 

The Product was finally delivered to customer, and during the functional Testing only he found 36 defects on day 1. This raised his curiosity as payment had been made to developer and he spent the next day doing more functional testing and found another 70. So the total defects he found were 106. He spoke to the Project Manager and gave him feedback and Project Manager said, wait, we are working on all those defects... Little did he realise that customer was doing testing which his Testing team should have done... Obviously, customer was not willing to listen and gave him 2 days to remove all defects. Project Manager discussed with his Team and management and they worked out a testing project on war footing... but it was only a Fix and not a solution, and they cancelled everyone’s leave, asked them to put in 15-16 hours of work every day, be present on weekend and eventually shipped out the “corrected” delivery to customer in 4 days (instead of 2 days) , mentioning problems of resources at their end .

And when it was retested again, by this time the customer had become aware that there is something fishy, the rotten smell of which was seen again, 2 of his requirements which were mentioned and logged in his email sent at time of Requirements were not even captured or functionally available . The customer blew his top, ordered a cancellation, and today the vendor is fighting in court on not refunding the amount received by them. The PM is in trouble for whatever happened, after all, it was his decision!!

This is where Quality counts... a few nuggets on prevention of such experiences in your workplace:

1.      Involve the important stakeholders in the requirements phase

2.      Have a QA team, listen to them and don’t put undue pressures on them... they are after all, working for the product and your success

3.      Involve QA team along with Functional Teams (involve experts from other groups also) In reviews at every stage... Never compromise on their feedbacks – early defects can go a long way in improving the overall health of the product. Don’t panic, every hour spent like this will save at least 10 hours later in doing re-works and re-developments, re-testing.

4.      Never ignore requirements which may have been explicit or implicit – such as the one in customers email but nowhere in Project Managers list of requirements

5.      Don’t start coding until the requirements are stable and understood or else budget time for rework.

6.      Don’t compromise on Testing, whether it is Unit, Functional, or Integrated testing, you must know that there is a customer who will repeat everything and he is not going to go by your excuses

7.      Estimation should always include Testing … preparation of test cases and doing testing, at every stage involve and incorporate suggestions by Testing Team

Lessons learnt

·         Explain to management that delivering “on time” is not the same as delivering to “customer satisfaction”

·         Include “Customer acceptance criteria” as a part of SRS itself

·         Shortcuts in scheduling actually reduce the time for Testing and Requirements gathering and discussions with stake holders... this works out to the opposite, i.e., increasing the time to deliver , unsatisfied customer and an unsatisfied, tired team which affects the productivity

·         An independent consultant can help in such scenarios.

This article is written by Mr. Anil Oberai, C.E.O of OberaiITConsultancy, with more than 2 decades of experience in managing and Consulting for IT Projects. Information Security is one of his pillars for consulting. To know more, Pl visit http://aniloberai.branded.me/ Read his blogs on https://oberaiitconsultancy.blogspot.in/