Peer to Peer Magazine

P E E R T O P E E R : I L T A ' S Q U A R T E R L Y M A G A Z I N E | S P R I N G 2 0 1 9 37 Scoping A big misstep early on may be not fully understanding the scope or constrained timeline for the project. Before embarking on the process, define success upfront. What does a successful outcome look like? Are you producing a recommendation to go in front of senior leadership for a decision? Or are you expected to come out with a decision and move into contract negotiations? What has been looked at before? Have the business owners considered buy versus build options, or has that decision been narrowed already? What and who is required in order to make the decision? All of these points will play strongly into who is involved at what point in the process, and the level of detail needed during the initial and deep dive demonstrations. A key measure of predicting a successful outcome is whether the right partnership between groups has been established, and whether roles and expectations are well defined from the start. Very rarely is a project purely a "technical project" or a "business project." Teamwork, communication and collaboration between Information Services/ Information Technolo and Business Stakeholders are key. If your firm has a Project Management Office (PMO), this team will facilitate the process so that all stakeholders can make a thoughtful decision for the long term. An assigned Project Manager, either from the PMO or selected from the working team, should create a charter that documents all of the goals, expectations, assumptions, roles and responsibilities, and other factors. Equally important is ensuring agreement by having key stakeholder and team members approve and sign off on the charter, because that document will continue to be your anchor and a reference point when other groups chime in or when peripheral requirements arise that would change the scope or deliverables. Requirements When people hear requirements, they may be tempted to rely upon a business requirement document ("BRD"), with high-level ability statements. While this serves as a valuable starting point, it is advisable to go deeper than requirement statements by outlining more detailed use cases, user stories, and workflows. A surface-level evaluation will not provide enough proof that the proposed solution will work as you expected or be compatible with your environment. In addition, be careful not to be content with repeating and documenting the current state. In most instances, your goal is to improve upon the existing workflow and technolo. From a change management perspective, take time to undertake the exercise of deconstructing and contesting the current state to develop the desired state and a wish list of enhancements. During this requirements gathering phase, all the business and technical stakeholders, and often a focus group of consumers, should be enlisted. This is not the time to take short-cuts or exclude potential contributors or benefitting individuals from the process. Developing the requirements is a time- consuming but essential process that should result in a veritable laundry list of ideas, encompassing critical must-have features and functions, as well as nice-to-haves. Thus, prioritization and weighting the requirements is the next step, and will be a key document used to create a scoring matrix for evaluating the vendors and their product capabilities. Having a checklist and questionnaire to complete during demos and pilots can ensure that you remain focused not on bells and whistles but on features and functions that really matter to you. By rating each vendor, you can look at specific quantitative content to compare vendors and support your decision. Vendor Research Once your goals have been clearly defined, and the development of key requirements is well under way, the team should research the contenders. Identifying leading products is easier than ever, thanks in large part to professional publications and websites. ILTA peer groups provide benchmarking opportunities, peer assessments, and client references that are invaluable. While each law firm is unique, getting feedback from others who have already purchased – or rejected – a product can be highly informative. Indeed, it may turn out that despite the desire to buy an off-the-shelf product, the buy versus build question will need to be revisited. RFI (Request for Information) Some literature questions whether an RFI is really worth the time, and whether it differs enough from the formal Request for Proposal. The purpose of an RFI is to collect written information about the capabilities of various tools early on to enable you to weed out products that do not meet core requirements. No one has time to sit through demonstrations of tools that do not come close to fitting your needs. It is often a waste of time to schedule product demos based on glossy brochures and jazzy websites. The RFI is an opportunity to send your questions out to confirm with vendors that their solutions are worthy of further investigation. A reputable vendor may even pull themselves out of the running if they see that their product does not adequately address your high-priority needs. Demonstrations and Pilots Once you have whittled down the contenders based on your requirements, your vendor research, and your RFI reviews, it is time to schedule product demos. Be careful not to skip the important step of planning the demos with the vendors. The presenter should not be permitted to do a canned sales pitch. The demo should be customized to meet your specific time frame, and the agenda should be jointly developed. If a large or senior group is attending, consider a full dress rehearsal or run-through to ensure that every attendee's time is respected and their questions and concerns covered. Insist that the vendor skip introductory material such as the business case, the legal landscape, and the history of

• Cover