At the heart of the matter was one word – QUALITY (or Kvalitet in Sweden). “Your software isn’t good enough” was the assertion from the customer. “You’re being unreasonable” was the retort from the vendor. “You are our last chance” was the message we received from the customer’s CEO. “You”, being a small specialist (SWOT) team comprising, a Senior Project Manager, a Systems Architect, a Technical Project Lead, a Senior Business Analyst and a Senior Testing Consultant. This is not an unfamiliar scenario for those of us who have seen the software landscape change from bespoke to prêt-à-porter solutions during the past 15 to 20 years. It is also not an unfamiliar outcome for lawyers to get rich in these situations and for the customer to lose credibility in the marketplace.
In May 2009 I was asked to assist with a Transport Ticketing project that had been struggling to Go Live for the previous 2 years (the overall project lifespan was 7 years). The solution was 98% ready - just 360 requirements of the original 16,000 required sign-off. This had been the situation for over 12 months, with no agreed end in sight. How could they be so close and yet so far away? How we achieved (what appeared impossible just seven short months earlier) is the story I will tell at EuroSTAR 2011. How we turned “your software isn’t good enough” into “we’re going live next Saturday” will never be a Nordic legend, but it will be remembered as the project that saved a software vendor from bankruptcy and another major city from a multi-million dollar failure.
At the centre of this story is how we re-focused everyone on QUALITY/KVALITET. What’s essential, what’s negotiable, what’s unacceptable? These questions were central to our success. Our team didn’t identify any new requirements or write any new software. We just analysed the available data, spoke to the right people, re-worked the Test Strategy and agreed on a new GO LIVE strategy with an agreed date – and then MADE IT HAPPEN.
An interesting Footnote from this Case Study is that the Customer hired/payed us (and expected us to deliver) – so we got little in the way of recognition. The vendor was over the moon, as we had saved them from an expensive lawsuit and (almost certain) bankruptcy. The vendor still calls us. The customer experienced NO significant outages – KVALITET!!
ONLY the current Production Code Base is used for SATONLY functionality relating to the current Implementation Step scope will be used as a basis for SAT If a Bug is detected using an earlier (or later) version of software than is currently in Production, it must be proven to exist within the Production version also, otherwise it will remain as an ObservationThe client will ONLY advise the Vendor of Bugs that must be fixed for the current Implementation Step; these Bugs will be categorised as either Critical(SAT is suspended due to this specific failure) or Major (unacceptable for customers or internal business operations once the )Bugs categorised as Minor will result in a (short to medium term) workaround within the client & will ONLY be sent to the Vendor if no Critical or Major defects are outstanding; otherwise they will be sent to the Vendor after the Code Freeze has been implementedBugs categorised as Trivial will be sent to the Vendor after the Code Freeze has been implementedAll Bugs begin life as Observations & are only categorised as Bugs once they have been replicated, prioritised & assessed via the Daily Defect Triage MeetingAll Bugs must be associated directly with a Test CaseAll Critical Bugs require a Patch to be scheduled within 24 hoursAll Major Bugs require a Patch to be scheduled within 3 working days (unless otherwise agreed by the client)
Current Production Code Base used as basis for SATONLY functionality relating to the current Implementation Step scope will be used as a basis for SAT If a Bug is detected using an earlier (or later) version of software than is currently in Production, it must be proven to exist within the Production version also, otherwise it will remain as an ObservationIf a Bug is identified by the Vendor, on a version of software other than that currently in use by the client, it will only be of interest to the client if it is proven to exist in the Code Base currently in use by SAT The client will ONLY advise the Vendor of Bugs that must be fixed for the current Implementation Step; these Bugs will be categorised as either Critical(SAT is suspended due to this specific failure) or Major (unacceptable for customers or internal business operations once the )Bugs categorised as Minor will result in a (short to medium term) workaround within the client & will ONLY be sent to the Vendor if no Critical or Major defects are outstanding; otherwise they will be sent to the Vendor after the Code Freeze has been implementedBugs categorised as Trivial will be sent to the Vendor after the Code Freeze has been implementedAll Bugs begin life as Observations & are only categorised as Bugs once they have been replicated, prioritised & assessed via the Daily Defect Triage MeetingAll Bugs must be associated directly with a SAT Test CaseAll Patches will be installed in the Acceptance Environment firstAll Patches rejected by the client will be removed from the Acceptance Environment before the next business day in StockholmAll rejected Patches will be escalated to the client’s Program Management team due to the delay to SAT & need for re-workAll Patches will be accumulated by the Vendor to create a Release that will be delivered to the client 2 weeks prior to the Code FreezeThe Vendor will conduct a Regression Test on the Accumulated Release prior to making it available to the client; The client will then conduct a Regression Test as the final SAT activity prior to Approving the Release for Production