A technology project in a firm competes with client work for time. Without a plan, it grows, stalls or ends without anyone using the result.
This article describes a simple way to run a project: define the scope, name owners, work in phases and decide in advance how to handle requests for more.
The problem
Projects start with a wish, such as better intake, and without a written scope that wish keeps growing. Each request seems small, and together they delay the project.
When nobody owns the decisions, questions wait for the busiest person in the firm.
What is known
Our articles on technology adoption and on measuring cover what is known about adoption and results. We found no independent figure on how project methods change outcomes in law firms, so we give none.
What is certain is that a project has a start, an end, a scope, people who decide and people who do the work. An unclear point in any of these causes delay.
What to do
- Write one sentence that says what problem the project solves and who will use the result
- List what is in scope and, just as important, what is out of scope
- Name one owner at the firm who decides, one person who knows the daily work and one person responsible for the result on the provider's side
- Break the work into phases, each with a result that a person can see and test
- Document the current process before building, as our article on documenting processes describes
- Review each phase with the people who will use it before starting the next
- Agree how changes are requested, who approves them and what they do to the schedule and the cost
- Decide what success will look like and how it will be measured, before launch
When to say no
- A request that is outside the written scope and would delay the first phase
- A change that serves a rare case but complicates the daily one
- A wish to automate a step that has not been written down, or that an attorney must decide
- A shortcut that skips testing with sample data
- A request to connect a tool when nobody can say who will own it afterwards
- Saying no can mean not now: write the request on a list for a later phase
What to look for when you implement it
- Whether the scope is written and the people who decide have read it
- Whether owners are named, with a backup for each
- Whether each phase ends with a review and a decision
- Whether training and support are planned, not left for the end
- Whether changes are recorded with their effect on time and cost
- Whether the project has a defined end and a handover that says who maintains the result