Handoffs Are Making Your Matters Late

Unless you’re a lone wolf, your project is going to have hand-offs.

Sorry, did I say “project?” I forgot for a moment that this is a legal blog. I meant “matter.” Or “case.” Or whatever else you call that “individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim.”¹  For consistency with the rest of the business world, let’s call it a project.

Oh, and even if you’re a lone wolf you’ll have at least one hand-off (assuming you have a client). Unless you’re working on something for yourself and you plan to work it from start to finish in one sitting, every project has some transfer of work from one resource to another. And those transfers are one of the biggest reasons your projects fall behind schedule. (They are far from the only reason, which is why I’m calling this post Part 1).

The most obvious source of a hand-off is when the project (or any task within it) passes from one person to another in order to get something done. But there are many others that are a little less intuitive. Handoffs exist between attorneys and clients, attorneys and supporting professionals, attorneys and other attorneys, and even one person and that person’s future self (as when you put down one project to pick up another, and eventually have to get back to the first one).

Why are hand-offs so problematic? You probably have an intuitive sense of some reasons, but let’s dive in a little and see why they are so fraught with peril.

1. Boolean Logic

Okay so this might be an esoteric place to start, but it really is the simplest. There is a simple logical rule that says that for every new dependency in a project (hand-offs, by definition, involve dependencies), your chances of the overall project being late doubles. This was articulated by Agile mentor Troy Magennis at his 2015 Agile Alliance talk and echoed by Dominica DeGrandis in her excellent book Making Work Visible.

Think about it like this: For every dependency necessary to deliver a project, there are two possible outcomes for the timing of the project’s delivery: On-Time, and Late. (Theoretically you could deliver early, but when was the last time that happened?)

For a single dependency, then, there are just two options, and (for now) let’s assume each has a 50% likelihood.

What happens when you add a dependency? Well, each one has a 50% likelihood of delivering their part of the project on-time, but the likelihood of the overall project landing on-time gets cut in half. Why? Well in one possible scenario it is easy to see: if both dependencies are late the overall project will be late. But what happens if one resource is on-time while the other is late? Of course that makes the overall project late too (baring heroics from the on-time resource). Only in one of the four possible scenarios will the project deliver on-time, and that’s when both resources deliver on-time. That means the project has a 25% chance of being on-time (half of what it was with a single resource).

Add a third resource and the likelihood of delivering on-time drops to 12.5%—just 1 in 8. This starts to get a little harder to hold in your head, but the picture below illustrates the possible outcomes.

Add a fourth resource, and the chances of delivering on-time halves again (6.25%), and again, and again, until getting something out the door on-schedule starts to look pretty bleak.

2. The Planning Fallacy, Optimism Bias, and Parkinson’s Law

Of course the model above is a simplistic one. Surely you and your team are experienced enough at what you do that you all can deliver on-time more than half the time, right? Just because you’re capable of delivering on-time, however, doesn’t mean that you will.

Three cognitive biases conspire to rob you of your on-time delivery even under the best of circumstances.

The first is the Planning Fallacy. First articulated by Nobel Laureate Daniel Kahneman and his research partner Amos Tversky  Kahneman defines the bias as the “tendency to underestimate the time, costs, and risks of future actions and at the same time overestimate the benefits of the same actions.” This is true even when you’ve worked on similar tasks before, because we tend to see the successes of our past behavior as a normal part of the work but we view any shortcomings as one-off occurrences that are unlikely to recur.

That last part is known as the Optimism Bias, and it is wrapped up in our very egos. We tend to overestimate our own abilities (while simultaneously underestimating the abilities of others), and we also tend to want to present ourselves in a favorable, capable light. That’s all well and good when it comes to social signaling, but it is a handicap when it comes to estimating how long it will take you do get things done.

Let’s say we’re hip to our own lesser instincts though, and we recognize that we need to give ourselves more time than we think to get things done. Maybe you go with the conventional wisdom and double or triple your gut instinct in order to avoid delivery. Or maybe you’re even geekier and you’ve joined the “multiply by π” bandwagon. In any event you’ve left yourself plenty of cushion to make sure you don’t fall behind schedule.

Unfortunately that’s where Parkinson’s Law kicks in, the adage that “work expands so as to fill the time allotted for its completion.” Now this one doesn’t have quite the scientific backing as the others, but as a rule of thumb in the business world it is probably better known.

There are a couple of things that come into play with Parkinson’s Law. For one, when we have a long time in which to complete something, we have a tendency not to start working on it until the deadline feels imminent. When we delay starting, we delay learning—especially learning whether the assumptions we’ve made about the project length and complexity are any good. If things proceed more or less as we expected them to then the delayed start may not be a problem (more on that in a sec), but if any unknown unknowns rear their ugly head then the timeline is at risk.

The true sense of Parkinson’s Law is that we all have a tendency to stretch out the work itself. Need to do some legal research? With a longer deadline you’re more likely to dive down some rabbit holes. Drafting a contract or a brief? You might spend a little more time than necessary noodling on the TPS clause, or making one extra argument, or reading through it an extra time or two to second-guess yourself check for errors. Expand the work too-early in the process, however, and you become susceptible to surprises in the latter part of your work that can still cause delays.

Let’s say you know all about these biases and make a good effort to prevent them; unfortunately, as I said before, they are nasty conspirators. Take the Optimism Bias: You take it fully into account and give yourself the exact right timeline. But the flip side of out optimism about ourselves is our pessimism around the capabilities of others. So you’ll tend to give your assistant, or your client, or your partner, a little extra time to do their part.

But when the task lands on their desk, then their own optimism bias kicks in. They think your deadline is way too long, so they’ll have a tendency to delay their own start, expand the work, etc. Even when you’ve done your part (say you’re resource 1 in the graphic above), it is really hard to control for the dependencies.

3. Queues

The third killer stems from the fact that hand-offs are rarely hand-to-hand. More often they are hand-to-inbox, or worse, hand-to-flung-over-the-fence. When a hand-off is anything but instantaneous, it inevitably becomes part of a queue—a limbo state—while it waits for the needed resource to become available.

Queues are a silent killer of productivity, especially in a profession that pays an inordinate amount of attention to metrics like utilization and then designs its incentives accordingly. Queues are a funny thing, simultaneously weighty and invisible; important yet neglected. And they have strange properties.

Take Little’s Law (a component of Queueing Theory), which teaches us that the length of time a single item will spend waiting in each part of a queue actually grows longer for every additional item that is also in queue. It is a remarkable finding backed up by empirical evidence: even the item that is next-in-line will wait longer in that penultimate state if there are lots of items lining up behind it than it would if it were the only thing in queue.

Think about all of the different queues most of us have controlling access to our attention: email, voicemail, appointments, to-do lists, productivity apps like Slack or Asana, and unproductivity apps like social media. Each of them demands our attention and queues up items for us to process. Little’s Law tells us that each of those additional items has a cost, and that’s before the additional effort needed to review and prioritize everything.

The proliferation of queues makes it hard for anyone to find a single source of truth as to what they should be working on next. Some queues simply become black holes while we spend our time and attention on other inputs, while often those inputs are actively hijacking your attention to impose someone else’s priorities upon you.

Those queues, in Lean parlance, are pure waste. Investment without benefit, neither to the customer nor to you, the provider. From the customer’s point-of-view, they do nothing but delay the delivery of value they’re paying for. And for you, they add nothing to the bottom line while taking time and attention and resources to manage. The project itself is WIP, or work-in-progress, that dreaded state where investment has been made but can yield no returns. It is a necessary evil, but one that should be managed and minimized.

One last thing about queues: they form even if the resource you are handing work off to is your future self. Every time you finish part of a project and put it down with the intention of finishing later, it goes back into queue. Once in queue it waits, and forces the other things in queue to wait, for your attention to return. In fact, you could go back up to the graphic in section 1 of this post and insert your “future self” as any of the resources you are handing-off work to; something that even lone-wolves are prone to do.

4. What to do about it

I’ll dive deeper into solutions in future posts, but for now a few things for you to try to minimize the effects of hand-offs in your workflows:

1) Eliminate unnecessary hand-offs. If your project gets initiated by Alice, gets worked on by Ben whose work is reviewed by Alice before going back to Ben for more processing, consider whether you’re passing things back-and-forth more often than necessary. Maybe Alice can do a little more up front so that Ben can do all of his tasks at once. Or maybe she can wait for her review until Ben has finished both chunks of work. Remember, any hand-off you can eliminate doubles the likelihood that your project will be delivered on-time.

2) Make deadlines, even arbitrary or artificial ones. If the work is in your court, give yourself a timebox for completing it. If it is passing to someone over whom you have authority, set an actual deadline. Or if it is someone you can only hope to influence, give them a deadline anyway—especially if that someone is a client.

And make the deadline a little shorter than you might think is needed (but consider giving people an opportunity to ask for an extension). You want to encourage the resource to engage with the work as soon as possible, not just to get it done but to expose those unknown unknowns that so often pop up. We often think we are doing people a favor by giving them more time to work on something, but in reality we’re usually just delaying their starting it. We’d be doing them more of a favor by setting the right conditions for them to get it off their plate completely.

3) Work the project until it is done. Whenever you put the work down, it enters a queue. Not only that, when it hits the front of the queue you need to re-boot your brain around the parameters of that particular piece of work. Taking something out of your queue only to have it re-enter that same queue does nothing to improve the speed of your line. Better to power-through and move it on to completion (or the next necessary hand-off to a new resource).

Have questions about hand-offs or any other element of legal project management or team productivity? Join one of my weekly office hours sessions and I’ll do my best to talk you through it. Just fill out the form below to get notified when I’m going live.

Trigger goes here

1. Google’s definition of “project.”
Post 2019-2

Happy Blogaversary to Me

Wow, blogaversary is a terrible word, but a good time for reflection nonetheless.

I started the Legal Value Theory blog a year ago as a place to capture my thoughts around the nature of legal value and occasionally express my frustrations around the perceived lack of value in our industry. At the time I had a dual role working for a mid-sized consulting firm, spending most of my time as a business consultant on client projects but also acting as in-house counsel for the firm.

Wearing two hats gave me an interesting perspective on the nature of legal work and operations. Continue reading

Legal Project Management: You’re Doing it Wrong

[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.Continue reading