Welcome to the second installment in our multipart series on building legal technology. If you’re looking for the first installment (Empathy, Design & Solutions), it’s right here. To sum up progress so far, we’ve identified the pain point/stated problem, and investigated root causes to confirm that the stated problem is the real one. We’ve researched, ideated and sorted possible solutions and presented the proposed solutions to the client. The client has agreed to the proposal, project scope and budget.

Now what? This is where project management comes into full swing. For a fun and easy crash course on project management, watch the Warner Bros. 2001 film Ocean’s Eleven starring George Clooney (among many other greats). In the film, the “project” is a complex casino break-in caper, with $150 Million in cash as the “deliverable”. Watch Clooney engage his team leader Brad Pitt in the heist, while they identify risks and stakeholders, break down the heist into different goals and tasks, then identify and recruit the right team members to do the job.

A big task in project management is creating the Work Breakdown Structure (WBS). This is where you try to define the discrete tasks required to accomplish a certain goal. I’ve found that the party game charades helps me in a way, since when you have to act out an action like a mime, you really must think about what it is you do to get something done. For instance, to paint a wall, you need to locate your paint, then shake the can. Next you pry open the can and pour paint into a tray. Then you assemble your roller handle, slide the cover over the roller and roll it into the tray. Wait – we forgot the drop cloth…

Legal technology builds, like other technology projects, will have an identifiable list of tasks that must be performed in a generally accepted order, with additional lists of “known unknowns” and “unknown unknowns” that you must allow for as the project progresses and scope invariably changes. Let’s say our project is a central firm knowledge management system, where the goal is to collect widely applicable practice intelligence from employees, sort it, then store it in an easy-to-access platform. You might break the task down into:

• Determine who gets to decide what types of knowledge are collected
• Identify types of knowledge desired
• Identify question structures and methods to obtain existing knowledge from individuals
• Sort knowledge obtained, identify gaps and trends
• Vet software platforms for suitability, stability, ease of use and security
• Obtain budgets and risk assessments from in-house technology team (if applicable) to decide if building the platform is better than paying a service (make or buy decision)
• Execute the make or buy decision, (build) implement the platform
• Decide the people and process that will work with the individuals to extract the knowledge
• Identify methods to ensure new knowledge gets deposited into the platform, including awareness campaigns and automatic systems
• Create a storage architecture and User Interface (UI) appropriate for accessing the knowledge created
• Build training systems and materials that are universally understandable by the intended audience(s)
• Build a strategy and budget for ongoing maintenance
• Create closeout documents and a repository so the process (and lessons learned) of collecting knowledge and building the platform are retained and accessible (do not underestimate this step – great amounts of insight into current processes and organizational structures are gleaned from the knowledge acquisition)

Obviously there are myriad ways you could break down a complex knowledge and software project, and we’ve just scratched the surface. You’ll tend to find more research questions in your WBS than you might expect at first, but that’s all about turning the “known unknowns” into “knowns”. It is important to note that building your WBS often comes before forming your team, so that you can figure out who you need to do what. However, it is also common to only roughly sketch out the WBS, then go into more detail with your team as a group project, drawing from the expert knowledge of your team members. Also of note is the 100% rule, which says that you should strive for all the tasks in your WBS to add up to 100% of the project (if possible).

Assuming you built out the WBS by yourself or with a few other top-level leaders, the next step is forming a team, which we cover in the next post. For a real feel of professional project management, I’ll leave you with the Project Management Institute (PMI)’s definition of the WBS as written in the Project Management Book Of Knowledge (PMBOK):

“The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The WBS is decomposed into work packages. The deliverable orientation of the hierarchy includes both internal and external deliverables.

Got that? there’s going to be a quiz.