What do you do if you find a defect at the 11th hour, just before go-live?
Someone on a #Salesforce Project asked me this question which I answered in my newsletter (It’s awesome – sign up below! 👇🏻… she says without a hint of modesty 😁)
Last minute bugs sometimes happen, but the probability is usually minimised with good project and test management.
Unfortunately, testing is one of those areas that most people skimp on, either by cutting down the number of resources or the time. 🙁
“Project Pain Principle”© (coined by me – you heard it here first) postulates that any potential problems not perceived earlier will be ex-ponentially painful – in every way. 😁
Projects should be tightly managed – with risks flagged and logged and monitored so that they don’t become issues. Things get messier and more painful if that happens.
Much like a child ignoring a parent and skateboarding without safety equipment. There is a risk of a fall and injury, but until that happens – it remains a risk.
If the child continues to ignore said parent (as they are wont to do), and falls – the risk has materialised into a screaming wailing bawling pile of ‘issue’.
This problem has now become bigger.
Projects are the same – risks and potential problems need to be dealt with as soon as they crop up.
So, back to the question.
If the resolution (inclusive of fix, unit & regression test and deployment) for that 11th hour defect is small and low risk – it may be an option to try and do it then and there with the agreement of the customer.
Otherwise, it may be more wise to delay go-live and assess the situation properly.
I must say that the “Project Pain Principle”© – coined by ‘Pei’ 🤭 has never steered me wrong. It’s like gravity and other natural law of things. It just is.
🚩 that are not addressed as soon as they are identified, promises a world of PAIN.
#OnThePeiroll
#ProjectManagement
#DontSkimpOnQA
#ProjectPainPrinciple <– I’m going to © this hashtag too if that’s at all possible
