A story

“We live on planet Earth!” declared the 4-year-old, boasting to my son about his new knowledge of the solar system. The boys were waiting with their class as the parents signed them out of preschool for the day.

“No! We live at home!” my son responded righteously. He was a year younger and not yet burdened with planetary learning.

“No! We live on planet Earth!” the other boy insisted more loudly.

“No, no! We live at home!” my son shouted. This escalated until my wife and the other boy's mother had to break up the shouting match.

How does this relate to practice management?

Lawyers and technology professionals can find themselves in the same situation as those two boys. When the two groups sit down to design and build the technology piece of a know-how sharing project, a funny thing happens. Both sides appear to speak English, yet they couldn't be further apart in the way to approach the problem than if they spoke different languages and came from alien cultures.

Many knowledge strategy initiatives within a law firm involve some form of technology assistance. My previous posts (Welcome to my blog for law firm leaders, Parts 1 and 2) have discussed the importance of starting with lawyer needs and driving the project from the lawyer perspective. Still, the two groups may have a hard time working together.

The lawyers, commiserating after a project meeting, might wonder aloud, “What do those IT guys do? Everything takes so long! First they have to document the heck out of everything we say, then make us check it and then document the checking! They're so process-oriented and inflexible. When we make changes to our plans, they get all upset and warn us how we're extending the timeline. How are we supposed to know exactly what's needed? We're building something new. Changes are inherent in doing that. Even little changes seem to throw them for a loop. Then they show us their first attempt and it's ugly and hard to use. Why can't it work like Google and our iPads?”

Meanwhile “those IT guys” are just as frustrated. “Those lawyers don't even know what they want. They haven't taken the time to write up their business needs in an organized way. They just want to talk to us about a concept and expect us to fill in the blanks! We're not lawyers. We can't read their minds. They want to build the house without any plans, and change the design along the way! They act like we have the development resources of Google and Apple. They have no idea how much work is involved.”

Just like my son and the 4-year-old, both sides are right but neither can see it.

How can it work better?

My advice

To the lawyers I would say:  You need to accept more structure in the process. Expressed in concepts familiar to a deal lawyer, there needs to be a time and responsibility schedule. There also needs to be a write-up all can agree on describing the project scope – in other words, what the new system will accomplish and how it will function. There also needs to be agreement on the success metrics, so you can know when you're done. IT projects require several rounds of building and testing. The first round can be really rough-looking. Apple's customers see only the finished product, not the prototypes and mistakes. Also, though your IT Dept. may seem large, IT guys are not interchangeable. Your department has very few IT professionals with the skill set to develop new software. The IT director must balance these scarce resources against many development projects, including yours. The vast majority of the IT staff focuses on the care and feeding of the existing complex infrastructure and user support. They do not have the skills for development work. As you work with the IT guys and admit structure into the process, they will start to get what you want. They will become more comfortable and flexible. Be patient.

To the technology professionals I would say:  You need to accept that lawyers are not used to a predictable process. Their brains and personalities are wired to handle interruptions, which is the way their client work flows as they juggle multiple matters. They assume everything works the same way. Despite your best efforts, they will make changes along the way. It's the nature of the beast. They will also let themselves be pulled away by client work to the exclusion of all else. You will endure periods of radio silence. The lawyers are good at writing, though, and will quickly accept the requirement for a write-up of their needs. As the lawyers are forced to write their business requirements, however, they will realize they haven't thought their needs through fully. That writing process will bring them along. The situation will get better. Be patient.

Find a translator

The project will go much more smoothly if there's a translator. This could be someone in the IT Dept. or another administrative department who is used to interpreting business requirements for technology projects. Often the IT director has these skills, but not the time to play this role in a specific project.

Less likely, the translator could be a lawyer who has previously worked on software development projects in the firm or otherwise understands the project management process. A “techie” lawyer is not the person you want for this role. In fact, techie lawyers usually don't work out at all in these kinds of projects. They are happy with more complexity than the average lawyer-user can tolerate, have inflated expectations about the technical result that can be achieved with the available resources and can be even more impatient than the non-technical lawyers. They also are no better than the non-technical lawyers at spelling out details of the business requirements.

If a translator from the IT or lawyer side is not available, an outside consultant experienced in this process should seriously be considered. The right person in this role can make a huge difference in the overall efficiency – and possibly even the success – of the project. To be effective, the person not only has to know how to be a translator, but also has to gain the trust of both the lawyers and technology professionals.

Make a written plan

Lawyers are used to changing on the fly. Their professional experience has taught them that what they need to do for a client matter may change every day. These lawyers believe there'd be no point writing a detailed plan for their matter because it would never unfold as laid out. Perhaps the very few lawyers who are accomplished in legal project management will understand where the IT guys are coming from, but most lawyers will not. They don't think that way, and have no experience operating that way. (Those lawyers could use some lessons in legal project management, but that's a topic for another day.)

A technology project is like building a house, though. Plans are needed first. They must be written. How else can manpower, cost and timelines be estimated? Of course, plans can change, but those changes need to be made in an orderly manner, taking into consideration how those changes may affect what's already been constructed and what's yet to be built. Changes usually introduce delays and extra costs, so it's good to minimize them by making the design as complete as possible at the outset.

Build it in phases

It's best to start with a pilot. Design the entire system, but build only a subset at first. Get a small group of lawyers to test what's been built. Build and test another piece. When it's built, expand the user audience gradually.

The phased approach has several benefits. First, a tangible result is produced more quickly, even though it may be partial. Second, user testing on that partial result may reveal needed design changes, which can be made before the other phases are built, saving money and perhaps time. Third, initially sharing the final result with only a small circle of lawyers will allow good word of mouth to be generated in advance of an official launch, making it more likely the larger audience will embrace the result.

Conclusion

Lawyers and technology professionals in a law firm can collaborate successfully when they make the effort to understand where the other side is coming from and try to meet in the middle. A translator can make the process more efficient and may even be the determinant of success.

In the next post

The next post will discuss the challenges of e-mail, including important client advice that's not saved, research that can't be found, hundreds of communications in a matter that aren't shared with the team, and intrusive broadside messages seeking information that should be available centrally. Technologists propose all kinds of software solutions that don't work because lawyers can't be pried away from Outlook when at their desks and the solutions don't work on mobile devices. What can be done?

[Photo credit: © Can Stock Photo Inc. / forsterforest & endotune]