Dave Howard reviewed some defect stats for a platform implementation just weeks away from go live and found that only 25% of the defects raised were real. Think about how much effort is being wasted in raising, investigating and closing these…
50% were caused by a combination of configuration, data, integration and environment issues and 25% were caused by testers not knowing how the platform worked and the outcomes they should have expected from the tests. In a mature and well-managed environment, we would expect 75% of defects raised to be functional and needing a fix to the code base. So what accounts for such a large gap?
At face value, you could be forgiven for pointing the finger at the testers and the folks that manage the environments, configure and deploy the code. You would be right in thinking that these guys need to raise their game, but I think the real root cause is a more subtle and uncomfortable truth:
- Platform suppliers are geared up to implementing a platform and not delivering business benefits for their clients.
- Clients aren’t aware of the extent of their role and the need to own the solution from proposition through to traceable requirements to acceptance into production.
The combination of these two factors means that it is inevitable that the wheels are going to be coming off in testing and the relationship between supplier and client is going to become strained at best. Both have good arguments; suppliers will point to the lack of detailed requirements and the ineptitude of the testing (back to phantom defects).
Clients will retaliate by reminding the suppliers of their pitch when they won the business about how easy it is to implement a platform ‘out of the box’ and the lack of small print about the clients’ responsibilities. These positions can rapidly snowball at a point when client and supplier collaboration is most critical – just prior to go live. So what to do? The bad news is that testing often exposes upstream limitations and by the time you hit test it’s too late to do anything other than regroup and reset delivery expectations. This is lead balloon territory and it’s not surprising that effort is deflected into hunting and punishing scapegoats. Going live will be gutsy and there will be precious few shortcuts. However points 1 and 2 above can be avoided by introducing an on-boarding stage of the implementation lifecycle to help clients:
- Understand their chosen platform and what is easy to deliver via configuration vs what’s hard and requires new development
- Understand their role, the importance of solution ownership and to have traceability of requirements from proposition through detailed test cases and expected results. Own it!
Successful platform delivery requires a few basic disciplines to be in place. Agile development is all about building solid foundations, then going quickly – not rushing into things before you have your foundations defined, the proposition linked to the solution architecture. Clients should take control from the outset by developing a clear on-boarding strategy so that they are in a position to behave as an ‘intelligent client’ and help the supplier deliver the required business outcomes.