The Legal Practice Technology Plan
Let's buy everyone a computer, network them together, add a palm pilot, some practice management software, email training, and we're off to the races — right? While this is the plan for some folks out there, it can be a recipe for failure and organizational turmoil.
A technology plan is not essentially about buying hardware and software. It is about your business and how and if there are ways to use technology to improve the way people work, save money, stay competitive, and expand what the firm can accomplish. You may end up buying hardware and software, but this is the caboose of the process, not the engine.
You should have a technology plan because in today's world you simply have to have technology in a legal practice. Without a corporate plan you will get the technology that those with a budget happen to like at the time whether it works for the organization or not. This is as true for two person operations as for firms with two hundred employees.
In short, why do you need a technology plan?
- You'll save money because you won't buy something that doesn't fit with the rest of your hardware, software, and work processes.
- You'll save money because you won't be buying the hottest new item in that category next year if you buy correctly this year.
- You'll save money since you will first figure out what your business needs and advantages are, and are not likely to buy something that simply automates an existing efficient process.
- You'll save money because you will need to train somebody, even if it is just you. This takes time, and if it isn't done effectively you will need to redo it or you will create costly mistakes.
- You'll save money because your work flow and responsibilities in the firm (even a 2 person firm) will likely change and if you haven't thought about this before you dive in, you will pay for it several times over if you discover this fact late in the process.
Back to Table of Contents
2. Preparation: What We Have, What We Need, and Why
The creation of a successful technology plan is not part time work for a lawyer or a systems 'techie' with a full plate. Many organizations go so far as to appoint a Chief Information Officer (CIO), or to charge the current one with developing and implementing the plan. Requiring that the plan and its implementation are evaluated as part of an annual performance review ensures that it doesn't take a back seat to other obligations. Take it seriously or it will falter and fail. Find a willing and capable internal champion to drive it forward. It goes without saying that without management support behind the development of a plan it will rest on the shelf when and if completed.
No plan starts in a vacuum. The planning begins with an audit of what you have now in terms of resources — hardware, software, networks, and human resources, including those who do not work for your firm directly but support it as outsource contractors. This inward-looking activity is accompanied by the outward-looking one of examining current "best in class" legal technologies as well as emerging technologies that are on the horizon. Don't guess what might be out there and don't rely on a vendor to tell you.
Early in the process of developing your technology plan you should consider whether you would need assistance from a consultant who is independent of any software or hardware vendor. Hiring a specialist will pay back in terms of better, and likely faster, decisions. A firm should consider about 2 to 3 weeks of consulting time to assist with plan development, presentations, and obtaining management approvals. More time might be needed if your firm is large, has substantial legacy systems to review, or doesn't have anyone internally to act as the prime author.
The audit should also identify equipment and software that is clearly outdated or scheduled for replacement or modification. It should identify what hardware, software, and business processes work well and what components are likely to be in place for some time to come. 'Plan' is not a synonym for 'replace'.
Back to Table of Contents
3. The Functionality Statement
Accompanying the audit is the need for a needs assessment, which is driven from a corporate vision. The vision must be translated into specific objectives and then followed by a detailed functional requirements statement. The functional requirements must be met by the combination of hardware and software, and your acceptance of vendor supplied equipment, software and services will be based on testing that your requirements will be met. Thus, the requirements must be laid out in terms that are 'testable'. As an example, a requirement might be for a scheduling system that can be viewed from the Internet. But it needs to be made 'testable' by adding conditions of use such as:
- It can be viewed on either Netscape 4 or Microsoft Internet Explorer 4 or, a WindowsCE-based palm browser.
- Changes made in the office are loaded within 4 seconds.
- Changes made by a mobile device are loaded within 6 seconds.
- It should be viewable by at least 40 users simultaneously.
- ...and so on.
Back to Table of Contents
4. Vision and Project Statements
Corporate visions are general, but they set out where the company is going in terms of subject matter expertise and service profiles. The corporate vision must then be translated into objectives that make sense at the information systems and daily operations level.
The definition of the business processes and innovations to be made corporately are not the sole province of the CIO. Management and the users of the technology must be involved. They are the source of understanding the specific business of your particular firm. Not all law firms are in the same business and not all have the same business objectives.
A corporate vision may speak of increasing the speed with which litigation issues are brought to trial and completed but at the function statement level this must be translated into something concrete. For example, the firm will embrace e-filing for motions and palm pilot based wireless scheduling by October 2003. The broad vision must be brought down to specific PROJECTS that together actually generate outcomes that meet the corporate vision and its objectives. You must be able to state what you want to do in terms that allow you to actually accomplish it.
Ordering projects, determining budget requirements, and developing time estimates also represent components of the plan. They are essential components because without them, you are unlikely to find funding for the projects that deliver your plan objectives.
A key derivative arises from figuring out what you want to do and how to do it with technology. Usually the process gives you enough information to answer the following question from the person or group holding the purse strings: "What are the benefits to the organization and how long will it be before this technology has paid for itself?" If you can't answer this question early in the process, go back to the start point and throw the dice again.
Back to Table of Contents
5. The Four Architectures: Foundations for a Technology Plan
There are four key pieces that must be knit together to make this plan work. Systems architects talk about these as the four architectures — software, hardware, data, and management. Remember that a technology plan is not totally about hardware and software — here is where you have to pay attention to them because your plan has to spell out how all four architectures fit together. The architecture planning takes place after you have outlined the nature of your business and the key business processes that you undertake. Some elements of implementing technology cross the boundaries between the architectures, but that is because there are often two ways of looking at a problem. Below is a listing of some of the issues that must be addressed under each architecture. Again, you might consider some external help in getting this plan together if you do not have a skilled IT department or a resident CIO.
a. The Software Architecture
The software architecture encompasses the specific software packages that you will need to operate the business. In addition, you must work out the understanding of how these packages can and will work together. For example, are you going to use an accounting package or a spreadsheet to keep track of business finances? If the former, then you will need to ensure that you can export information from the accounting package into your particular word processor or presentation software in order to generate financial reports and presentations.
Again, if you have a larger firm, how will access to software work? Will it be installed on all the machines, or will software be accessed on a central server? Some of the key issues to be thought through are:
- Given the functions that we have described for the business and the goals of bringing in or modifying our technology, what software is needed?
- Who gets what particular software and in what order, and what licences are needed and for how many people? — now and as the firm grows.
- Who gets trained and who does the training?
- Who handles support?
- How is access to the software controlled?
- Do we have software currently that must be kept because it is essential to the business right now and replacing it would be to great a dislocation at this time? What does this mean in terms of working with new software we would bring into the firm?
- What is the implication on our current storage and file retrieval of moving to new software — i.e., can we read the old files with the new software, and if not what are our conversion costs? Furthermore what files/data should be converted?
b. The Hardware Architecture
Once you understand what software is required and how the packages will work together, the next step is to be clear about what machines, network equipment, backup and peripherals (printers, faxes, routers, etc.) will be required to support the software you have chosen to achieve your business objectives.
- Given what we want to do, and the software we want to use, and the estimated demand on the system, what hardware do we need to accomplish the project and corporate objectives?
- What hardware is needed to satisfy estimated future needs (which we took our best shot at figuring out when we were doing the project phase of the technology plan)?
- How is this hardware to be laid out and allocated in our corporate environment?
- How do we care for and support this hardware and who will do it?
- What standards are we going to adopt to ensure that all the pieces fit together and keep functioning when we add new components into the mix?
- Which manufacturer will we go with, and why?
- What equipment can we keep and what do we have to replace?
- How do employee home-based systems, hand held devices, and other mobile pieces of equipment fit into the hardware plan?
c. The Data Architecture
When we talk about 'data' we are talking about all the information that the organization captures or should capture including client lists, scanned discovery documents, opinions, summaries, briefs, emailed agreements, dockets, digital fax document copies, schedules, and more.
- What data are to be captured by the new technology?
- What are the data used for (e.g., scanned files for discovery) and where are they kept?
- How are the data organized and indexed?
- What is backed up and when, how often, by whom?
- What data or files will we convert to new software formats?
- Where will we keep the data?
- How will we access the data and retrieve it from the desktop?
- How will we backup and protect the data?
- How will the data be organized to meet our business needs?
- How will changes and edits to the data be carried out?
- How long will we keep the data?
- How will we handle client data versus our own business information?
- What will clients be able to access, and who can access client data from within the firm?
- What are the quality control procedures that ensure that the data is created or captured correctly? Who checks what?
d. The Management Architecture
Implementing software usually occasions business process changes. Even if you only buy a spreadsheet to manage a SOHO firm's finances, the daily or weekly processes of entering data about the finances and summarizing the information for tax and accounting purposes will change. The roles of individuals often change. Even in the one person firm the software purchase may result in a decision to have a part-time bookkeeper work with the software rather than the individual lawyer.
Managing the systems, people, data, and support is a piece of the plan that cannot be ignored. We need to be clear on who is managing what, and what the responsibilities of each is with respect to all the architectures — software, hardware, data, and the most important component — people.
Who is responsible for the hardware and the software and what are their responsibilities?
Who owns what data and who is the keeper of the data? In many cases the custodians of the data do not really 'own' the data. That is, the responsibility for nature and use of the data lies with a different group or individual than those who care for the data as a resource to be stewarded and protected.
Who can change and update the data and under what conditions?
What support is required to keep users using and systems working and who manages this?
What new skills have to be brought into the firm and who will be trained?
How will the training be conducted and what will it cover (given our defined business needs)?
Who is responsible for training, and will it be accomplished by in-house staff or consultants? Furthermore, where will it be held and what form will it take — video, live one-on-one sessions?
Who deals with the issues of privacy, liability, and accuracy with respect to information?
Back to Table of Contents
6. Implementation: Making it happen
a. Security Planning
Security needs planning like anything else. The security plan should cover at least the following issues:
- Physical security for equipment
- Lock up for software
- Procedures for installing and changing software and hardware
- Internet provider relationship
- Firewall, Internet router and virus checker allocation
- Data archiving, regular backup and disaster recovery plans
b. Professional Development Planning
The users and the support groups must be brought along with the equipment and software. Thus, a professional development plan that sets out training on the software and hardware is an absolute necessity. In addition, it needs to be flexible enough to allow the technical lawyer to cover what he or she needs, and the non-technical lawyer to move slower but achieve the necessary skills.
c. Financial Planning
The plan must also confront the fact that someone has to pay for the goods and services. Often the ultimate investment strategy is developed outside of the technology plan by those who control the investment levers. However, the technology plan needs to set out the investment timing and size of allocation before any dollar decisions can be made or executed. Thus, there is a need for the finance component of the company to be involved early in the process.
d. Set Up and Roll-out
Provide the 'how' after you have detailed the 'what' of technological change. Without it, your realism and credibility will suffer seriously. Work and equipment install as well as training and rollout must be staged in a realistic fashion, and some room left for unexpected conflicts of schedule, problems with installations and changes, and budget availability. Most implementations benefit from early involvement of some key users in the implementation strategy and development of these users as role models or technology leaders to assist the remainder of the staff.
e. Support and Maintenance
Support and maintenance must be accounted for in the plan. Otherwise, at the first sign of trouble, there will be a scramble that raises temperatures and likely doesn't solve the problem quickly and efficiently. For all likely support issues, the hardware, software and data owners need to know who is to be called. They need to know that there is a relationship with the service provider (internal or external) that they can count on for response within so many hours as set out in a maintenance and support contract. Mission critical software and hardware should have been identified and 'workaround' procedures thought through and written up.
f. Evaluation
Since change inevitably overtakes us, the plan should identify the owner of the plan itself and set out when the plan will be updated and who will be involved (by position, not necessarily by name.)
And finally, there is one last important, and likely difficult, step. When I go out to buy a car there is little problem recognizing whether I have been successful or not. Buying technology is not so simple. When you write your master technology plan or as part of the early planning process with a consultant, you will need to develop the Acceptance Criteria. If you remember, buying technology must relate to the specific business needs that you identified and then followed with a functionality listing. Thus you will need to work out the criteria against which you are going to evaluate whether you have acquired and put in place something that achieves the firm's objectives through this functionality. You need to be able to answer the questions — did we get exactly what hardware that we needed? — did we get the software we needed? — AND does it deliver the functionality we set out in our Functionality Statement? A system that runs too slowly for support staff to use, or provides functionality that is so complicated that no one will use it, is not what you set out to acquire and implement. Thus you need to figure out how you will know that you have been successful. A note of caution — don't pay for everything until you know you have what you contracted for.
Back to Table of Contents
7. Fifteen Steps for Successful Technology Planning
That's a lot to pack into a busy schedule. To provide a reminder, here is a checklist of the key steps covered in this summary:
- Get management to buy in to the technology planning process
- Give the responsibility to a CIO or corporate champion and possibly secure some outside help
- Conduct a systems audit and inventory
- Review the technology that is out there and establish the market leaders
- Prepare and get agreement on a vision statement that talks about the business goals of the firm
- Prepare a functionality statement that translates the business goals into specific projects
- Work out a reasonable cost estimate for the projects
- Generate a time estimate for each project and the ordered combination of all projects
- Work through the security plan
- Draft the professional development plans for users and supporting IT staff
- Make sure you have the financial plan in place and approved
- Create and get buy-in for the set up and roll-out plan including what the implications are on individual users
- Have your proposed Support and Maintenance plan in place
- Ensure that the evaluation plan and schedule has an owner in the organization
- Decide on how you are going to know when you are done each project and that you have the deliverables you believe you were seeking.
Back to Table of Contents
There is obviously more to the full technology planning process than the simple sketch give here. Firm size, budget, and even a firm's 'culture' will determine how much effort is ultimately put into technology planning. If you pay attention to the stages outlined here, you should have less of a battle than if you wander into the technology minefield unprepared.
Dr. David Brusegard is the President of The OSLO GROUP, a systems and analytics consulting firm located in Toronto.
Neither the author nor the CBA should be construed as endorsing any product or website listed in this article. The views expressed in this article are those of the author and do not necessarily reflect the views of the CBA.
In this document, any reference to "jurist" or "lawyer" includes, where appropriate, "Québec notary". |
|
|
