There is nothing worse than a good project gone bad. How do you identify them and what do you do? Here’s what I say . . .
Bad projects occur when a project team fails to apply the Six Sigma methodology to reach the answer but instead jumps to an unanalyzed conclusion. These projects can be identified because the action recommended does not have a link to data analysis. How does this happen? Sometimes it is due to having an overzealous team that think they know the answer and want to hurry up and solve the problem. In this case, bringing the team back to the data analysis usually gets them going in the right direction.
The tougher issue is when this action is pre-meditated. This is when a Project Champion (PC) or Black Belt (BB) uses the Six Sigma forum to accomplish a specific task that they want to get done. Portraying the task as a Six Sigma project implementation recommendation may be the only way to sell their idea. Addressing this issue is a difficult task. You must keep asking the PC, the BB and the team, “How does this solution link to the data analysis?” Focus on the PC. If the PC refuses to acknowledge the issue it means that he or she is the issue. If the project is too far down the road, you may not be able to save it. But keep a sharp eye on the situation and you may be able to halt the next project before it starts going bad.
Good projects gone bad can ‘spoil’ any deployment. If given the choice, no project is better than a bad one.