Blog

I read a recent blog on legal project management that proposed that legal project management should be of the “agile” variety, not the waterfall variety. The basis for this was that at the start of a legal matter we cannot possibly know all the steps it is likely to go through.

The blog went on to say that should you come across a legal project manager who talked about analysis, design, build, test, implement etc, you should not hire them, wretched waterfall person that they are. The blog was adamant that agile people do something else (although it wasn’t very clear what it was that they do do).

All of which I found pretty disturbing, not because I am pro-waterfall and anti-agile – although agile as a cult does both irritate and concern me. And not because agile does not work, or is not needed – there are plenty of situations that merit, demand even, an agile approach, which we know will generally work.

No, I found it disturbing because it was, IMHO, confusing two things that are separate but always integrated – project management and project execution. And thereby missing a trick or two.

So, some thoughts:

• My own process map of LPM comprises four processes (Direct, Initiate, Control and Close) which envelop a fifth process (Execute). Some people will add Plan to the four processes, I tend to do it as part of Initiate, and then continue the planning and re-planning as part of Control. So, LPM looks, in process terms, like this.

• Execute varies with the form of the thing being built. In a law firm, the Execute could be as exciting as a major M&A transaction, or as mundane (no offence to real estate lawyers), as the assignment of a lease. Every different matter type will have its own Execute (with, we hope, its own process map), but with broadly similar Direct-Initiate-Control-Close processes.
• And that’s the point – LPM (Direct-Initiate-Control-Close) has its process map, and Execute has the map defined for what it is that is being built or delivered – a legal matter, a new system, a bridge, an engaged organisation….
• The PM/LPM must, as one of her critical responsibilities, integrate the two process maps as the basis for a project plan.

The agile approach and its terminology were developed in the white heat of system development projects. It is rooted in the belief that requirements for such systems are never fully known, and are constantly changing anyway. This invalidates a development method (the waterfall method) that is based on getting all the requirements done at the beginning of the project, signed off, and then baselined, never to be questioned or changed again. This according to the agile generation is how we antediluvian boomers developed systems in the last century. Some thoughts on this….:

• First, I agree that requirements are hard to fully know, and that it is unrealistic to pretend they won’t change, or that new ones won’t emerge.
• Second, as an aside, many software developers/engineers are really bad at doing requirements, often failing to distinguish between the domain of the problem (where the requirements live) and the domain of the solution or application (where the system that is a solution to those requirements lives). Always beware the software developer who says his user “doesn’t know what she wants”. Sometimes true, often not.
• Agile developers still do analysis, design etc. They have to, or they couldn’t develop and deliver anything.
• What is important about agile approaches is that the standard functions (analysis-design etc) are not applied to the whole problem but to different parts (subsets) of it, working from requirements that are known and stable, towards those that are less so, but will become more so as the product is developed incrementally.
• I’ve never seen a pure waterfall project, let alone worked on one. The idea that people plough on regardless of changing or, more likely, new emerging, requirements is an insult to a generation of skilled system developers. Most projects I worked on iteratively revisited all previous stages as new requirements emerged, making the project a set of cycles, rather than a single, continuous waterfall….so much more like agile thinks it is…
• Most waterfall methods utilised releases as a way of delivering useful functionality early. As implementation changes specification, releases typically trigger a revisiting of all previous phases to ensure that the analysis of requirements is still valid (and yes, it always needs re-work).
• Those of us who worked on the rapid prototyping projects that were the antecedents of today’s agile projects learned early that some analysis of the total requirements is necessary to ensure that the initial versions of the software (MVPs, if you like) are a close enough fit to the actual (but as yet undiscovered) requirements to allow the later versions of the solution to converge on the right solution. Too far away, and that convergence becomes difficult, if not impossible.

So, is the project management of an “agile” build different to that of a “waterfall” build? I’m not certain it is much, especially if you’re using product-based planning. If you aren’t then you tend to manage stages in waterfall where you would manage sprints in agile. There might be some difference in the management of the iron triangle, where agile projects hold cost and time constant, and vary features (scope, quality), whereas waterfall projects make decisions based more on the project’s characteristics (so a regulatory project might hold time constant, and vary cost and quality).

An aside – I have always insisted that estimates should be presented as ranges, not as single numbers, to reflect the residual uncertainty at each stage of the project. There is no doubt that the use of single point estimates of high precision that prove to be stunningly inaccurate has brought waterfall into great disrepute.

Agile is not the answer that so many people hope it will be. That’s often because they’re not certain what the problem is to which it is supposed to be the answer. Agile has had some pretty big failures chalked up to it (e.g. Universal Credit) – although the excuse of Agile proponents is almost always that it “wasn’t proper Agile”. And some of that is undoubtedly true, though certainly not all of it.

Is it what is needed in legal?

• I know that lawyers cannot know how everything will pan out but it is also true that most clients have a good idea of what they want, or at least how much it is worth to them, even if they can’t describe it in detail.
• What I do know is that there has to be enough (maybe only just enough) of a blueprint of the thing being delivered and enough (just enough) of a plan to help confirm that the thing being delivered can be built, and for the money on offer. I can’t see that lawyers don’t need to know these things as well, for their client’s sake. Timeboxing, and sacrificing scope, is unlikely to satisfy any law firm clients.
• My experience of LPM in a couple of big UK firms reminds me that the biggest problem we had was holding the lawyers back. The client’s telephone call to a due diligence team was an instant signal to drop everything, head over to the client’s place, and start wading through documents. No or little thought about what the client wanted until the team had delivered the 300-page report to a bemused client, often too late for her to make proper use of it, when all she wanted was a short two-or three page report on the major contractual risks in the transaction and their potential mitigation.

My own view is that a mixture of the two methods is likely to work best – enough requirements work to give the design of the solution a good chance of being both coherent and correct, with enough local agile development to nail precise requirements.

The job of the PM/LPM is to understand what is being built, and how, and then shape a project management method to manage that build and delivery in the best way possible. Blind adherence to a single method is always likely to be an impediment to success.

The LPM world still has too much confusion of process and projects. It still has too much adherence to the idea that the person managing the matter should have the same competence as the person executing it. We know from other worlds that this is not necessarily so (and sometimes definitely not so).

Understanding the difference between project management and project execution, the distinction between their process maps, and the need to integrate them into a single approach will move LPMs a lot closer to success.