Archive by Author

How to Survive Complex Projects, Part 5: Getting Your Testing Right

20 Apr

By Andrea Alliston, Partner, Knowledge Management, and Nicola Shaver, Director of Knowledge Management, Stikeman Elliott LLP

In part 4 of this series, the authors guided us through implementation and development. Ed.

Once your platform has been implemented and handed over to your team, you will need to make sure that everything works the way you want it to work. After all of the effort and time you have put in, the last thing you want is to fail now. This is where testing comes into play.

What is User Acceptance Testing?

Unfortunately, we know from experience that if KM does not conduct the testing, you can never be certain the product you hand over to your users will work as they expect it to. This is true regardless of how comprehensive the IT department’s quality assurance testing is. The hard truth is that IT professionals see things differently than most users. IT people are not lawyers and do not think like lawyers. As a KM professional, your job is to operate between the technical and legal realms to evaluate whether your users will be able to incorporate into their daily practice the new platform as designed. This crucial step is called user acceptance testing (UAT).

The form and quantity of UAT the KM team performs varies enormously from firm to firm and project to project. We have worked in firms where very little testing is done before launch and in firms where massive testing is done. In truth, the proof is in the pudding – the more effort you put into UAT, the better your outcome will be.

Where do you start?

Our first step in UAT always is to create a test plan. We find this so indispensable that we now create plans even for testing the most minor upgrades to a platform. When creating the test plan, return to your requirements and use cases developed for your business case. You should plan to test every element of functionality a user would touch, understanding the desired outcome based on your requirements. For example, in our search system we determined that ensuring that a filter worked when applied to a set of search results would not be sufficient. Instead, we also needed to check that the list of values for each filter was correct, we could both exclude and apply filter values, the “or” (rather than “and”) logic of the filter values was in place when multiple filter values were applied at once, and we could both scroll through and search for filter values.

Our test plans usually outline a process where each team member mimics a user’s journey through the platform based on our use cases. Depending on what we are testing, we may allocate roles to different testers, with everyone following a slightly different journey through the platform. For example, partners likely use most platforms differently than legal assistants and you need to ensure the functionality works equally well for both. Role-based testing helps you to confirm that your new technology is ready to be released to everyone in the firm.

People doing the testing should note failures in not only pure functionality, but also design. An IT professional testing a grid view may feel that clicking on a column heading and having the results sort is just fine. But, a KM professional will likely recognize that unless a symbol indicates that sort functionality is available, most users will not know the option exists. Your requirements likely included this need early on, but testers should be on the look-out for its having made its way into the actual build.

Because our firm is Canadian and has a major office in French-speaking Quebec, testing bilingual functionality is vital. Recognize and prepare for the fact that your firm may have its own unique jurisdictional requirements or other complexities that must be addressed through a customized UAT process.

Allow sufficient time for UAT

Depending on the complexity of your project and testing, UAT may take some time. In our experience, no test phase ever goes without hitches. Assume you will have multiple issues to report and some elements of the functionality will not work properly on first review. Also prepare for substantial back and forth with IT and the vendor as you work through the issues that testing reveals. During our enterprise search project, we completed several rounds of testing for each component of the project.

Improve inter-departmental communication

Perhaps the most important takeaway from our major projects has been the importance of communication. Communication is critical during testing and it is hard. Communication among team members and between KM and IT, the firm, and external vendor all are critical. Most communication challenges that arise between your team and IT likely can be improved through mutual empathy and understanding.

As observed, most IT professionals speak a different language than legal professionals and you must account for this in the communication style you adopt between departments. For example, during testing, it is tempting for individuals who find major issues to want to report them to IT at once to be addressed quickly. Of course, in some instances this may well be appropriate. But, we have found that waiting to report all issues together generally works better. One of our team members collects feedback from everyone else, consolidates it into a single spreadsheet, and sends it to IT. Every piece of feedback is numbered and, wherever possible, accompanied by screenshots. We have found that the words we used to describe the problems we find often are insufficient to communicate those issues to IT. In fact, we have been tempted to sit beside our IT colleagues and show them what we have experienced on our screens. This rarely is the best use of anyone’s time, nor should it be necessary as visual props should abate confusion and frustration.

Lessons Learned

Engage multiple testers: People have different aptitudes for testing and technical detail. In the same testing round, we have had someone report that everything looks great, while another person reports over 25 issues. So, you will need a team of testers for UAT. You simply cannot do this on your own.

Understand your team’s limitations: During our enterprise search project, the KM team tested the system’s ethical walls compliance. Even though we managed to do it, it was needlessly time-consuming and, in retrospect, this should more properly have been handled by IT. We would not take this on ourselves again. So be realistic – some things are better left to IT.

Know when to stop: After you have signed-off on a component of the project, stop testing that component’s functionality. It sounds simple, but letting go and trusting that the fixes really are in place can be difficult in practice.  Now, if in using the platform you stumble across new issues, these of course must be reported. Otherwise, encourage your team to trust your firm’s IT and the vendor and move on to the project’s next stage.

Coming up in part 6: In our next post, we get to the exciting part – how to prepare for launch and take-off.

How to Survive Complex Projects, Part 4: A Marathon, Not a Sprint

5 Apr

By Andrea Alliston, Partner, Knowledge Management, and Nicola Shaver, Director of Knowledge Management, Stikeman Elliott LLP

In part 3 of the series, the authors walked us through the key steps in planning complex projects. Ed.

With a plan of attack in place, it finally is time to start on development and implementation. The complexity of your project will depend on several factors; but, no matter whether you are implementing an out-of-the-box or highly customized solution, substantial KM technology projects usually involve an intensive period of technology development.   Enterprise search – aggregating information from multiple sources and presenting it in a user friendly way – is inherently complex.  So, we knew that implementing our project would not be easy.

KM Involvement in Development and Implementation

Even with an out-of-the box solution, you will have options for how different aspects of your project can be implemented. This becomes more complex if you wish to customize the solution.  In our case, we increased the complexity by deciding to implement a new taxonomy tool and KM content management tool in parallel with our search implementation.

In the throes of a complex project, forgetting what you have decided and why is easy to do.   Combined with developers bombarding you with questions regarding the functionality you want, this can quickly overwhelm you.  As observed in an earlier post, having documented detailed requirements was our saving grace in these situations again and again.

A difficult reality in development and implementation is making compromises. Even with the most careful planning, nothing goes perfectly and being told that the design you have envisioned cannot be achieved is frustrating.  What do you do?  You go back to your design principles.  You may recall that in our search project our overarching theme was a relentless focus on user experience.  So, we always chose options that would best support the user experience, even if those options were not perfect.

Data Integration

Because very few KM projects involve stand-alone technologies, a heightened demand for tighter integration across multiple platforms and data integration become key aspects of most projects.   In our implementation, we integrated as many data sources as possible into search, which proved critical to improving relevancy. Those data sources included our InterAction contact management platform, Aderant financial system, matters and experience database, website, blogs, document management system, and KM content management system.

But, integrating data from multiple sources brings its own challenges. In our case, data was sometimes populated from the wrong system or from the wrong field in the right system, which required a bit of detective work to sort out. Another challenge was working with the owners of some of the data to address inconsistencies that the search project revealed.   Enterprise search and other technology projects cast a giant magnifying glass over your data (and its warts). You need to be prepared to address issues that might arise.

Lessons Learned

Manage expectations:  Highly visible, significant technology projects often lead to high expectations.  Throughout our development stage, we managed stakeholders’ expectations with regular updates and early demonstrations.

Tune and tweak: Do not be afraid to spend time making small tweaks that have a big impact.  One of the most valuable efforts we put into our project was fine-tuning relevancy.  Although taking the time mid-implementation to focus on relevancy was difficult, doing so significantly improved the user experience.

Master your metadata:  One reason we were able to identify incorrect data was that we had prepared a detailed data map listing all of the metadata appearing in the search application, including what it should look like and where it was expected to come from.  We revisited this (and other) documentation throughout the development stage.

Coming up in part 5: In our next post, we look at the role KM can and should play in testing complex KM technology projects.

How to Survive Complex Projects, Part 3: Chunking to Completion

21 Mar

By Andrea Alliston, Partner, Knowledge Management, and Nicola Shaver, Director of Knowledge Management, Stikeman Elliott LLP

In part 2 of this series, the authors examined how to develop requirements and focus on them throughout complex projects. Ed.

Now that you have your business and functional requirements in hand, how do you to turn them into reality? It is time to start tackling the practical aspects of the project.   While it may be tempting to jump in and just get going, spending some time up front on planning is well worth it.

Get Past the Fear Factor

Where do you start?   With high-stakes, complex projects, the pressure to get it right is daunting and thinking about all of the tasks that need to be accomplished can be overwhelming. In considering the challenges that lie ahead, you may feel too many hurdles will impede implementation. You may also wonder if you have sufficient resources to tackle all parts of the project or worry about the change management required after the platform is implemented.  How to do you go about rationally planning under these circumstances?

One approach is to start your planning by looking first at your desired outcome and working backwards. Ask yourself what needs to be done to achieve your goal?   Another approach – our favourite – is to break the project into chunks – components, phases, and finally detailed tasks.

Identify the Moving Parts

Think about each major component of the project and set these down on paper. We like to use something visual like a process map or post-it notes.   For the search project we developed a visual setting out the various components of our project, the main phases for each component and the dependencies between them. Each project component was colour-coded and each phase was numbered.  This was less about the detail (that is what the plan is for), and more about keeping a big-picture perspective on the project.

The major components of our enterprise search implementation included the following.

  • Taxonomy Management Tool
  • Taxonomy Development
  • KM Content Management Tool
  • Technology Development
  • Content Migration
  • KM Content Clean-up
  • Launch and Roll-out
  • Within the broad components of any project lie many phases and discrete tasks. You need not identify all of these at the beginning, so create a project plan that allows you to add detail as the project develops. If you have no preferred vendor at the outset, your project plan will likely include demonstrations of various products and a proof-of-concept before a purchase decision is made and implementation can start.

Assign a Project Manager

Your plan is nothing without a strong project manager at the helm throughout a complex project.   If you do not have project managers at your firm, consider asking your vendor for assistance or hiring someone on contract.  You can also look within your own team for someone with good organizational skills who could perform basic project management, like plotting the tasks of each phase of the project against a timeline and keeping track of what has been completed.

The project manager should attend the project meetings with your team and take notes, adjusting the timeline as needed and acting like a human “tickler system”, sending reminders as particular tasks come due. Becoming embroiled in the project’s details and losing sight of the bigger picture is all too easy. An effective project manager can prevent you from getting lost in the weeds by reinforcing your original strategy and perspective; this will help keep your team focused.

Expect the Unexpected

In any large project, issues inevitably arise that push back the project timeline. Knowing at the start where delay will come from is nearly impossible; but, be ready for hurdles and, if possible, build some flexibility into your timeline.

We found that the key to dealing with delays is to communicate, among not just the project team, but also the stakeholders. If the original launch date no longer looks feasible, try to set a realistic new launch date and strive to meet that goal. Adapting as issues arise allows you to keep moving forward, rather than being knocked sideways by every complication.

Lesson Learned

Plan, plan, and plan: The importance of planning cannot be understated. Remember Henry Ford’s words: “Nothing is particularly hard if you divide it into small jobs.” Have your project manager hold regular meetings with the core project team so everyone understands what they need to be doing. During major projects, we meet inter-departmentally at least biweekly and more frequently if we enter a particularly intense phase of the project. We also hold weekly meetings with the KM team to keep the project on course.

Take pleasure in small successes:  We used our diagram of the project to keep us engaged.  We felt a sense of great satisfaction each time we could cross off one of the task bubbles as completed. Celebrating the small successes along the course of a project helps keep your team motivated for the long haul.

Communicate: Any complex project involves stakeholders from multiple departments, raising all kinds of communication challenges. We have found it critical to ensure that the information coming from our own team is consistent. In our enterprise search project, we met as a team before but on the same day as our meetings with IT to ensure were all on the same page before reporting to the other department. By maintaining our lines of communication and ensuring that the messaging coming from KM was clear, we were able to improve the flow of information between departments. Having said that, we know we still have some way to go. We can only hope that our next major project will be the one where we get the balance right.

Coming in part 4: In our next post, we look at the development and implementation phase of a complex project. Rest up.  You are going to need it.

AI Round-up: A Guide to ILTA’s Artificial Intelligence Content

17 Mar

Joe Davis has graciously allowed us to cross-post his recent compendium of ILTA content on artificial intelligence.  So, don’t miss this second opportunity to catch up on some of the latest thinking on this hot topic. Ed.

By Joe Davis, Project Consultant, Prudential Financial, Inc.

OK, so Watson won “Jeopardy!” back in 2011. That’s ancient history in technology years.  ILTA provides a wealth of programming about the current state of affairs in Artificial Intelligence that will benefit law firms and corporate legal departments.  In the future, I’m sure we’ll have a bot to curate all this content for us.  In the meantime, below is a sampling of some of ILTA’s best AI-related content from ILTACON, Insight, webinars, white papers and Peer To Peer.

Webinars

Beyond the Hype: Artificial Intelligence in Legal Research
This webinar, sponsored by ROSS Intelligence, features ROSS CEO and co-founder Andrew Arruda discussing how the company was born out of a desire to get from questions to answers more quickly.  He points out that even though AI is still in its “Model T phase,” the Model T still beat the horse in many ways.  Bill Caraher from von Briesen & Roper talks about what made his firm interested in the technology, and shares with moderator Beth Patterson the kind of firm culture that is required for this technology to catch on.  Be sure to listen for the last question to hear about how ROSS is practical for small firms, solo attorneys and pro bono work.

Nothing To Fear: How Artificial Intelligence Can Benefit Law Firms
Peter Wallqvist of RAVN Systems offers this solo take on AI, including a look at which kinds of AI RAVN and other AI companies focus on. This webinar offers the most in-depth explanation of AI on this list, so be prepared for an academic, but very thorough, treatment of the subject.

Articles

Reframing the AI Question in Law by John Alber
ILTA Futurist and retired Bryan Cave partner John Alber makes the case that the legal world should focus on using AI (and technology in general) to improve its service model. Tame Regulatory

Chaos with Cognitive Technologies by Eric Laughlin
Sanctions for improperly managed compliance requirements cost corporations more than $20 billion per year.  Author Eric Laughlin of Thomson Reuters offers a perspective on using AI to manage regulatory complexities.

When Machine Intelligence Joins Your Professional Services Team by Mark Noel
Mark Noel of Catalyst Repository Systems provides a good introduction to the advantages of using Technology Assisted Review (TAR) as part of your e-discovery process.

Artificial Intelligence Systems and the Law by Andrew Arruda
ROSS Intelligence CEO/co-founder Andrew Arruda offers a primer on the different categories of AI, along with a brief introduction to the ROSS platform.  Also included in this article are 10 predictions excerpted from a 2014 ABA Journal article by Paul Lippe and Daniel Martin Katz about the way Watson will affect the legal profession.

Audio

The Exponential Law Firm: Unlocking the Growth Potential of AI and Disruptive Thinking
Technology isn’t necessarily the key to being exponential, according to Fast Future’s Rohit Talwar.  In this session from Insight 2016, Talwar talks about how the legal profession needs to focus on three things: what is vital in the next 12 months, where innovation will come from in the next 3 years, and the an “early warning system.”  Overall, he is confident that “there has never been more opportunity for the legal sector than there is being created by science and technology today.”

Legal Innovation: More Than Just Artificial Intelligence
As the name implies, this Insight 2016 panel session is about more than just AI.  Panelist Jan Van Hoecke, CTO and Co-Founder of RAVN Systems, outlines the challenges to innovation and discusses a case study in which the risk and compliance department of a top-50 financial services company leverages AI to reduce its risk.  Could this be a potential new line of business for law firms?

Choosing the Right Artificial Intelligence for the Job
Panelists Sylvia Leblanc, Dera Nevin, Noah Waisberg, Julian Tsisin and Peter Wallqvist cover a lot of ground in this ILTACON session, including weak vs. strong AI, the trailer for the film Morgan, getting rid of “the ugly bits of lawyering” and Sharknado.  One conclusion: it is rocket science.  Tip: check out this video and this follow-up before listening to the session.

The State of Play of Artificial Intelligence in Law?
Michael Mills of Neota Logic discusses the current state of affairs and the players within the Legal AI space.  Be sure to take a look at his slide deck, which contains some useful diagrams.

Face Your Fears: Embracing Change in the Legal Environment
Consultant Ann Gorr leads this panel featuring Dennis Garcia from Microsoft, Matt Blaine from Davison Eastman & Munoz, and Jim Merrifield from Robinson Cole in a lively discussion on “how to be a grown up law firm.” Along the way, they cover “conversation as a platform,” augmented reality, driverless cars and Pittsburgh vs. Scranton.  Two resources mentioned in this session: Klaus Schwab’s The Fourth Industrial Revolution and UC Hastings’ Disruptive Innovation: New Models of Legal Practice.

Grading Susskind: The State of Legal 20 Years After the “Future of Law”
While these panelists probably shouldn’t give up their day jobs to pursue a career in comedy, they do get credit for putting together a creative alternative to the standard panel discussion.  In the style of NPR’s Wait Wait… Don’t Tell Me!, this session evaluates the predictions Richard Susskind made 20 years ago in his book The Future of Law.  Host Ryan McClead of HighQ (now with Neota Logic) and panelists Susan Hackett of Legal Executive Leadership, Sam Nickless of Gilbert + Tobin and Dan Lear of Avvo discuss the present and future of legal technology.  You’ll also learn what three lawyers and three MBAs on a train, two lions, and one elephant may or may not have to do with the founding of the American Corporate Counsel Association.

Mutual Challenges and Successes: A Large Firms Discussion Forum
This session, moderated by Tim Golden of McGuire Woods, features three CIOs from large firms (Doug Caddell of Mayer Brown, Ash Banerjee of Hogan Lovells and Curt Meltzer of Chadbourne and Parke) covering a variety of issues that pertain to large firms.  The discussion turns to AI at the 17-minute mark.

Using the Right Data To Drive Your KM Program
Kingsley Martin and Karl Haraldsson examine the journey from Profiling to Search to Analytics to Predictive Coding and Machine/Deep Learning.  This session starts with a strategic view, but includes some very tactical ways to start quantifying legal practice.  Highlights include “don’t start with the Death Star,” “If I knew… I would do…”, buying a car (in four acts) and insight into the importance of data visualization.

Watson, I Need You! Augmented Intelligence for Legal

IBM’s Kyla Moran offers a broad perspective on Watson.  While this ILTACON session is light on legal-specific applications, it does offer insight into how Watson works.  Ginevra Saylor, National Director of Knowledge Management for Dentons, asks some interesting questions as moderator, including why the other Jeopardy contestants were able to answer any questions at all.

How to Survive Complex Projects, Part 2: Commitment to the User Experience

7 Mar

By Andrea Alliston, Partner, Knowledge Management, and Nicola Shaver, Director of Knowledge Management, Stikeman Elliott LLP

In part 1 of this series, the authors discussed how to decide whether to pursue a major project and convince leadership of its value. Ed.

With decision making and project approval behind you, the next step is to start work on the design and detailed requirements.   In our enterprise search project, the research from the decision-making stage made it clear that we had much work to do to improve our user experience.  As a result, the theme we wanted to capture in our design and requirements was a relentless commitment to user experience.   The underlying theme for your projects may be different.  The point is to understand your theme and focus on it throughout the project.

Design for Success

The design phase of a software development project can be defined in many ways. In KM projects, design usually is about matching your users’ needs with the applicable technology’s functionality (and constraints).  Our strategy of putting the user experience first required us to engage a UX expert to help us to create user journeys, identify desired outcomes within the limits of our technology platform, and make tough decisions about our KM content and its management.  Do not underestimate the value of specialized expertise at this point in a project.

In addition to seeking expert advice, now is the time to engage your users and have them get their hands dirty. We used two techniques with our users.

  • We held card sorting workshops for lawyers to determine the system’s structure from a content perspective.
  • We convened focus groups to gather feedback on our wireframes and proposed functionality.

A set of design principles that set the tone of the project should come from the design exercise, along with the details needed to prepare the requirements. As one designer notes, “Design principles articulate the fundamental goals that all decisions can be measured against and thereby keep the pieces of a project moving toward an integrated whole.”  Your design principles should reflect your particular project; ours were the following.

  1. Keep the interface simple and intuitive
  2. Restrict filters to a maximum of 7, plus or minus 2, per page
  3. Avoid customization where possible
  4. Allow for flexibility in accessing content
  5. Provide a bilingual interface
  6. Include all filters as part of the search snippet

Business and Functional Requirements

Projects are more successful when a clear set of business and functional requirements are documented; they ensure that the business stakeholders, the internal technology team and the vendor are on the same page. Where do you start?

Some of you will be fortunate enough to have a business analyst in your firm. Indeed, engaging business analysts in law firms either on a contract or permanent basis seems to be on the rise.  But, what if you are not so lucky? Not having a business analyst role, we used the KM/UX consultant we were working with and our internal KM resources to create the needed documentation.

Our business requirements were comprised of annotated wireframes, descriptive narrative, and spreadsheets (see screen shot from one of the pages).   However, depending on your project, you will also need detailed functional technology requirements for the developers.  Once a draft is ready, the requirements should be circulated and reviewed in detail with both your technology team and vendor.

Lessons Learned

Stick to the design principles: We needed to simplify various aspects of our search implementation to be responsive to user feedback.   Our mantra became “less is more.”  While it sounds easy, it was very difficult to give up certain content management practices we had used for years.  We constantly second guessed ourselves and worried about making a mistake, getting it wrong, and losing what we once had.  We needed to be quite disciplined with this part of the project and, so far so good.  No one misses anything we took away and the benefits of sticking with our design principles are paying off.    

Discuss with the vendor: Once we had a sense of our desired design, we had early discussions with the vendor to explore options for some key functionality and get the vendor’s input on design elements we were considering.  The goal was to tap into the vendor’s expertise and address any potential issues early on in the project.

Get into the details:  Our business and functional requirements were developed when we had time to be thoughtful about what we were trying to achieve.  Being able to go back to those requirements when we were later under pressure gave us confidence about our decisions and the right path forward.

Coming up in part 3: In our next post, we look at project planning as a critical step in putting your design and requirements into action.

How to Survive Complex Projects: Search, Intranet and Beyond (a Multi-Part Series)

27 Feb

complexBy Andrea Alliston, Partner, Knowledge Management and Nicola Shaver, Director of Knowledge Management, Stikeman Elliott LLP

So, you are ready to tackle the big one – enterprise search, an intranet, an experience database, a client portal, a collaboration tool – or, in other words, a highly visible, costly project where the pressure on you to get it done right is daunting. In this series, we look at surviving and successfully implementing a complex technology project in a law firm.  We have leveraged our experience with our own enterprise search (STELLA KM), but the discussion throughout the series is both project and technology agnostic.  We have also strived to share some lessons learned that apply across a range of projects and technology implementations.  In this first post, we look at the critical decision making stage.

Part 1:
How Do You Know If You Need It?

KM practitioners have a gut instinct about what tools and resources would work well in their organization. This is based on a deep understanding of what they have today, their users’ needs and their firm’s culture.   Unfortunately, most of us would have a difficult time selling management on a significant investment in people, processes and technology based solely on our “gut.”  So, you need to do the work – researching, analyzing and developing a business case.  The question we faced was whether we needed to upgrade or change our existing platform.

Researching User Behavior

To start, you need to understand what your users are currently doing, whether they are using your platform and, if so, how they are using it. In our case, we also wanted to understand if they were using work-arounds or other means to find information. Three research methods were used.

  • Analytics: While the analytics were rudimentary, they enabled us to gather information on overall usage, top users and behavior following a search.
  • Surveys: These allowed us to gather information from users on a range of questions, including what they would change if they could.
  • Interviews: These provided a deeper understanding of how people were actually using search. We reviewed the search logs at night to find unsuspecting subjects for interviews the next day about their use of STELLA KM.

Using all three techniques gave us a nuanced view of our current users and what they were doing (and not doing) and how they really wanted search to work.

Creating a Picture from the Analysis

What does your research tell you? Reviewing the information with an internal group or data expert or someone from outside your firm can provide insights that you may not otherwise see.  We did the latter, engaging a KM consultant to provide the objective critical view that we needed.

The key to analysis is distilling your research into core themes or messages that will enable you to make a decision about the direction you want to take. They should be framed in a way that will resonate with your users if you decide to push forward.

In our case, the result was two-fold: users reinforced the importance of search, many of them citing it as an integral part of their practice; at the same time, there were aspects of search that they wanted improved.  These improvements included the ability to find content more easily based on practice area and separation of precedents, research, CLE and marketing content. Other feedback highlighted a need to simplify.

Crafting a Compelling Business Case

The final stage is preparing and presenting the business case.   We would like to point you to the perfect template but (confession) ours vary depending on the project and circumstances.  Generally they include background information, the objective or rational for the project, use cases, the impact on lawyers and other stakeholders, the technology approach and an estimated timeline and budget.  In situations where we are considering a new initiative or technology we do not currently have, a competitive analysis is also critical to answer questions like, “who else is using it?” and “what are our competitors doing?”

For the search upgrade, we presented the results of our user feedback at the opening of the business case as it was the most compelling reason for the project. We also highlighted the project’s benefits and the technology risks of not proceeding.

Lessons Learned

Keep an open mind: As noted above, many KM practitioners will have a good idea about what their organization needs from a KM tools perspective.  However, it is critical that you put that aside and have an unbiased look at the results of the research to guide your next steps.  Our research made us realize that the upgrade and improvements were more critical than we had anticipated.

Leverage your data:  No matter how poor you think your data is, it is data and you can use it.  Even a rudimentary statistic like how many searches are run can be turned into a statement such as, “this means that each associate runs approximately X searches a day.”

Tell powerful stories: As important as statistics are, storytelling and personalization are even more powerful.  We used quotes gathered from the survey questions to populate the business case.  We also made the information personal to decision makers by using stories and anecdotes from their colleagues and peers.

Coming up in Part 2: Now that you have the green light, what comes next? In the second post in this series, we look at the design and requirements phase.

 

The Evolution of IT Geeks into KM Geeks

10 Feb

evolutionBy Kathryne Valentine, Knowledge Management Solutions Manager, Dentons US LLP

As a Knowledge Management (KM) Solutions Manager, I am often asked what I do and how I arrived where I am today. Like many of my generation, I fell into information technology (IT) accidentally.  Particularly on the IT support-side, people suddenly found themselves in this new role simply because nothing came before.  It wasn’t until people with no background in technology were told to use computers to do their customary work and were expected to somehow know how to do so that new support roles began to emerge, roles for trainers, documentation writers, service desk analysts, interface designers, and all around IT geeks.  Remember, this was in a time long before Google and YouTube videos were around to help interested people quickly learn how to perform discrete tasks.

I believe IT people fall into two groups. The first group is the IT machine-people; these are the engineers, programmers, network geeks, and many others who relish the mechanics and general geekiness found in machines.  We really need these people, but often they are reserved and prefer talking to other people – especially end-users – only if and when necessary.  If they could or would articulate it, they might say something like this, “Please don’t make me explain this to a user; we don’t even speak the same language.”

And, this is where the second group of IT people comes into play. The second group, which includes me, is the IT people-people.  We are those who now fill the new roles that sprang up in the late 1990s and early 2000s as people in all work environments were permitted and then encouraged to interact directly with computers to do their job.

I remember seeing the first IBM PC on the floor of the large insurance company where I worked, standing out there all alone, and wondering, “What would you do with that thing?” No one knew.  We had to figure it out.  At about the same time that machine rolled in, I happened to be looking for a change from the training I had been doing on the sales side of the business and the company sought someone who knew that side of the business but could learn about computers.  So, for the next three years, I travelled around the country talking to the salespeople about how they could use computers to help automate much of their manual work and become more efficient.  Of course, the salespeople were receptive because greater efficiency means more productive, which means more money in their world.

After this program was introduced, the company next needed a system for tracking and managing support calls from the field and – voila – the first help desk was born. In those days, most of the calls had nothing to with things not working; rather, the calls came from people looking for ideas on how to better manage and use the information they were generating.

I next became an entrepreneur and entered the completely different real estate development and construction project management industry. We too bought a computer and printer, as well as a new miracle technology – the facsimile, or fax, machine.  Again, we had to figure out how to incorporate all of these new gadgets into doing business.  In this interlude, I needed to teach myself how to use the programs we bought to run our business, including the likes of WordPerfect, Lotus 1.2.3 and Quicken.   We weren’t learning the programs to become proficient in the programs. Instead we were trying to learn how to use them to solve real business problems and manage our growing business.  This taught me the most valuable lesson that I have carried throughout my IT career: IT people in support roles need to focus on how people work and the specific tasks they need to accomplish.  I also learned to quickly identify the most tedious tasks in people’s work and ask, “Is there a better way to do that?”

Fast forward several years and I found myself developing classroom training for federal government agencies in Washington, DC, which led to working with law firms in training, help desk support, and overall problem-solving for impatient and frustrated lawyers whose primary complaint was, “I just want to practice law; I don’t want to have to become a rocket scientist to use this computer.” There, I learned a very simple lesson that I have applied ever since: find out what the person wants to accomplish, ask questions, and listen.

By asking questions and listening closely to the answers, you learn the business that you support. You simply cannot be effective in technology support if you do not understand the business the people you support are immersed in every day.  Fortunately, this is precisely where IT people-people shine. We like communicating with our end-users, we like solving real business problems, and we like discovering new ways to perform tasks.  And in the practice of law, the observation made earlier about working in sales rings equally true:  more efficient means more productive, which means more money.

So 1000 or so words into this post, you may have noticed that KM hasn’t reappeared since the first paragraph. Where and how does KM come back into the story?  Many years of approaching IT support from the perspective of analyzing and understanding how people work to help them solve real business problems made for a natural and seamless transition into KM.  When the large firm I was working in combined with another large firm, team and role realignment opened the opportunity for me to move from IT into KM – another field that hadn’t existed and sprang into prominence at some point while I was out there in the working world minding my own and other people’s business.

In KM, the same rules apply. Doing your job well requires focusing on and getting to really know the business, what it does, how it makes money, and what its goals and visions for growth and sustainability are.  You need to know how all of this translates into the needs of the people doing the actual work. And, you need to remember that these people generally have no background in either IT or KM and likely have no interest in necessarily learning much about either.  They simply want to get their work done well.  Once you know and understand this and find out what their current problem or need is, you can identify better ways to accomplish the task at hand and explain the benefits of doing the task differently.  When approached this way, IT support and KM make their end-users happy and productive. And, they will return to us again and again with more tasks that need to be done in a better way.