If you fail at something, and the cause was not lack of effort, then the cause was most likely a lack of issue management.
I’m not certain who first said this. It wasn’t me; I picked this saying up in a meeting a few weeks back, and it rung so true I wrote it down and wanted to share it here.
Almost all of my career, including the non-IT parts of my career, has been project-based. No matter what my primary job, I have always been either managing or participating in one, two, or sometimes even dozens of projects. Some of them have failed. Perhaps not on paper; often when we failed, we actually met the goals of the project, but then the project itself didn’t accomplish something of value, so the ‘successful’ project was actually a loss to the company. In retrospect, I cannot think of a single project that failed where the team did not know in their hearts it was going to fail well before the actual failure happened. Almost always, it was a matter of discussion. We knew we were doing the wrong thing.
The reasons varied. Sometimes during discovery and requirements analysis we realized the project wasn’t going to accomplish the desired goal. Sometimes we found out the customer’s business model was different than expected, and the project wasn’t going to deliver something the customer truly needed. Whenever the problem was technical, we invariably found a way to overcome it. The common theme in the failures has always seemed to tie back to something we learned later in the project revealed that the original premise of the project was wrong.
So if we knew, as a team, why did we do them? Why did we waste our time and the company’s money?
We did it, almost every time, for one of a few reasons:
- There was no clear individual sponsor who could stop the train
- There was no specific individual on the team who could pull the information together, had access to the necessary audience, and could present the issues in a way that could be understood by executive leadership
- The problem was complex enough that it required a greater depth of listening and understanding than leadership was willing to give
- Leadership stuck to its guns regardless of the information presented to them
Do you note the common theme here? It all traces back to leadership- a lack of it, a lack of its willingness to listen, or a lack of ability to communicate with leadership.
You almost always get to where you are as a leader in a company by making good decisions. You act on the information you have and are right more often than not. You trust your instincts and what you know, and you make good decisions based on it.
This is usually one of the main problems once you are a leader.
The team that is executing your projects is usually better informed on the details of the project than you are as a project sponsor. The high-level reports you receive as the project goes on is only a sliver of the full project detail. As project sponsor, you most likely back this project because based on what you know about it and what your instincts say about it. You back it because the horse that brought you this far says the project is a winner. If a member of your team comes to you and tells you the project is going to fail, your first reaction is obvious- order everyone to dig in and save it.
The problem here is:
- Your instincts and skill brought you this far, but at some point your project team will know more details than you do.
- If you chose well, your project team is a group of sharp people that you trust. If they say that the project is in trouble, your real instinct should be to listen, not to defend the project.
- You may be the boss, but you are not a delicate snowflake of unique skills here. Its very possible that out of the whole team, at least one person is every bit as skilled as you are. And that person has more information. You should listen.
