Large complex legal projects: 2 of 2 - communication problems and three strategies to address them
In a post earlier this month, I outlined a distinction between complex and complicated aspects of legal projects. It is hardly news that projects which are predominantly large and complex are particularly hard to control in terms of cost and focus. This post seeks, however, to be a bit clearer about just why that is so, and thereby to lay some groundwork for how to do better.
Large complex legal projects often end up being run, in practice, something like this:
- A fairly high level project plan is articulated, covering quite a long period
- This includes some allocation of responsibility between organisations (e.g. legal department, law firms)
- Some project-specific protocols are also agreed for reporting, review, financial aspects and other points of interest
- Each organisation (and often, in practice, each part of a large organisation) is largely left to define its own working methods
- Organisations coordinate between themselves informally, typically involving a lot of email and some phone calls
- In a really large project, "broadcast" emails (often attaching status tables or similar) and large calls/meetings (with action points emailed around afterwards) are used to tie things together, perhaps also with some form of steering group if the project's importance justifies this
- The high level plan is revisited when dates clearly require change, or when scope has changed significantly
It's easy to see why this happens - each part makes sense on its own.
In practice, however, it doesn't scale very well.
The central problem is that, in a genuinely large, complex project, unexpected things tend to come up in different parts of the project, with implications for the relative value of tasks.
Rapid, effective communication and decision-making about the implications of this tends to get lost in the noise and within the rigidity of the plan.
This translates into time and therefore cost being incurred on things which are no longer good value for money.
Why is communication such a problem in large, complex legal projects?
The answer lies in a realistic appreciation of
- Human limitations, the ever-changing realities of complex projects and the distractions of organisational life
- Some arithmetic
I'm not going to dwell on the first group of things, save to observe that
- Effective communication about complex things requires a conversational approach. To be effective, participants need to have the chance to ask questions, make suggestions, raise challenges and clarify their own and others' understanding of what is needed and how best to do it.
- The fact that people involved in a complex project tend to have different backgrounds and day-to-day focuses (within the particular project and outside it) increases the challenge of effective conversation.
- Status-conscious traditions in the legal profession, and certain other lawyerish tendencies, can also represent challenges.
As to the arithmetic, the point to consider is this.
If only two individuals are involved in a project, the single communication channel between them is manageable, assuming both parties have the necessary soft skills and are prepared to spend the time. However, as the number of individuals increases, the number of possible bilateral channels increases exponentially. The formula is n(n-1)/2.
- 2 people - 1 channel
- 3 people - 3 channels
- 4 people - 6 channels
- 5 people - 10 channels
- 10 people - 45 channels
- 15 people - 105 channels
- 20 people - 190 channels
- 30 people - 435 channels
- 40 people - 780 channels
- 50 people - 1,225 channels
These numbers are illustrative, not definitive, of the problem of communication overhead.
Of course, not every effective conversation needs to be bilateral. However, once you get above a handful of people in a single conversation, there is a limit to what can effectively be discussed about complex things - everyone has their own style, needs and knowledge gaps.
The consequences of this are important.
Three strategies for addressing these communication problems
Strategy 1: split out complicated elements more aggressively
One strategy for addressing the communication overhead is to challenge the characterisation of work as "complex" and find ways of treating it as merely "complicated".
This reduces communication overhead in two ways
- It reduces the volume of issues which need to be discussed, expensively, in a truly conversational, nuanced way.
- It also results in smaller teams handling the genuinely complex elements of work that remain (see the arithmetic above for the importance of this).
Two basic approaches may be distinguished, though in reality they lie on a spectrum rather than being fully distinct:
- One is to break up elements of work into relatively simple chunks, allocate these to human beings and introduce industrial-style quality control mechanisms. Manuals and quality control processes substitute significantly for conversation, though it's important not to eliminate the need for creativity and problem-solving (someone from Fife made the essential observation some 240 years ago about the harmful effects of reducing work to "a few simple operations, of which the effects... are perhaps always the same, or very nearly the same").
- Increasingly, more substantive automation (rule-based and machine-learning-based) is being introduced.
These approaches have proved their worth in recent years. There is still the challenge of ensuring effective communication between a team working in this way and those working in more traditional ways: this is not to be underestimated but is effectively tackled by a number of players.
I don't propose to say more about that strategy here other than
- It has much further to go.
- It also has real limits.
On, then, to two possible strategies for dealing with the complex aspects which are left once everything else has been stripped out that usefully can be.
Strategy 2: accept the status quo and optimise it
In the years following the 2008 financial crisis, significant steps have been taken in many large law firms to optimise the way complex projects are handled, without however significantly challenging the established business model (in practice, as opposed to rhetoric).
An illustrative short summary of techniques deployed is the book Legal Project Management in One Hour for Lawyers by Woldow and Richardson, published by the American Bar Association in 2013.
I cite it simply to emphasise some aspects which seem to be characteristic of much work and thought in this area:
- Legal project management (LPM) is defined as being about "performing legal work more efficiently" and "managing uncertainty." So far, so good.
- A distinct note of exceptionalism is detectable throughout. For example, from the Introduction:
- "The forms of project management that are common in the industrial sector - particularly management, technology and research - focus on delivering invariant results and producing identical, repeatable outcomes. LPM is different. It focuses on delivering value as efficiently as possible under the circumstances."
- A number of practices are suggested, relating to planning, executing, monitoring and improvement. Despite the exceptionalism already noted, much of what's suggested is, in fact, standard project management textbook material, with some pragmatic suggested adjustment to law firm realities and sensitivities (e.g. allergy to non-legal jargon).
- Some illustrative points:
- There is great emphasis on scoping. Legal projects are analogised to construction projects, with the suggested approach being to plan for uncertainty by estimating the probability of occurrence and impact of various contingencies (pages 24-6). This is an analogy which, in my view, risks misleading.
- Success is stated to involve minimising "scope creep and time creep" (page 77). Changes to the original plan are expected to go through a formal change control procedure, supported by traditional tools such as a risk register (page 68) and "redraw[ing] the flowchart" (pages 106-7).
- Individual delegation skills are emphasised: "In successful LPM, no other skill is as important as effective delegation" (page 79).
- The importance of keeping "all crucial stakeholders in the loop all of the time" (page 1) is mentioned. For that purpose, the importance of meetings and conversations is emphasised in the abstract, and the problem of email overload is noted, but these topics are, in essence, noted as difficult to address (pages 88-90). Communication techniques suggested put an emphasis on email, vaguely-defined meetings/calls and periodic updating of formulaic documents (e.g. page 65).
- Emphasis is also placed on the "can't be measured, can't be managed" principle (page 1 and chapter 5) - practically speaking this translates, in the book, mainly into a discussion of tracking time-based costs, with brief mention of AFAs. The challenges of phase/task-based time recording are noted and will be familiar to anyone in the sector but tactics for addressing this are limited (e.g. a suggestion of detailed monitoring and provision of a detailed instruction manual).
In many ways this is an admirable work - succinct and clearly written. Reading it and similar texts, it all seems terribly plausible. Of course, the balance of particular LPM texts and initiatives varies, with some placing more emphasis on technology and on pricing issues than this sample work. However, I believe the above work is representative of the basic philosophy.
However, having seen close up what happens in a lot of complex projects involving large law firms, including ones named in the book as leaders in LPM, and having compared notes with more than a few friends and acquaintances in law firms and legal departments, it seems clear that reality isn't matching aspiration on genuinely complex projects. Not even close, in fact.
The approaches outlined above don't seem to be followed widely in practice, and a deluge of email and information overload combined with inadequate communication often gets in the way.
Indeed, even taking the book on its own terms, a "post-project review" is promoted as an important thing to do but, as one of the authors notes in a blogpost in late 2016, "the room goes silent when we ask how many present regularly and religiously engage in Post Project Review."
What's going on?
Some clues as to why this is all so difficult are offered within the book itself and in the 2016 blogpost just mentioned.
There is acknowledgement of the difficulty of persuading lawyers to do anything, and indeed of the brittle egos of some lawyers.
The authors also make a "major distinction" between LPM efforts in corporates and those in law firms, characterising the former as largely about efficiency and consistency whereas in the latter there is also the consideration of profitability. While increasing profitability for the firm and lowering cost for clients are not necessarily contradictory, there is certainly a tension between them. The authors seek to resolve this with the familiar answer that "[i]n today's legal climate, firms that cannot perform efficiently cannot perform profitably" (page ix, footnote 1). It's not proved quite so straightforward in practice.
Some deeper limitations of the approach which the book exemplifies are, in my view, as follows.
- Over-emphasis on planning. It mischaracterises the nature of the challenge by over-emphasising planning. Whole-project planning and process-mapping are obviously useful if you're largely doing complicated work, e.g. transactions of a predictable, templateable nature (of which far too much is still handled as if it were complex), but are only a modest part of solving the real problem (achieving a good result at reasonable cost) if you're doing genuinely complex work.
- Wrong paradigm. It puts too much emphasis on traditional project management practices and artefacts that have evolved in physical engineering contexts in which much of the work can be broken down and costed in ways that don't map well to genuinely complex legal projects. In which the involvement of a large team is, in other words, mostly in complicated rather than complex activities. Thus, while the authors express scepticism of approaches designed to ensure consistency in manufacturing (e.g. Lean Six Sigma), they do adopt the kind of techniques that are applied in, for example, large construction projects. In my view, the rejection of the first of these is sensible so far as complex legal work is concerned, though such techniques are in fact more relevant (in my view) than the authors acknowledge to non-complex, complicated work. However, the adoption of the second type of technique is in my view an error unless you do, in fact, have legal work which can be broken down as reliably as in, say, the engineering work in a construction project.
- Too complicated. Related to the second point is that this sort of approach fails to challenge existing, fairly free-flowing lawyer practices, and instead seeks to bolt more complicated practices on to them. One can appreciate the temptation to adopt this as a change management tactic, but it risks constraining in the wrong places while increasing the burden on already over-stretched individuals. It involves doing more rather than less, and thereby increases the risk of just been rejected or ignored.
- Insufficiently empowering. That third point also flows into a fourth: speaking to a number of people about their experience of LPM, it seems to feel like it involves a high admin-to-benefit ratio and that it lacks fun or much of a positive, energising feel about it. I'm sorry if that sounds frivolous, but this sort of thing matters.
The proof of the pudding is in the eating, of course. I can't find any reliable evidence to suggest a really positive impact so far of the techniques exemplified by the book just discussed. My impression is that the reality is as summarised in the most important survey of large US law firms and legal departments put it in May 2017 at page 10:
"Legal project management training is another efficiency tactic that is used relatively widely but has not generated convincing results"
In the same survey, almost 40% of law firm leaders considered that their firms were moderately-to-very serious about changing their delivery model to provide better value to clients, but only 15% of clients agreed (page 32). And those that did almost all thought "moderately" rather than "very".
Thus, there seems to be a serious gap between words and reality.
Now, none of this is to criticise those involved in delivering LPM initiatives who, from what I have seen and heard about from a number of sources, are often making good progress in areas which are susceptible to strategy 1 above (i.e. disaggregation, process mapping and automation of complicated work, aka "process improvement"). There is plenty still to do there and it makes sense to focus effort on that, given the difficulty of bringing real, beneficial change to genuinely complex work. It is therefore understandable that law firm LPM successes so far in the complex context so far seem to be mainly about supporting profitability (e.g. maintaining profitable partner-to-associate ratios and monitoring other KPIs) and pricing work more attractively. The question is whether anything more is possible.
Strategy 3: communicate about complex issues in a different way
In footnotes within the book just mentioned, the authors reject the relevance of what they call "industrial project management disciplines" - of which they name several. They categorise such approaches as "plodding" and "designed, above all, to impose absolute uniformity and precision on task of producing identical things."
That's not entirely fair but, more importantly for present purposes, the authors
"admit some admiration for a different project management methodology called Agile, a dynamic departure from step-by-step 'waterfall' architecture of traditional industrial project management systems. Agile emphasizes constant team collaboration, rapid feedback and continuous adaptation as events unfold..."
Despite it having intrigued them, however, they regard it as best for "small-scale projects" and characterise it in ways which seek to fit it into traditional categories (e.g. asserting that "everybody serves as project manager.")
In fact, it's a good deal more important and interesting than that.
The arithmetic used in this post is widely known in the software world as an elegant illustration of the problem. But in my experience it's not well known in the legal world.