There are plenty of books and quite a few blogs that focus on good leadership. They talk about what needs to be done and when, they discuss decision making, strategy, team building and collaboration. But what about bad leadership? It seems that when it comes to bad leadership, there is very little to be found.
However, over at Michael Krigsman‘s blog, Mike Kavis has a guest post on bad leaders. And while he is writing about IT project failures, there is still much for the aspiring, experienced and even bad leader to learn here (in fact, a failed project may be the single strongest learning experience of one’s career). Mike provides a ten point list of why large IT projects fail, but sums it up as follows:
This list boils down to three categories: technology, business, and people. You can probably count on one hand the number of folks that you’ve come across who excel in all three areas.
The challenge for leaders is not so much straddling these competencies — for sure, even the best leaders cannot master every leadership skill. And, anyway, there is no need — as long as our village is strong. As Mike points out, success lies in communicating vision, managing change and aligning the project (yes, it could be any project) with business outcomes. Not delivering in any one area is likely to see your overall project fail.
But if bad leadership boils down to these three elements, surely is makes it easy to be a good leader? Not so. We are measured mostly by our successes — and those successes generally take the form of projects, and projects only yield outcomes when teams work as teams. As Erika Andersen suggests, the minute that teams start to lose their focus on the problem and their role in the team, the alarm bells should start ringing. In these situations, it is the leader’s responsibility to come back to the three category areas driving the project — people, business and technology and rise to the challenge that they represent.
Nina Nets It Out: We can often learn our most valuable experiences by observing, or even living through, project failures. Understanding the role and dynamics of our teams as well as our personal skills and strengths can help ensure that our leadership contributes to a project’s success, and not its failure.
The organizational structure of project management needs to be looked at as well. Too often, the executive sponsor of the project is simply there as a person to deliver reports to on the project and not seeing the dynamics that drive a project to failure.
A project manager is too often a person who fills out all the paperwork to make sure the project is compliant with internal controls or external auditors.
And members of projects are often on 6-10 projects and they start balancing them for their own priorities.
As a result, it is easy for a project to fail, miss the budget or the timeline or all three.
Better to have designated people specifically accountable for technology, processes and people on the project and assign the right person to each. Collaborating that way would would maximize the strength of the team and not let something go south because the person in charge isn’t good at one of the three areas.
We’ve been implementing projects, especially software projects, for years and years. You’d think by now we’d have this down, but that’s not the case. I don’t know if this is the right answer, but the structure of project management, in spite of all of the PMI’s out there, is broken.
Hey Scott,
I couldn’t agree more. The structure is often overlooked yet plays such an important role as you suggest. It is somewhat like a baseball team. If each player plays their respective positions well, then the team functions better. Each has accountability for their area of the field and ‘owns’ what happens within that area. It is when one or more players feel as though they can roam around the field and not have any specific accountability when things break down completely. Thanks for your comment and for highlighting the oft-overlooked structural aspects of a project!
It’s easy to for management to blame project managers for failures. For example, complaining the budget wasn’t managed with a sharp enough pencil. While the PM may well be at fault, often the real failure lies with management itself.
On many projects, the time-budget-scope parameters are established by senior management before the PM is brought on board. When the PM complains, he or she is told to “just get it done.” One person I know calls this fact-free planning.
Thanks for focusing attention on these issues in your blog.
Hey Michael,
I could not agree more with you. “Fact-Free Planning” is a killer and likely a more frequent one than managers might like to admit! Your article on this topic is a worthy read and hence, I am placing a link here so other readers might benefit from it (and perhaps get a chuckle as well):
http://blogs.zdnet.com/projectfailures/?p=321
Thanks for sharing!!
Nina -
I especially love your phrase “as long as our village is strong.” Bad leaders, in my experience, often think they have to do everything themselves — and since that’s generally impossible, they fail spectacularly. In contrast, good leaders build teams whose members have a variety of complementary strengths, and they consistently elicit and rely upon those strengths.
I love that you put the link to that funny youtube video in your post…it’s such a great failure-of-leadership story!
Warmly,
Erika
Hi Erika,
))
Thanks as always for your comments and insights! Long ago, I learned that I can be mediocre at many things or be really good at some and find others who can be really good at complementary tasks. Just seems all too logical to follow the latter approach! After all, I find doing this way grows “great employees”!!