"But It's Just a Small Change"


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

2 Replies to “"But It's Just a Small Change"”

  1. Common situation many PMs face. Our challenge (as PMs) is to try and convince the overly-optimistic development leads and architects that they WILL face these issues when they reject Murphy and rely on their own technical prowess alone. How can PMs predict this future and motivate preventative action early?

  2. For me, an installation bug is a “first impression” problem and that might make it a show stopper.
    With Ultraseek, effortless installation was a core feature and part of the free trial and sales process. Of course, there are always bugs that get “release noted”. I think it is important to be honest with your customers about when you know something doesn’t work. Write it down, ship it, and fix it fast.
    No product is perfect, but you can choose to have a more or less broken relationship with your customers by how up-front you are about bugs.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.