Legal Project Management: You’re Doing it Wrong

Embed from Getty Images

Legal Project Management is quite the buzzword these days. Of course the concept has been around for years, but the recent publication of the ABA’s The Power of Legal Project Management has renewed the push for lawyers to adopt the project management techniques that have been used in the business world for decades.

Here’s the problem: the project management methodology being marketed to lawyers—whether by the ABA book, an upcoming ALI CLE, or any number of consulting firms—is outdated. Not only that, it isn’t especially well-suited to the dynamic and sometimes volatile nature of legal work.

Before I go further, let me first say that I think that legal project management of some sort is not just a good idea, it is essential to running an efficient and effective law practice (or law department). And by effective, I mean one that is focused on delivering Customer Value. In the old world of unchecked hourly billing, project management may not have made much sense since the financial incentives weren’t aligned toward efficiency. But clients today demand efficiency and predictability, and project management is a great way to get a handle on both.

(Not to mention that optimizing your workflows and operations is the surest way to clarify your marketing pitch and intelligently price your services, but those are topics for another day.)

The first thing to remember is that project management isn’t a single thing, It is a collection of concepts and methodologies adapted to the needs of the project stakeholders, participants, and end-customers. Every organization will have its own flavor of project management. The business world—and especially the technology world—typically works under one of two top-level project methodologies: Traditional (a/k/a Waterfall), or Agile.

Waterfall is what most people think of when they conjure up an image of project management. It is called Waterfall due to the way a project is usually depicted visually through a Gantt Chart, with progress over time cascading like a mountain stream.

Waterfall Gantt_chart

This is the methodology you’ll learn if you pony up $400 and make it through all 571 pages of the ABA book. And it works fine for some projects (any project management is usually better than none). But implementing Waterfall at an organizational level requires significant time and investment, and because of the length of many Waterfall projects the learning cycle for team-members is slow. On top of its other shortfalls (and I won’t go into them all), the biggest problems with traditional project management in the legal context are (1) the large effort required for up-front project planning, and (2) the rigidity of a project plan once it’s put into motion.

Planning = Guessing

In their excellent 2010 book Rework, Jason Fried and David Hansson* make the point that “planning” is just another word for “guessing.”

Unless you’re a fortune teller . . . planning is a fantasy. There are just too many factors that are out of your hands [and] writing a plan makes you feel in control of things you can’t actually control.

. . . The timing of long-range plans is screwed up too. You have the most information when you’re doing something, not before you’ve done it. Yet when do you write a plan? Usually it’s before you’ve even begun. That’s the worst time to make a decision.

This is especially true with legal projects. Lawyers usually understand the basic framework of a matter (case, deal, etc.), but the matter itself often presents new information on a regular basis.  Sure you can adjust the plan—and better to adjust a plan than to not have one at all—but all those little adjustments take effort and represent Waste (exposing unnecessary pre-processing leading to inevitable defects).

Traditional project management places a heavy emphasis on up-front project planning. The project manager will usually go through a rigorous exercise to determine project goals and milestones, draft a project charter that outlines the time, money, and resources it will take to accomplish those goals, and establish a project schedule. He or she will then gather all of the interested parties around the table where they’ll debate the assumptions and do as much horse-trading as the allotted time will allow. In the end they’ll give their blessing (often lukewarm), to the document henceforth referred to as THE PROJECT PLAN. Only then can the project begin.

But as Fried & Hansson point out, planning is nothing more than guessing. Hopefully it will be educated guessing, but why not get as much education as possible before staking your guess? The reason there is so much debate and horse-trading in a project kickoff meeting is that nobody really knows what efforts the project will take until they actually start working on it. Everyone understands that issues will crop up, landscapes will change, priorities will ebb and flow—they’re just hoping that they can hedge their up-front commitments sufficiently to cover their tails if things go awry.

This heavy-lift planning is also, I suspect, the reason that traditional project management hasn’t gained more traction in the legal industry. Lawyers are often fairly comfortable with matters evolving over time, therefore it feels counter-intuitive to stick themselves with accountability for milestones and deliverables that may not make sense when the time to deliver them actually arrives. Sure there are change orders for the big changes, and hems and haws for the small ones, but these add to the administrative overhead of the overall matter and erode client trust.

Staking your name and reputation to a traditional project plan involves a good deal of risk, and we know how lawyers feel on that topic. A big reason that legal project management appeals to clients is that a project plan shifts risk and accountability to the lawyer. That isn’t necessarily a bad thing, but imagine instead a project framework that responds to risk and reduces it, with everyone working collaboratively to address issues instead of playing hot potato or the blame game. That framework is Agile.

Learn (and Plan) As You Go With Agile

The software development world has long experienced similar frustrations with traditional project management. Software releases would often take months or even years, only to find that the business assumptions driving the new functionality are no longer valid (or never were), or that the sheer size of the development effort had resulted in clunky, unworkable product. Everyone involved would leave frustrated, with plenty of blame to go around.

Not surprisingly, some forward-thinking software professionals imagined that there must be a better way to handle the development process. Their thinking coalesced in 2001 with the publication of the Agile Manifesto:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

 That is, while there is value in the items on
the right, we value the items on the left more.

As you can see, Agile is more a mindset than a methodology. There are at least a dozen project management and product development toolsets that rally under the Agile banner, but all of them follow those four simple preferences. Replace “software” with “product,” and you can apply Agile thinking to nearly any business situation.

Without going into the entire history lesson there are two key points for lawyers:

(1) Agile is far from a newfangled approach; it is built on Lean principles originally developed by Henry Ford and W. Edwards Demming, and famously refined into the Toyota Production System. Agile methodologies have been adopted and further developed by some of the most successful companies of our day.

(2) In the technology world, Agile is everywhere and Agile is everything. Have you ever noticed how often some of the apps on your smartphone push new updates? Weekly is common, and for some it is every few days. That’s Agile at work: delivering incremental improvements into the wild to be used and abused by actual customers. Some will work, and some will flop, but either way the business gets real feedback real quick and can respond accordingly. Google, Facebook, Twitter, and thousands of other technology companies rely on Agile methodologies to build their products and services quickly, make fewer mistakes, and respond to actual customer demand.

For me, Agile methodologies like Scrum and Kanban have several advantages over traditional project management in the legal setting. First and foremost, Agile methodologies don’t require a lot of up-front training or process design to get started. For some, you need little more than a whiteboard, some sticky notes, and a  notion that “there has to be a better way.” Because Agile adopts the Lean concept of Kaizen, or continuous improvement, it recognizes that the improvement has to start somewhere. So why not begin by doing what you’re already doing but tracking it in a slightly different way? Agile encourages you to get started, pay attention, and you’ll be amazed at how certain problems will almost magically resolve themselves.

Second, Agile methodologies emphasize frequent and open interaction among team members. Goals, deliverables, and progress are usually tracked using some form of visual management tool (often a card wall or Kanban board) so that the entire working team—even a team of one—can see what everybody is currently doing, what they’ve completed, and what’s next. A cadence of short but regular meetings (or rituals) helps ensure that progress is celebrated, obstacles are identified, and next steps are commonly understood.


This in turn fosters genuine teamwork. Team members understand how their work contributes to the whole, whether they’re delivering against expectations, and where to get help if they need it. Project owners can see exactly where the project stands by reviewing the board or attending a ritual, and they can communicate progress to the customer in near real-time. Because of the visual nature of the tracking tools and frequent interactions, the sense of progress in an Agile project is tangible. And that progress becomes addictive.

Finally (at least for now) Agile is, well, . . . agile. Up to the point where a team member actually starts working on a task, the project manager or product owner can adjust the priority of the tasks in the queue to respond to new information or new customer needs. An Agile team embraces the changes because its members are in a position to understand its drivers, can quickly assess its impacts, and are motivated to respond. Moreover, team members are encouraged to bring new information to the table so that the entire team can ensure that it is building a product that delivers the greatest possible customer Value.

This isn’t to say that implementing an Agile solution doesn’t take effort and commitment—it most certainly requires both. Although I know of some examples of teams “going Agile” somewhat spontaneously, it usually takes at least one experienced practitioner to shepherd the members through the early set-up and rituals, and to mediate when disagreements arise. But because of the transparency of the process and the frequency of interactions, most teams pick it up quickly and are able to measure (yes measure!) tangible improvements in their workflows and output within a few weeks of getting started.

So if you keep hearing about the importance of legal project management but either don’t know where to start or are put off by the amount of work and planning required by traditional project management techniques, I strongly encourage you to look into Agile. There are a gazillion resources on the web, and while most of them are geared towards technology projects, with a little tweaking the tools are easily adapted to manage a case in litigation, a major transaction, or the myriad of small day-to-day projects that most lawyers face.

Better yet, seek out a Certified Scrum Master (yes, I am one) or other Agile professional and start a conversation about how Agile methodologies can work for you.

I’ll close with the guiding principles behind the Agile Manifesto. Whether or not you “go Agile,” these statements are full of sound advice for managing a business and customer relationship. If you want to talk more about Agile in the legal context, I can do it all day. Feel free to shoot me an email or contact me on Twitter @JEGrant3.


Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

 Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

* The authors are the founders of the excellent business tools Basecamp and Highrise, both of which were essential to my law practice before SaaS tools like Clio and Rocketmatter were mature).

© 2014 John E. Grant. Revised 2018.

7 thoughts on “Legal Project Management: You’re Doing it Wrong

  1. I really like how you outlaid the problem of law firms just going with word Project Management. It’s so broad and weightless that it’s not even funny.

    Taking things from other verticals that have been trying to improve processes is a great to find ways to improve law firms. I can see you took inspiration from IT, and this is great.

    I suggest law firms exploring, Lean movement, which became a buzzword, but surely brings value, Recently Ivan from LegalTrek, my partner, presented at #ReinventLaw talk about what law firms can learn from startup.

    There are so many things you can take from this startup and high technology firms, you have pointed out a great direction!


  2. John:

    I have studied project management principles in an effort to be more efficient in my law practice. And I have observed that most of the resources tell us why we should utilize project management but very few show us how to do so. Steven Levy’s book on the subject was a good start but the book used waterfall examples rather than agile examples. Perhaps the market is ready for a book that shows how to use agile in a law practice (both a transaction and litigation practice). If there’s one already on the market I’m not aware of it.



    1. Thanks Bradley. I agree that the “why” is critical. As I’ve thought about this more, I believe that one of the reasons that project management of any kind fails to get traction in legal environments is that lack of project management frequently isn’t the critical bottleneck that is constricting lawyer or team productivity. An offshoot of Lean called the Theory of Constraints teaches that all workflows are constrained by a very small number of bottlenecks, usually only one. Once you accept the assumption that just one or two things is limiting your output, you’ll quickly recognize that making improvements to some part of your workflow that is not the bottleneck cannot improve the output of the system as a whole. Fixing something upstream of the bottleneck only increases pressure on the constraint, and improvements behind the bottleneck will leave those functions starved for resources.

      At a project level, I think that waterfall project management mostly ignores this principle. At best it obscures the bottlenecks in a project workflow by expanding the overall project time frame to accommodate them. At a macro level, I would question whether a lack of project management (especially waterfall principles), is truly the constraint that is hampering the overall productivity of your practice–perhaps there is some other area that is constricting your output.

      Fortunately the Theory of Constraints (and more recently Eric Reis’s book “The Lean Startup”) gives us a great way to tell if you’re working on the right thing: Make a small change, measure whether the change results in any improvement (to the overall system, not just the specific function), and react accordingly. If your change actually improves your overall flow then you know you’ve found your bottleneck. Now keep working on it to see if you can get additional improvements. If your overall throughput doesn’t improve, however, then you either haven’t found the critical constraint or you found the constraint but your fix didn’t work. With any of these outcomes, you’ve learned something and can react accordingly. And even if you didn’t get a system-wide improvement, if you’ve kept your change small and your outcomes measurable then your ROI (the return is what Reis calls “validated learning”) is worth it.

      I’ve got an article in progress that will illustrate more on this, but hopefully this is helpful. Thanks for reading and for your comment.


  3. I enjoyed reading this – a thoughtful article.

    In my experience (UK based LPM consultant) private practice law firms seem to start first by looking at process improvements (value stream mapping etc), then they start to give consideration to legal project management with some going so far as to implement Agile techniques.

    Personally, I am a fan of Agile but I really do believe there is no ‘one size (or process) which fits all’. I think law firms and law firm departments need to be aware of all the process and productivity improvement ideas which are out there and then select which seems most appropriate for them.

    If interested, I wrote a series of articles about Agile for lawyers about 2 years ago and the first can be found at:


    Antony Smith


    1. Perhaps, but there is no shortage of great tools for Agile project management developed by and for the tech industry. I actually prefer physical tools (whiteboards and physical cards or sticky-notes) for teams just getting started with Agile. I think the tangible act of moving physical cards through the system really helps bring home some of Agile’s advantages. Physical or digital, however, I think that existing tools are more than adequate for legal processes, at least until there is enough critical mass for some software developer to market a more tailored solution for lawyers.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s