Enterprise search sounds so powerful… can that be used instead?  Could you instead leave everything as it is, where it is, and apply Enterprise Search to make it accessible firm-wide?

I don’t know of a search solution yet, that eliminates the need for a DMS.

What does DMS do that ES cannot?

Creation, collaboration, history

1. Launch Internet Explorer
2. 

   Click the image to show the full-size version in a new window.

   Click the Internet Options toolbar button, which has a grey-white Gear icon. That’s labelled with highlight “1″ in this following image.

3. On the General tab, in the Browsing history section, click Delete… That’s labelled with highlight “2″ in this image.
4. In the Delete Browsing History popup, make sure that the second three checkboxes are checked. Note: the topmost option starts out checked. You should un-check it. Those are indicated with highlight “3″ in this  image.
5. Finally to commit these changes, click the Delete button in the Delete Browsing History popup, then OK in the Internet Options popup.
6. After a bit of a pause, the original Internet Explorer window should tell you with a message at the bottom of its window that the history has been deleted.

Point number two is a succinct way to restate my previous post “When is training not the answer?”  User errors are not always a sign of insufficient training – sometimes they are the result of bad solution design.

via Information overload? Maybe it’s bad design « Sandy’s CERSYS Blog

• Adapt your testing
• Look for families of bugs
• Is the fix worth the risk?

Numeric tests

Use numeric tests to find omissions based on unexpected causes. There should be 28 files in the A folder, 61 in the K folder, 4 in the Z folder. Write scenarios for both happy-path and exception. Check for things that are too long.

Why DMS is fabulous

After all, what’s not to love? Document Management offers many benefits to improve the work life of legal practitioners. For example:

• iManage WorkSite and FileSite integrate directly into Microsoft Word and Outlook.
• Documents are created and retrieved directly with the usual ‘open’ and ‘save’ toolbar buttons.
• Emails can be contributed by dragging and dropping many at a time; or, suggested filing locations can be chosen with a single click.
• Collaboration is suddenly the default option as the powerful IDOL search engine gives you google-like thoroughness in searching your colleagues contributions.
• Simply saving your content into the matter-centric folders automatically populates the client, matter, author, and date information that Records Management Administrators have been begging for.

The Dangers to your Project

So, what could go wrong? Surprisingly, some standard features undermine those valuable business goals or hinder the promised ease-of-use.  More about those later.

Even more dangerous than software gaffes are the following project definition problems.  Document Management should not be left to sell itself as a technology upgrade. It and Email Management require buy-in from all levels of the organization, and it requires a permanent shift in how information is processed.  The following Seven Deadly Sins of Information Governance are quoted from an article with that name at the eDiscovery Insight blog.  It delves into further detail on each point – click through to learn more.

1. Failure to obtain executive buy-in and sponsorship
2. Lack of participation from all stakeholders
3. No well-defined and documented program scope
4. Absence of distinct benchmarks from which to measure success
5. Insufficient Marketing
6. No long-term execution and management
7. Objectives are not realistic and/or ambiguous

from Seven Deadly Sins of Information Governance

Does your Document or Email Management project suffer from any one of those flaws? Contact us at Cersys – we have years of experience in introducing and upgrading technology for law firms or legal departments.  We can help your project efforts stay focused on the crucial success factors while deploying the software itself with a minimum of fuss or disruption.

Use cases and user scenarios

Use cases: common thread

Use cases and following scenarios play an important role, tying together a project from requirements to launch:

• communicating with the customer during requirements definition. They are very useful as an artifact resulting from user interviews… shows that ‘we heard what you told us’.
• structuring the demos during development
• inspiring end-to-end test cases for User Acceptance Testing
• providing scenarios for training

The scenarios should be reasonably abstract so that it is applicable to both the pre-project workflow, and how things behave with the project once delivered.  These overarching scenarios will show commonality with old and new, and even improvement with the new system.

The goal of our use cases is to describe ALL of the project scope at in strategic, summarized, business terms – in order to get customer buy-in that the solution describes the in-scope functionality. In other words, it’s a different slant on the requirements, and a more effective tool for communicating and getting agreement.  Specific exceptions, variations, and contradictions are explored and documented as a Business Use Case is expanded into Business Scenarios and Functional Scenarios.

Functional Scenarios are intended to be refined iteratively.

Repeat for the reasonable technology scenarios in each stage.  Spend more time elaborating the most important scenarios, and the most likely ones to be implemented.

The role these business use cases play is that you can show how this was carried out in the old world (often in multiple ways), and then the recommended way(s) to accomplish it in the new world, and how it’s managed through the co-existence transition.  For our particular purposes, we want to help build distance from the ‘old way’ of doing things – PST files, flat-space filing, etc.  So, it’s preferable to frame the lawyer’s goal as ‘I keep track of a matter’s emails’ rather than ‘I use a PST file’.  By describing it abstractly, we emphasize how we are continuing to meet their needs, vs highlighting that we are taking away an ability to use a PST file.

How a use case evolves

In their first incarnation, user scenarios should describe what the user is accomplishing, in terms of the user’s work-related goals.  Few lawyers would describe their lawyering as ‘I accessed a folder this morning, then had to work with some databases’.

So for example, here are informal imaginary comments from the customer that would each be slightly formalized into a User Scenario.

• Lawyer says: I like to keep together all the emails I send on a given matter, and also the emails I receive.
• Lawyer says: Sometimes I need to get a particular email I sent regarding a matter, knowing only the rough timeframe that I sent it. Other times, I need an email that someone else sent.
• Assistant and Lawyer: Lawyer marks up a draft. Assistant makes those revisions, then returns it to the lawyer for review. Lawyer OKs it and it’s sent to the client.
• Lawyer says: I need to find the stuff I am working on currently, whether in one matter or in several.
• Assistant: I have to take care of email for 2 different lawyers (filing to matters).
• Lawyer says: find me that document that Chris did for client x about a blah three or so years ago.
• Assistant (or associate) – I need to get at what ‘the boss’ is working on for a given matter.

The difference here is that a user scenario applies to the practice of law, and often consists of multiple steps: it may not mention or even require software. In fact, if there is only one (software-based) way to carry out a user scenario, then that scenario is too specific to be a business use case.  A pet example of a specific software action is ‘Relate document A to document B’.  Why? Who? When?

More background on user stories

Are user stories better than other types of requirements specification? It depends on the situation, but in a collaborative environment, my experience leads me to say yes.

User stories will not make your project agile, and the lack of them will make it challenging to become agile. However, user stories encourage a number of principles from the Agile Manifesto:

• Welcome changing requirements, even late in 
development. Agile processes harness change for 
the customer’s competitive advantage.
• Business people and developers must work 
together daily throughout the project.
• The most efficient and effective method of 
conveying information to and within a development 
team is face-to-face conversation.
• Working software is the primary measure of progress.

via Defining Requirement Types: Traditional vs. Use Cases vs. User Stories | TechWell.

 

And Dilbert: design