We Learn from What We Screw Up
Posted by Brad EgelandThe title basically says it all. We go to school, we go to training classes, we join associations, we read books. We do everything good little IT and business people should do to better ourselves in our profession. And, at the end of the day, we’ve learned some things that help us in our jobs.
But what do we really learn the most from? Growing up, did you learn more from what you were told to do or did you learn more from what you did wrong and had to pay the consequences for? I contend that the latter wins hands-down. It’s nice to learn things…it always is. But when we screw up really good and pay some sort of price for it…I contend that those are the times that we really really LEARN.
Example #1
Case in point…. I’ve mentioned many times how budgeting issues can torpedo projects and I’ve had at least one major project of mine go south due to budget handling issues. I’ve passed blame somewhat, but overall I’m the Project Manager and that’s my responsibility. That which does not kill us makes us stronger, right? I firmly believe that. And that which does not get us fired makes us a better employee, a better server of our customer, a better business professional.
One major project completely shutdown for budget issues that could have been avoided – or least the blow could have been softened – with the appropriate action. I learned from that mistake and budget information is key to weekly discussions and project status reports that I have with and share with the customer now. It’s formally documented – both current budget and forecasted budget – and discussed formally every week. I’ve taken away the question marks and made it a joint effort with the customer. And believe me, the customer always appreciates the knowledge and would rather know the bad things and work through them with you then to waste money and cancel an engagement. I’m certain of that.
Example #2
I also worked on a major $50 million program for the US Department of Education. It was much more of a program than a project – it had a five-year run followed by an RFP process and our proposal and another contract win. The company I worked for always won it because the program had grown to such a large size, it was so complex and had so many add-ons that no potential bidder could knock us – the incumbent – out of contention for the next proposal. We had become fat and overconfident.
Then one day a funny thing happened. We missed a major milestone deliverable. Then we missed another. Then we improperly tested a change order resulting in delays and re-work. Suddenly, the government was not so enamored with our performance and certainly had lost confidence in our ability to deliver. We desperately needed to learn from this mistake, act aggressively and right the ship before it was too late – because at this point the project was within one year of coming up for re-bid.
I had responsibility on this program for all financials and budgeting, all change management, all change orders, disaster recovery, and status reporting. Production was not in my scope, but I pulled my direct reports together and we resurrected the project schedule that I had put together 3 years prior in order to win the current contract and we updated it to what was happening today. What my team and I turned out was a project schedule encompassing nearly 4,000 tasks and a my peer managers on the program were ready, willing and equipped to manage their specific portions of this mammoth project schedule.
My responsibility was to bring that all together and take over leading the weekly status meetings with the government managing everything to that schedule and producing meaningful alert reports from it both for internal purposes and for the customer to hold us accountable to. What resulted was a project that quickly got back on track, a customer whose satisfaction was raised beyond the level it had been previously and another huge contract win down the road. It wasn’t my doing – my entire team and I took the initial action – but everyone pulled together and made it work. We learned from our overconfidence and mistakes before it was too late. And in this case too late could have meant losing our jobs in a year if the contract was lost.
Summary
We’re human…we’re told what to do from the time we’re born till the time we die from someone or another. It doesn’t matter if we’re John Doe or Donald Trump…someone somewhere is instructing us off and on. We learn from those instructions. But I believe we also learn very fast – maybe faster – when we screw up and suffer the consequences. Sometimes we have to fail to perform better.
Related posts:
Nick Milton says:
Yes, up to a point you are right Brad, especially when speaking about human nature, but corporately, or as a society, we make the biggest learning steps when we finally succeed.
Think of Edison and his light filament; when did he do the most learning? When he tried each of the 99 options that didn’t work, or when he found the one that did? Now you can argue that he learned from both, but now lets look at transferring that knowledge. Tell me, if you were a light bulb maker, which of these two statements would be of most value to you?
1. You can’t make a light bulb filament out of cat hair
2. You can make a light bulb filament out of tungsten
It’s Edison’s success you learn the most from.
Now lets look at KM in an organisation, and how an organisation learns. The ideal for an organisation is that it learns from the *minimum of mistakes*. We don’t want to be at the mercy of human nature. We don’t want people to have to screw up in order to learn. We don’t want mistakes and screw ups if we can possibly avoid it, because mistakes and screwups can cost money, they can cost lives (in certain cases), and they can cost careers if they are big enough. I know that people find a mistake a powerful learning experience, but KM in organisations must aim at countering this, and giving people access to learning from other’s mistakes. (In fact it is notable that where mistakes are most serious, as in the Military, the greatest attention is given to systematic learning and KM)
In a way that is what both of your examples point to. You don’t want anyone else to repeat those mitakes you made, surely? That’s why you shared with us your solutions to avoid those mistakes in future. And I bet your personal learning in terms of how you behave now is based on the successful solutions you implemented as a result. So if you were a project manager, which of these two sentences is of most value in helping you succeed?
1. “budgeting issues can torpedo projects”
2. “budgeting issues can torpedo projects, so you need to formally document both current budget and forecasted budget – and discuss them formally with the client every week”
It’s the learning from the success that gives people the ability to avoid the screw-ups.
Brad Egeland says:
Nick- You are correct. I only covered one angle. We definitely learn from our success as well. I believe we learn alot more from both our successes and our failures than we do from any teachings we receive. Sounds like the success angle should be the basis for another article. I think we learn equally from both – but unless we are individuals who fail more than we succeed – which I hope is never the case – then we likely in the long run learn more from our successes than our failures.
Thanks for the comment.
John Caddell says:
Brad – thanks for sharing these very useful mistake stories. These would be a great pair of stories for the Mistake Bank… I wonder if you might give permission for me to repost them there. Or, if you’d prefer, you can join and post them yourself, in which case they’d be tied directly to you. Please let me know.
regards, John
Four Key Areas Where a Business Consultant Can Save Your Organization | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:
[...] is not always a bad thing because we can learn a lot from our mistakes. See my article on “We Learn from What We Screw Up.” But we don’t really want to start by experiencing failure with our first high-visibility [...]