[getty src="456501701?et=r-qTYgCKT6Z9NXgfwpEQ1A&sig=Q0a2IK7BXklNSQs8J23lAC_2h8dh-WYylj8onTsfhdc=" width="507" height="387"]
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.
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
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.
© 2014 John E. Grant. Revised 2018.