Failures of Project Leadership

I’m fascinated by project failure.

First, I believe we learn more from our failures than our successes. Success usually has an element of chance, of circumstances cohering… or at least not pulling out the rug. Yet in looking back (e.g., at after-action reviews/project debriefs), we rarely recognize the extent to which what-didn’t-happen played a part in our success.

Second, failure stories are often mesmerizing, especially big failures. They frequently read like thrillers, with plot twist after plot twist conspiring against the heroic project manager. Actually, at least half of them read more like lampoons, with the project manager anything but heroic. Either way, entertaining.

I’ve been working on and off towards a book called Pass the Blame! And 99 Other Ways to Screw Up Your Projects (and debating whether I dare replace “screw up” with something stronger). Let’s draw some lessons by excerpting a few of its short (two-page) chapters, starting with the opening section on project leadership.

1. Fail to Recognize It’s a Project

The easiest way I know to screw up a project is simply to not recognize it as such. “Oh, this is simple – I can just dive in.” I’ve analyzed too many cases where lawyers did just that on multi-million-dollar matters.

Of course, sometimes the client dumps an emergency on you, and you have to do something today. That’s fine, but tomorrow morning, stop and consider the larger picture – and recognize the project within it.

A “project” meets each of the following criteria:

  1. It has a start.
  2. It has an end.
  3. There’s “stuff” (multiple steps or tasks) in between.

Copying a document, to take a trivial example, is not a project. There’s the first page and the last page, but the “stuff in between” is more of the same, with little ambiguity.

Likewise, responding to your inbox is a process, not a project. There’s lots of “stuff in between,” of course, each email, and each required response, being distinct. However, there is no start and for sure no end. Advising the client isn’t a project, for the same reason, although you need to be aware when “a bit of research and I’ll get back to you” turns into a project (think “multiple steps or tasks”).

Here’s a rough but useful rule of thumb:

  • Takes more than six hours
  • Involves multiple people for the “stuff in between”
  • Has three or more distinct tasks or parts, especially if the tasks can overlap

If whatever you’re working on meets two of these three criteria, it’s a project.

Treat it as such. Do some planning. Figure out what depends on what, and on whom. Be sure you know the client’s goal, and the budget, and what “Done” looks like.

For smaller projects, you don’t have to write out all the steps, though even on small projects I usually make a few notes that constitute a project charter (think: structured statement of work). My aim is to pose and answer questions about the goal, the budget, and the client’s critical success factors.

For larger projects, I recommend more concrete steps toward project management – not necessarily formal, but distinct, discussed, and annotated. The determination of when “smaller” morphs into “larger” is up to each individual project manager, but here’s another rule of thumb I’ve found useful. If it is likely to

  • Last longer than 40 total hours, or
  • Involve three or more people in the substantive work

then it’s moving into the realm of “larger” project. It may not be a big project per se, but if you don’t deal with the pieces in terms of Legal Project Management steps, procedures, and perspectives, you significantly increase the risk of failure – or at least non-optimal and inefficient delivery.

How to project-fail: be blind to the fact that what you have is a real living, breathing project.

2. Don’t Designate a Project Manager

If it’s a project, it needs a project manager – not necessarily someone with that title, but someone who assumes that role. On all but the largest projects, that role is probably one among the many the project manager has on her plate.

There is no reason the senior lawyer on the project has to be the project manager. It’s a role that can be assumed at almost any level in a legal organization – senior lawyer, associate, paralegal, even trusted legal secretary or assistant.

Formal training in project management isn’t necessary, but familiarity with the tenets of Legal Project Management will make a big difference. (You know where to find my books!) Most of all, everyone on the team, starting with the senior lawyer, needs to acknowledge the project management role, delegate the project management tasks to that person, give that person time to perform the role… and then not “bigfoot” the person by ignoring him, or taking over his tasks, or pretending you’re too important to adhere to the procedures he’s trying to use.

How to project-fail: don’t designate a project manager, or designate and then undercut that person.

3. Lack Project Leadership

Project leadership isn’t the same as project management, any more than leadership and management are synonymous. I’m sure you’ve known great leaders who couldn’t (or at least shouldn’t) manage anyone or anything, and great managers who proved to be disastrous leaders.

I’ve written before about the Three Laws of Leadership:

  1. Share a clear vision.
  2. Engage smart, committed people.
  3. Get out of their way.

Sharing a clear vision, as a project leader, applies not just to the goal of the project (for the client) but to how the project will run. Will you set clear tasks? Support team members in both success and failure? Praise in public but correct in private? Will you be the kind of project manager and project leader that people will want to do multiple projects with?

To the extent that you get to choose team members, seek out those willing and able to commit time and focus to the project and its goals. And while pretty much everyone is legal is baseline-smart, look for those with real-world smarts as well as legal knowledge.

And then… let them do their work. Don’t micromanage, either their legal work or their project tasks. Set an expectation that they own and are responsible for their tasks, and then let them do their work. And remember, the synonym for “my way” on most tasks isn’t “the right way” but “a right way.”

How to project-fail: forget that leadership and management aren’t the same thing.


Stay safe, and keep those projects moving forward.


Comments are closed.