You may have a problem at hand if the team, for some reason, was unable to maintain technical excellence while working on a legacy application. And the problem is that there are so many defects but there’s so little time to discuss. Take the status-reporting problem, for instance. By using defect tracking tools, the defect trends could be reported: number open last week, number closed and remaining.
Managers are expecting to know the true impact of the defects when they inquire about defect status. They want to know:
- Will the customers’ perception of the product be affected by the problem to the extent that they will consider not buying or recommending it?
- Will our ability to gain revenue be affected?
- Will our ability to attract or retain customers be affected?
If you’re capable of addressing these problems properly, it should take no more than 10 minutes to provide a reasonable status.
Here’s how this might work in three scenarios:
Scenario 1
With hundreds of inconsistent-looking screens, typos, and general sloppiness, you’re thinking that the team should fix all these using defect tracking tools and it might even take a few weeks to do so. What do you do?
Tell your team that with none of your x number of problems is a real issue itself unless combined will all other. It makes customers concerned about the inconsistent look and feel. Maybe, it can be lived with. But will it stop customers from being reference accounts or looking for another alternative? Maybe not.
Scenario 2
You have two serious problems, both of which occur rarely. Upon occurrence, customers could end up losing all their data. You’re thinking that you shouldn’t let customers get their hands on the product, even if the chances of occurrence are rare. What should you do?
Tell your team that apart from several small problems you’re facing, there are two major ones. Instruct them to shift their focus on these problems and make them aware of the criticality of the problem and how it can affect customers. And if it affects the customers, they may tell other people about your problems.
Scenario 3
When transitioning to Agile, you might think that during that time, you haven’t tested enough since there wasn’t enough test automation, even though the team marks everything as “done”. What should you do?
Tell your team about the existence of unknown risks in areas you have insufficient test automation. Acknowledge that although the features are marked as done, the picture is still unclear. Recommend releasing it as a beta release, spending the next couple of weeks on the backlog of test automation, and build time reduction to quickly increase clarity. That way, you won’t have a problem with customer retention or acquisition. You won’t have to worry about the potential customer problems with data loss and therefore losing the customer.
Conclusion
In the above scenarios, you’ve done your job of explaining the impact of problems. Leave it to your managers to decide what to do.
If you want people to be influenced by you, which is what you’re essentially doing with a project report, focus on how the problem affects them. Offer different possibilities and discuss them in detail.
