Archive for 2010/02/24
2010/02/24 1 comment
In a previous post, I discussed how it can be painful to learn that you were wrong. As a project manager, you probably don't like to learn that your assumptions proved wrong and that you need to make new plans. But sometimes it's painful to be right too. Software developers are often in this situation. They try to explain why something is harder than expected, the risks of a solution or how uncertain an estimate is. When they then are proven right, they often have to pay the price for making things right afterwards too. A not so sweet victory, if you don't take pleasure in proving others wrong, that is. The other day, I had one of these sour victories. I wish I hadn't been right. I've been discussing a project with a friend of mine and she was so optimistic about a new system which they were implementing but I saw some troublesome risks in the user interface. We discussed this very openly and she accepted that if the problems would be factual, the project would be in serious problems and a large investment would be lost. As she is a professional project manager, she decided not to hide the problems to her customer, and she invited me to her customer for an informal lunch. The customer was informed about the risks and was asked if he would accept a total failure if my opinion on the user interface was shared by the user. I guess this is not the most normal situation because the customer listened, reflected and said that he would take the chance of risking this large investment. It would be acceptable to give the solution and try and if it was rejected by the users, then that would mean the end of the solution and bye-bye to money spent. A couple of days ago, my friend called me. The system had now been in use for a couple of months and besides the draw-backs I had identified, the users had found even more and they are not willing to continue using the system. The customer, true to his word, has accepted this and will now go searching for another solution. He's not happy of course, but he knows he had the decision before things got really expensive and he's not shying away from responsibility. I've been reflecting on this these last few days. I really wanted to be proven wrong this time. The project manager and the customer is really great people. I cannot really point to a specific error in the process. They were agile during the development producing solid deliveries every two week sprint, the quality was good and the leadership was probably better than average. And still everything ended up a failure. The problems in the user interface was such that you might not spot them during a demo or just using the system for a couple of days. It was more the long term use which made the problems evident. I only spotted the risks by having worked with similar systems in the past and had seen these problems then. But there is a sort of happy end to the story and that is of course the next step. The customer is standing by his word. His users won't have to settle with a faulty solution and he's now using these findings in search of something better. A great leader takes responsibility and moves forward.