In the many organizations and projects I have been through, I always hear someone saying these words, “We must have more accountability around here.” But, in reality what they ‘really’ mean is, “I want to know whom to blame when something goes wrong”. We assume that by early identification of a scapegoat you have put the fear of blame in you or at least the fear of consequences related to that blame and further assume that fear is an effective motivator.
As a project manager that works solely on IT projects, I find that the scare tactic is not particularly a potent motivator for the IT resources I work alongside with. My IT colleagues have always had the need to apply their creativity in resolving every problem that has come their way and the blame-game prevents creative people from doing what they do best.
On a web project I worked on recently, the primary developer approached me with some bad news. He told me he had been maintaining the source code to the project on his work laptop instead of the server and that while walking home he dropped his laptop thereby destroying it and losing all the work he had done on my project. There were several mistakes done here and I could have instantly started the blame-game as I had a ready scapegoat in front of me, but this would have not accomplished much for me or for the greater good of the project.
I told the developer that I would talk to the project sponsor on the consequences of the lost source code if he would do what it took to recreate the code in a week. If this was not accomplished then he would not be the buffer between the developer and the sponsor.
The developer came back in 2 days to let me know he was able to recover part of the source code off his damaged laptop and was able to rewrite the rest. “Excellent!” I said. I asked the developer for 2 more things, call the client and give them the good news and tell them they will not be charged for the lost time. The developer was surprised that it didn’t go towards his review and when asked, I informed him that I only make an issue out of it if a mistake is repeated.
In this case, the developer made good on his promise by delivering the project and was able to make a lasting relationship with the client. After that point, we never spoke about this issue and the developer was free to make new and better mistakes.
For me, events like this help me in strengthening my belief that identifying that whipping boy is not conducive for building a creating, productive and learning team.
Like our Project Management Blogs? Connect with Amit for more helpful insight on managing projects and becoming a successful leader by emailing sales@ktlsolutions.com or calling 301.360.0001.
Amit Trasi | Project Manager
Amit is responsible for institutionalizing project management governance at KTL to streamline ERP implementations. With over 15 years of technology experience as a software developer, project manager, and program manager, Amit has managed end-to-end ERP implementations with Dynamics NAV and GP as well as POS implementation with e-Commerce front end. He holds extensive experience deploying POS and ERP applications at non-profits, theme parks, and museums across the United States. Amit joined KTL in October of 2013 and holds an MBA in Information Systems as well as holding a Project Management Professional certificate.
