I had the pleasure of speaking with two different colleagues today, both with the same dilemma. They are near the end of their projects. They don’t quite have enough time for one round of final testing–but if they’re lucky and the stars align, and they don’t find too many problems, they can still (maybe) test what they need to test before the desired release date.
But no, the stars don’t align. First week into testing, they find a nuisance of a defect. It only occurs once–in installation, and they can work around this with release notes–but they’re under pressure to make the change. They each asked me what I would do.
After asking a few questions to make sure the problem only occurs when installing, and they can make big red stickers to explain to the customers what to do, I agreed with the PMs: don’t make the change.
The risk is just too high. The reason the projects don’t quite have enough time for testing is that they’ve encountered trouble all the way through the projects. The builds take too long. The developers didn’t integrate testing as they developed. They implemented by architecture, and couldn’t manage the changes in requirements, so the architecture doesn’t quite fit what the customers want–but they shoehorned the features in anyway. The project team hasn’t met one deadline yet.
If you’re in this position with your project team, ask yourself and the team this question: What did you see or hear that leads you to believe this would work?
If the someone has data, “Oh, we fixed the build and we can tell in 10 minutes if the build is any good,” maybe you can agree with the decision to make the change.
But if all you hear is gut feelings, say no. Murphy is one of your team members. Finish this project. Hold a retrospective. Work differently on the next one. But don’t make that one small change. It won’t be small. It probably won’t work, and you won’t know until the customers receive the product. The risk is too great.
Labels: project management, risk