Do traditional “waterfall” (PMBOK) project management methods really work in legal, or are they too rigid for most legal projects and processes? Learn how some legal project management teams apply Agile/Scrum software development frameworks or other modified traditional methods for a more iterative and incremental approach to the management and delivery of litigation, AFAs or any other legal projects that can be mapped into phases.
· Kim R. Craig - Seyfarth Shaw LLP
· Andrew Terrett - Borden Ladner Gervais
· David A Rueff - Baker Donelson Bearman Caldwell & Berkowitz
· Suzanne Wood - Norton Rose Fulbright
See tweets at #info8.
These are my notes from an intriguing presentation about an area of effort that may differentiate law firms. The conversation emphasized lessons from the trenches. The panel included representatives from three of the most sophisticated LPM law firms and it was good to hear about their challenges and victories in implementing LPM. I wish that they had spent a little bit more time explaining concepts like scrum and waterfall to project management newbies.
[I've covered the Seyfarth PM story elsewhere http://caselines.blogspot.com/2012/08/ilta-session-alternative-forum-track.html ]
Lean Six-Sigma emphasizes the voice of the client.
Seyfarth started PMO in 2004 outside of IT. They did do some IT projects.
Using too much historical data to develop process maps can be problematic because the way we'll be doing things going forward is going to change.
They use "Task Map" which is a light overlay on Visio. They've mapped out the process of mapping out a process. They pull out a page that they've used before. They range from 8-60 pages. Attorneys get hung up on rolling over from page to page. They blow up one task and show how it's organized. Attorneys like educating them on what they do. She's learned a lot about law. Hearing attorneys talk about how they make decisions is really important.
These conversations are a major KM opportunity. KM needs to listen to, capture, and reuse the process mapping discussions.
We're all new at this. PM techniques that look nice and take a long time to develop may not work in legal. The first time she showed an attorney a SharePoint project chart it didn't work out well.
An email with bullets was much more effective than a full status report.
They used many types of applications and not any one coherent piece of technology to do PM.
Agile has self-managing teams, lets teams manage work. Scrum defines roles.
LPM needs to take core PM concepts and twist and turn them to apply to legal.
We don't know at the start of the engagement all the factors that come into play. You don't know in advance how aggressive opposing counsel might be or what you might discover in the documents.
The agile approach allows weekly planning meetings.
Agile is really a manner of thinking. You can adjust and be flexible.
Kim's team started out as a value add, but they are now billable (but without a billable requirement). They measure ROI on retained or new clients. Clients very rarely write off the LPM time. Clients usually have PM teams.
She's seen increased sophistication in RFP information requests around LPM.
BLG borrowed from Seyfarth playbook, they have had an LPM office for two years. BLG has six offices and a very diverse set of attorneys and practices.
A lot of traditional PM makes a lot of sense in legal. It needs to be simpler. They are not writing things down in project plans. Lawyers have a high sense of urgency and want to "do, do, do" right away. You can turn a long project statement into one page.
Attorneys don't use Gantt charts. They do have deadlines and milestones.
Process maps enable bottom-up estimating instead of analogous or top-down estimating.
Process maps have been a great success, they elicit additional steps. Old habits die hard, that process mapping work has been done for a particular piece of work does not mean the matter team will actually leverage it in practice.
A process map is like a GPS. It gives you direction but you're going to use common sense and "keep driving when you cross the bridge" instead of turning into the river like the GPS suggests.
What matters is what works. Lawyers want the tools and approaches that will work for them. What that is may vary from industry to industry and client to client.
The big LPM challenge is change management. You're dealing with people who have been doing things a particular way for a long time.
Traditional project management workflow too cumbersome for attorneys to adopt. They spent three months designing a specialized workflow "BakerManage" that draws on waterfall project management, but is based on the way legal teams actually work. Clients can see the same information attorneys are using to manage the case.
They decided to develop a team of 10 project managers (paralegals, attorneys with PM certification, technologists). Process improvement and management is included.
Agile sets up regular times to revisit project schedule and plan. Not every two months, more like every two weeks.
The heart of the work is the tasks and processes. They worked with a health care litigator to develop a detailed process map. When the AFA request came in, they had already developed the ability to provide a detailed estimate within 48 hours.
BakerManage has a budgeting tool that reconciles with time with the budgeting system to show lawyers where they are against budget, and also provides email alerts. The system requires daily time entry. Checking the system every 30 days is not often enough.
Using a consistent set of codes allows cross-office matter comparison.
Lawyers need to have initial meetings where whole matter / case team is educated about budget and limits. Then they can operate as a self-managed team. It can't be business as usual. LPM type systems are a way of communicating with the team about what the client requirements are.
They use LPM on matters on fixed fee matters. The consistent communications with the client develops its own momentum. The LPM team doesn't bill to clients.
They have had client employees seconded to the law firm team to learn LPM.
An audience member suggested that associate / resource availability is a real challenge for LPM.
Don't assume an associate only has an 8 hour day. Engineers have used critical path technique. That may be the next phase, but right now we're just trying to get lawyers to develop the plans at the time of budget development.
Identifying resource availability is a next step [my firm has developed "iStaff" software that could help with this, as associates identify their prospective level of availability.]
Clients are forcing kickoff meetings where they want whole team is identified up front.