05/17/2010

Documentation for Application Development

Tags: IT Project Management General

Filename: j0230374.wmf
Keywords: businesses, businessmen, computers ...
File Size: 16 KB

Have you ever wondered what types of documentation you should have created or made sure that you have captured when working on a new application? Regardless of the Language being used: C, C++, Visual Basic, Java, JavaScript, HTML, Fortran, Cobol, Pascal, Perl, .Net, ASP, Lotus Script, Assembler and more… These documents could definitely apply.

This list is in no way complete, you may find that there are other types of documents that you would want to have for your application, or you may also decide that there are documents mentioned here that are not relevant. Regardless, ensure that whatever documentation you create or capture helps to establish your ownership / appropriate rights to the application as you have developed it.

1. Application Specification Documentation

a. Requirements Documentation
 - Provide the original documentation outlining the basic requirements for the System. (Include Functional and Non-functional Requirements)
 - Functional requirements describe the functions that the system is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities.
 - Non-functional requirements are the ones that act to constrain the solution. Non-functional requirements are sometimes known as quality requirements.

b. Design Flowcharts, Process maps, Documentation related to:
 - Functional/logic view of Application(s):  This documentation should cover the overall (high level) view of the various functionality / features that you want the application to meet.
 - Code/module view of Application(s): This documentation should cover the interactions between the code modules defined in the requirements documentation. Items may include communication / API, data transfer, transfer of application control, integration to other Third Party APIs that are being used. If there is use of Third Party APIs. What analysis and process was gone through to determine which API should be used in the development of the module(s)
 - Development/structural view of Application(s): In conjunction with the Code/Module View, it is important to document the process for determining the project time line for development of the application. This may be focused on the initial delivery of base modules that are common or critical to the initial phases of the overall project. Selection Criteria for Third Party APIs and for Back-end database application services may be included in this documentation.
 - Concurrency/process/thread view of Application(s): In conjunction with the Code/Module view, it is important to know which modules will run. Ie: what is the trigger, what processes get spawned as a result of the module being initiated, What is the dependencies, execution order and priority of each module initiated through the various module(s).
 - Physical/deployment view of Application(s): Prior to the Development of Installation Instructions a plan needs to be developed that outlines how the application will be deployed, and the requirements of the systems on which it will run (including bench marking data to determine what the real system requirements are).
 - User action/feedback view of Application(s): This documentation will show what will happen as the modules near completion to ensure that there is an interaction with the user community to gather feedback / input through Use Cases, Scenarios, Testing and Verification processes (See Item #1d below). Feedback and results should be collected and reviewed and if necessary, any issues identified should be addressed through the Change Management Process (See Item #5 Below)
 - Data view of Application(s): Data that is created, maintained, edited, deleted, transferred through the applications. Including Data Definitions, Dependencies, Keys, and Data Models (for Database type applications). Data being referenced in supporting Log Files, INI Files, Configuration Files, Graphical or other Custom Files that are read / accessed / written to by the application during its course of operation.

c. Implementation Documentation
 - May be related to the Design Documentation above, however looking for additional information specific to why a specific decision was made to implement the functionality of the Module in that way.
 - May include production of white papers, and meeting notes that show discussion and decision process to select specific approach.
 - May include problem reports with how they originally started to implement the module, that resulted in them having to make changes to address the issues (This relates to the request for the Change Management Process documentation in Item #5)

d. Verification / Testing Documentation
 - Provide Flowchart of Verification / Testing Process Map or Flowchart (relates to Change Management Process in Item #5 below)
 - Provide Verification / Testing Evidence showing that the modules / components of the application were tested, and that the results of the testing met requirements listed in the initial requirements documentation (See Item #1a and #1d above) and whether it passed or failed.

e. Maintenance Documentation
 - Provide Maintenance Schedule and Documentation showing completed Maintenance items along with End User Acceptance Testing / Verification of deployed changes.
 - Provide Maintenance Process Map or Flowchart (relates to Change Management Process in Item #5 below)


2.  Supporting Documentation used in aspects of the application.
       a. White Papers and Third Party APIs may be used to allow you to develop the required functionality.  

       b. Ensure that you have all the relevant documentation and licence agreements for any Third Party API that you may be using

3.  Developer Documentation

       a. Meeting Minutes

       b. Status Update Report

       c. Time Sheets

       d. Email Communications

4.  Market Research
       a. Documentation that indicates that you spent time developing and searching out to ensure that there wasn’t an application already out there, or if there was, what it’s deficiencies were that required you to develop your own.

5.  Change Management Process Overview
       a. Flowchart showing how you manage making changes to the application, and the processes followed.

       b. Detailed Records of Changes Made to the Applications including supporting Change Management Requests and any related documentation to each request.

       c. Tools such as VSS, Mantis Bug Tracker or other help desk apps can provide you with this capability.

6.  Final Published Documentation that is provided with the Compiled Application.
       a. Installation Instructions

       b. Help Files

       c. User Manuals

       d. Training Documentation (Manuals, Presentations) for staff that are managing the application and its implementation

7.  Any Financial / Taxation Documentation that may have been submitted that references the application.

8.  Any Purchases made (software licenses, or other) that may have been related to the application’s development / implementation.

9.  Any Legal documentation that was prepared in the development of the End User Licensing Agreement, or in the Sales/Technical Support Contract.


Other Blog Entries:
I can't say it enough - Documentation is Important!

Supporting References / Templates
http://en.wikipedia.org/wiki/Software_development_process
http://en.wikipedia.org/wiki/Requirement
http://www.it-checklists.com/system_documentation.html

01/20/2010

The Magic Number is.... 256

Tags: EDiscovery
A picture named M2

Whether in your eDiscovery Projects, or in your Information Technology lives, at some point you will become acquainted with the Magic Number - 256. This number represents the Maximum Number of Characters that a file name and its associated path can have in the Microsoft Windows World.

Don't let this limitation be the New Bullet that stops your ability to transfer, process, and ultimately deliver data to your clients...

Problem:

Common Errors / Issues that you may see when trying to access files that have a file name and path that is longer than the 256 characters will include:
1. Error statements like: "Path is too long", "The file name or extension is too long"

2. When you try to access the file through Windows Explorer RIGHT CLICK Menu you notice items are missing...
A picture named M3

3. Windows Explorer Properties missing files from the file count. (Note: this screen shot shows 0 files because there is only 1 file in the folder that I am using for this example)
A picture named M4
Note: if you use another tool like Treesize, then you see all of the files:
A picture named M5


Depending on the applications that you might be using, they may generate other error messages and allow you to gracefully exit, or they may just crash because they loose access to the file that they were trying to access.

Cause:

From the Microsoft Article referenced below: "Win32 programs are limited to a 256-character string size limit because of the MAX_PATH variable. Software programs can work around this problem by passing Win32 a path that is MAX_PATH or less."

IT Scenario:

Typically in the IT role, you might see this occurring when you are trying to access data from the ROOT of a disk system, and the users have created folders, and ultimately a file name and path from a mounted network share; or when you are trying to access a user's documents on their Laptop/Desktop and they have created a path that is just too long.

Here is an example of a file name and path that your users may inadvertently create because they store their documents in the "My Document" folder.

Example: "My Documents\My Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project ABC - Letter to Department Heads - Upcoming Changes in Application Functionality - Phase 1 - 2009-Aug-11.docx"
Length: 221 Characters

When you actually try to access this file from the root of the hard drive (aka C:\) the path is really as follows:
"C:\Documents and Settings\Richard Wessel\My Documents\My Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project ABC - Letter to Department Heads - Upcoming Changes in Application Functionality - Phase 1 - 2009-Aug-11.docx"
Length: 262 Characters.

Similar examples for disk storage systems (NAS, file servers) and how IT departments organize the Departmental and User Share locations should be considered... The user stores all of their files on the "P:" Drive (Personal Network Share assigned by IT through the Login Script or Windows Account settings), and they again build a very deep and elaborate folder structure.

Example: "P:\My Documents\My Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project ABC - Letter to Department Heads - Upcoming Changes in Application Functionality - Phase 1 - 2009-Aug-11.docx"
Length: 224

When the Network Administrator tries to access the file, they access it from the root of the file server, where the P:\ drive is replaced by the full path that it was mapped to:
"R:\User Data\Department A\Richard Wessel\My Documents\My Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project ABC - Letter to Department Heads - Upcoming Changes in Application Functionality - Phase 1 - 2009-Aug-11.docx"
Length: 262 Characters.

eDiscovery Scenario:

If you're working on an eDiscovery project and you receive data from a client, you may also encounter this issue, depending on how the client collected the data. (Keep in mind that the same examples shown above in the IT Scenario may also be encountered in an eDiscovery project if you are receiving images of computer systems (using Encase, or other forensic imaging products) and the users have created deep folder structures).  

A basic scenario, may be that a company is asked to collect all information for 5 custodians. The IT team at the company gets involved and identifies all of the potential locations/sources of data and then decides to organize it in an appropriate file structure as follows:

Legal Project\Custodian A\Laptop\.....
Legal Project\Custodian A\Personal Network Share\....
Legal Project\Custodian A\Shared Data from Network\....
Legal Project\Custodian A\Email from Server\...

Just by using this directory structure alone, the IT team is potentially adding anywhere from 34 - 51 characters.

Now this data is provided to an eDiscovery Vendor, or the Law Firm representing the company, and they transfer the data to their systems where they have a policy on Client Data and how/where it is stored. Their policy may state something like: "Client data is stored in a separate dedicated Source folder located in the Client's Case Folder". So, when they transfer the data they organize it in the following folder:

Client\CaseID\Source\....

Using this example, the Law Firm adds another 21 characters.

Just to put these numbers in perspective... If we start with the very first example above, where the user had the data stored in his "My Documents" folder,

Example: "My Documents\My Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project ABC - Letter to Department Heads - Upcoming Changes in Application Functionality - Phase 1 - 2009-Aug-11.docx"
Length: 221 Characters

The IT Department would have placed this data in the "Legal Project\Custodian A\Laptop\" Folder:
"Legal Project\Custodian A\Laptop\My Documents\My Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project ABC - Letter to Department Heads - Upcoming Changes in Application Functionality - Phase 1 - 2009-Aug-11.docx"
Length: 254 Characters

The Law Firm would have placed this data in the "Client\CaseID\Source\" Folder:
"Client\CaseID\Source\Legal Project\Custodian A\Laptop\My Documents\My Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project ABC - Letter to Department Heads - Upcoming Changes in Application Functionality - Phase 1 - 2009-Aug-11.docx"
Length: 275 Characters

With a file name and path length of 275 characters, a number of the eDiscovery Vendor's or the Law Firm's tools may have issues, and delay processing of the data...

Data Transfer Workarounds:

There are workarounds to allow you to gain access to the data without encountering these errors specifically:
1. How the Folder Structures are designed for transfer
2. How the data received is transferred, and at what Folder level is the data transferred from/to
3. As mentioned in the Microsoft Article: "On the server that contains the long directory structure, access these files and folders through a local redirection ("net use" or "subst") of the same share/folder that the network clients access across the network." - This really means MAP a Drive to a Point further down the Folder Structure so that you can access the data, and then use this new mapped drive to work with and process everything.
4. As further mentioned in the Microsoft Article: "In Windows... Explorer, select the folder one level above the folder that returns the error. Right-click the folder returning the error and then click Rename. Rename the folder to reduce the number of characters used in the folder name." - WARNING: This implies that you are going to be changing the original data and this may be an issue.

In these workarounds, there maybe other considerations that you may need to take into account, especially if this is an eDiscovery project:
1. Chain of Custody / Process Documentation: When data is transferred the Chain of Custody should be updated and maintained to reflect what was really done to the data
2. If you're renaming folders/sub-folders to try to address the issue, you may be changing critical information that may affect the meaning of the importance of the data. For Example, if the folder you rename was called "Project ABC - Smoking Gun Documentation" and you changed it to be "Project ABC - Smoking", the meaning of the content of the folder totally changes.
3. If you're mapping network drives to be able to access the data for processing, you need to ensure that you document the drive mapping, and determine how it will affect your processing strategy and how all of the data will again be consolidated into the appropriate deliverable for the client.

In the end, anything that you do to the data to get it transferred, accessible, processed, and ultimately provided to the client needs to be properly documented.



UPDATED: 1/20/2010 @ 3:05 pm EST: Thanks to Jeff, who passed on this information to me: http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath
"The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\<very long path>". "

So, I quickly Tested my Existing Test Folder that I was looking at, and tried navigating using "\\?\" Prefix, however it did not work within my test environment, as the application (aka Windows default RUN Command, and Windows Explorer) may still be restricted to the 256 character limit. It may be possible within the physical application code to have vendors support this particular feature to be able to gain access to the data.



There's more:
Although you have probably read this, and said "No one will ever use file paths and names like that...", I have personally experienced this in working with a number of legal projects where I was the IT person performing the identification and initial collection of the data, and as an eDiscovery Consultant working with Vendors to process data for clients.

You may not encounter these issues subject to the Actual Data, How/Where you transfer the Data to your Systems (if you transfer it instead of accessing directly from the original source media), and the Tools that you are utilizing and their own limitations (if any).

Another area where you may encounter this issue is when you begin to look at compressed files that users may have created. (meaning WINZIP. WINRAR and other compressed file formats). Some tools extract\expand these file types, with the Folder structure contained within the WINZIP/WINRAR being added on...

For Example: My Documents\My Business Documents\Project ABC.ZIP

Depending on how the information was ZIP'd/RAR'd the full folder path may or may not be included...

WinZip Settings:
A picture named M6

WINRAR Settings:
A picture named M7

This may mean that when fully expanded the path might look something like this:

My Documents\My Business Documents\Project ABC.ZIP\subfolder1\subfolder2\document2.docx

or

My Documents\My Business Documents\Project ABC.ZIP\c\documents and settings\My Documents\My Business Documents\Project ABC\subfolder1\subfolder2\document2.docx

Furthermore keep in mind that a Zip file may be moved around by the users, and the original path may be totally different then where the ZIP file currently sits.


In Closing:

The examples above may seem a little too obscure, but they were developed to show the potential issue, and what might happen when you are working with the data that is based in many folders/sub-folders and has extremely long file paths and file names.

Vendors are continuing to develop and adjust their tools to try to address these issues. eDiscovery Vendors who have encountered these types of issues should have procedures in place to address them.

If you haven't been thinking about this as a potential issue, it may be something that you need to look at further, a review of the information being provided as part of your Chain of Custody may be required so that you can ensure that all the data provided to you is being properly transferred, and ultimately processed.



References:
Microsoft Article ID #177665:  http://support.microsoft.com/kb/177665

Related Posts:

10/21/2009

Who's On Your Legal Litigation Preparedness Team?

Tags: EDiscovery
A picture named M2In the Modern Age of Movie Making, everyone is striving for that next Oscar, or Film Festival Award... To reach that goal, you need a team... In this post, let me draw comparisons to the Movie Industry and the Roles involved and compare that to your Legal Litigation Preparedness Team...

The Directors, Executive Producers
In any production, the Direction of the Project comes from the Director and Executive Producer, so in the Legal space this would be coming from:

- The Plaintiff or Defendant… which typically includes Corporate Counsel and key business unit contacts. Key Business Unit Contacts typically are key people in the corporation that have an internal knowledge of the matter at hand For Example the President, Vice President, or a Project Manager, regardless they’ll be identified to you by your corporate general counsel.  And They’ll vary from company to company.
- Legal Representation: which is typically the external law firm

The Actors
In any production, the Actors are typically front and center, in our legal team, this would include:

Supporting Corporate Resources:
- Human Resources – They can provide you the corporate policies
- Information Technology – If there is an eDiscovery Component, this team will be critical to your understanding of the computer environment and potential scope of data available to you. They will provide you with Information on Backup Systems, and the Tape Retention Policies.
- Records Management - They can provide you with the Records Retention Policies; and the Records Classification Specifications.

Litigation Support Teams
- Corporate Resource
- External Counsel Resource

Project Manager / Case Managers
- Internal Corporate Resource
- Litigation Support Resource
- eDiscovery Vendor Resource

Specific to Project Managers / Case Managers:  I would like to suggest that it is important that this role be of utmost importance as inevitably you will want to know what the Status is of various aspects of the legal matter. At a minimum you should ensure that any Vendor that you are working with provides a contact that will be your gateway to status updates and their issue resolution process during the time that you have them engaged.

The Special Effects Team
With Direction coming from the Corporate and External Counsel; The Actors are executing the script and strategies; There comes a time when some sort of Special Effect will be required… this would include:

Legal Consultants
- eDiscovery Consultant
- Technology Consultant
- Case-specific Legal Consultant

Vendors
- eDiscovery
- Forensic Collection
- Data Restoration Service Providers
- Etc…

Legal Consultants are typically experts in a specific field or area of law, and can be engaged to help in addressing key issues or decisions that you may need to address as part of your legal matter.
Third Party Vendors play a critical role to providing specialized services that address specific tasks where there is Electronically Stored Information (ESI) involved. You will likely need to have one of these involved through out your matter; Whether it be for Processing and Producing Data; Collecting the Data; or Just getting the data restored from the various Backup Media; these vendors will typically provide an important service that you will be relying upon for the rest of the matter.

Putting it all together
The key Point…. You Can’t do it all by yourself, you need a team to assist. Only together can the Directors, Executive Producers, Actors and the Special Effects Team put the final product together.

A picture named M3



After setting up this team and working successfully to the conclusion of any legal matter, you should strive to keep the team together, so that:
 - You Don’t have to Re-invent the Wheel - meaning that you should learn from what you and your team just did.
 - Your Team Understands: the Data Universe; the Company Policies; a Litigation Hold Process; and a Data Collection Strategy.

From each legal matter that you team works on you should look to record any: Lessons Learned; Changes to the Policies, Processes or Overarching Strategies that you may have followed, so that you are prepared for the next time.

For more information on building your team look at the following previous posts:

10/05/2009

Have you got your plan???

Tags: EDiscovery
A picture named M2 With the New Rules of Civil Procedures for Ontario coming into affect in January 2010, one of the key changes is related to your DISCOVERY PLANS... Key items: they must be in writing, and they must be agreed to by all parties; there are time constraints on the production of the plan; there are content requirements; the plan needs to be maintained/updated as things change; and finally there is a potential penalties for not agreeing to / updating the plan. ( See Rule 29.1 at http://www.e-laws.gov.on.ca/html/source/regs/english/2008/elaws_src_regs_r08438_e.htm )

In addition, with respect to eDiscovery, the Sedona Canada Principles need to be taken into account. ( http://www.lexum.umontreal.ca/e-discovery/documents/SedonaCanadaPrinciples01-08.pdf ); the principles all apply to any eDiscovery matter, however I want to draw your attention to a few that really relate to the topic of developing a plan between parties:

Principle 4: Counsel and parties should meet and confer as soon as practicable, and on an ongoing basis, regarding the identification, preservation, collection, review and production of electronically stored information.

Principle 8: Parties should agree as early as possible in the litigation process on the format in which electronically stored information will be produced. Parties should also agree on the format, content and organization of information to be exchanged in any required list of documents as part of the discovery process.

Principle 9: During the discovery process parties should agree to or, if necessary, seek judicial direction on measures to protect privileges, privacy, trade secrets and other confidential information relating to the production of electronic documents and data.

Principle 2: In any proceeding, the parties should ensure that steps taken in the discovery process are proportionate, taking into account
1. the nature and scope of the litigation, including the importance and complexity of the issues, interest and amounts at stake;
2. the relevance of the available electronically stored information;
3. its importance to the court’s adjudication in a given case; and
4. the costs, burden and delay that may be imposed on the parties to deal with electronically stored information.

In a nutshell.... Meet and Confer and Agree on what is the scope, formats, data exchange protocols, data protection measures, and the level of effort being put forth to execute the discovery plan is appropriate.

Your plan cannot be developed in the dark, you need to work with your litigation preparedness team, and understand the data that you have available to you. For more information on these, refer to my previous posts:


References:
“The Sedona Canada Principles Addressing Electronic Discovery (January 2008)”
The source:  “Working Group 7, The Sedona Conference”
http://www.lexum.umontreal.ca/e-discovery/documents/SedonaCanadaPrinciples01-08.pdf


ONTARIO REGULATION 438/08 made under the COURTS OF JUSTICE ACT
Made: December 3, 2008
Approved: December 10, 2008
Filed: December 10, 2008
Published on e-Laws: December 12, 2008
Printed in The Ontario Gazette: December 27, 2008
Amending Reg. 194 of R.R.O. 1990 (Rules of Civil Procedure)
http://www.e-laws.gov.on.ca/html/source/regs/english/2008/elaws_src_regs_r08438_e.htm

07/17/2009

Do you have your "A-Team"???

Tags: EDiscovery General IT Project Management
A picture named M2 The A-Team, from the 1980's... This was "the" team to be on, they rescued everyone, they caught the bad guys, and everything was neatly wrapped up in 45 - 48 minutes (unless it was a two part episode).  What I would like to draw your attention to is the need for you to have a team for all your projects, whether it is an IT Project, a Legal eDiscovery Project, or even a Home Renovation.... You need to make sure that you have the right people for the job. So, what are some things that you should look for in your team?

1. Knowledge - Having the right skill set is important; you need to have people that know the scope / impacts / methods / standards / etc that will help to make your project a success.

2. Experience - Just because someone "knows" something doesn't mean that they actually know how to implement or execute their particular tasks. (But keep in mind that everyone needs to start somewhere - So keep the scope and type of project in mind and you might just find that the new-kid-on-the-block is the perfect fit).

3. Initiative - Although you want your team to work together, it may take someone to initiate and spark the project into motion when things seem to be slowing down or starting to drift from the original project scope. Keep in mind that "too many cooks in the kitchen may spoil the soup". But if your team waits for you or the project manager to explicitly tell them what to do for every little step of the project, it will prove to be very trying and stressful

4. Energy - It is imperative to keep a project moving, although "slow and steady wins the race", if your overall project is slow and lethargic, your team will miss its opportunity to bring value and change to your organization in the time frame that was allocated.

5. Commitment - You can't do it all by yourself... you need a team that is committed to seeing the project through to its completion. Some examples of showing commitment include: attending meetings; completing tasks on time; actively participating in the project (if your team is "sitting on their hands", or "asleep at their desks" it may be time to shake it up a bit). Another factor to consider relates to the team members commitments outside of the workplace. I don't mean that they have other things that they need to do, but rather that they are committed to trying to maintain a positive work-home-life balance.

6. Accountability / Responsibility - Similar to Commitment (above) your team members need to take responsibility and be accountable for their actions and participation within the team. Following up and completing assigned tasks and doing what they say they will do, all lead to an effective team that will be successful.

7. Suitability to the project - Look at who you need within the team... If your project is Information Technology related you would want to make sure that you have someone from the IT Department on it... Likewise if your project has a large financial cost or accounting impact, you may need to have someone from the Finance Department. Something that I have personally seen overlooked in a few projects (during my employment) is the missed opportunity to have the actual user community represented... A good example of this came from my application development roles; we had application champions that were responsible for the application and any changes in its function... occasionally I would receive requests to make changes from the champion, only to have to undo the changes after the user community had a chance to test the changes before being rolled out. If even one of the key power users of the application would have been consulted during the champions re-design we would have not seen this issue and the project would not have been delayed, or needed to be re-designed.


This is NOT a complete list and there are many other things that you might look for. These seven items play a major role in larger projects where the: stakes/risks may be higher; time frame for implementation / execution is longer; scope is across multiple departments or segments of the company.

To quote the A-Team:  "I love it when a plan comes together!"  Col. John "Hannibal" Smith (George Peppard) and "I pity the fool!" Sgt. B.A. "Bad Attitude" Baracus (Mr. T).

In closing, work to make your team the best it can be... your project depends on it.



Resource References: The A-Team Image downloaded from: http://www.reelmovienews.com/2009/01/the-a-team-movie-rumors-update

07/08/2009

Don't Gamble with your Ediscovery - Understand the Process

Tags: Ediscovery
A picture named M2
Yes, I am a Trekkie!   At the Beginning of July 2009, I had the opportunity to take my wife to Las Vegas for a few days without the kids... We had lots of fun and had a very restful time.

As I look back on that trip now, I think: "I was lucky I only lost $50.00."  Wouldn't it be nice if our legal matters only cost us $50.00?

There have been numerous articles and white papers on Electronic Discovery and its costs and the need to control and understand them. I want to suggest that although cost is important, it is also important to understand what you are getting as part of the eDiscovery service that you are paying for. And when I say understand, I don't mean from a pricing proposal perspective, but rather from the process that the vendor is going to follow.

Here are a bunch of examples / questions that you might want to ask:

 - Do you want the vendor to have a certified process that they follow?
 - Do you want to be able to get reliable reporting and status from the vendor?
 - Although you may NOT understand the TECHNICAL aspects of everything that the vendor is going to do; do they provide an opportunity for you to learn about their process and what they do?
 - Do they provide you with documentation or summary report(s) of what they did?
 - When they are asking you for decision points, are they providing detail that helps you to understand the impact and the risks associated with the decisions that you are making?
 - Do you have a dedicated contact person at the vendor that is available for you to contact at any time?

In the End, don't just throw away your money, as if you are sitting at a slot machine; the slots are fun and loosing a bit of money is ok when you're focused on the "entertainment" of playing... But, in a legal matter we can't "play" with our money, the costs are real, and you want to ensure that you are working with a vendor that is doing everything in its power to ensure that you receive a quality product that follows a repeatable process.

Want to find out more on selecting an EDiscovery Vendor? You can Google "eDiscovery vendor checklist" and you will receive a number of documents back... Here are a just a few that I found useful:

http://www.fiosinc.com/resources/checklists/EDD-Vendor-Viability-Checklist.pdf
http://books.google.com/books?id=PvJohSehGlkC&lpg=PA28&ots=h0r7nT2qiQ&dq=ediscovery%20vendors%20checklist&pg=PA28
http://www.practicepro.ca/practice/eDiscovery_Rlist.asp


06/10/2009

I can't say it enough - Documentation is Important!

Tags: General IT Project Management
I'm sure you've all heard it before.... Where's your documentation?

It doesn't matter what the project, what role your playing, what company you work for... the message is still the same. You need to document what your doing. If your working towards any of the ISO Certifications (
http://www.iso.org) you should keep the following motto in mind: "Do as you say. Say as you do"

I have been involved in a number of projects where documentation is key, and yet when it came down to the wire, the documentation was incomplete and missing. Not only did this add undue risk to the situation, but it also quickly made team members look like they had not completed their tasks. So, Here are some tips that may be of use to you:

1. Update Documentation IMMEDIATELY following any changes. If you have a Help desk or an Issue Tracking system, you could integrate a "Documentation Updated" check or a new status - "Resolved - Pending Documentation" to indicate that the issue has been corrected, but that you still need to complete the documentation.
2. Periodically Review documentation to make sure that any recent changes have not gone un-documented.
3. If you have a Help Desk, or an Issue Tracking system you could look at generating some report(s) that highlight the changes for a particular system/application, and then use it as a checklist for ensuring that the documentation has been updated.
4. Set up a documentation task force, and select systems/applications that are critical to your organization. Assign specific documentation (by type, role, or other means) to individual team members and set realistic timelines that will allow the entire team to be successful. (Note: having a timeline of 1 year is not an appropriate timeline. It needs to be measurable, and assist with keeping the team members on track, and accountable).
5. Get management's support, communicating to them on a regular basis on the status of any documentation initiatives.
6. Develop Templates that allow team members to start documenting and not worrying about formatting. Consider developing a template for each of these apps: Microsoft Word, Powerpoint, Excel, Visio.
7. Encourage the use of graphics, flowcharts, etc... Remember... A picture is worth a thousand words.
8. Develop a standard set of definitions that will help to ensure that team members are providing the same type/content for the same types of documentation. (eg: System Management vs. User Management vs. System Monitoring, etc)
9. If your having problems getting started, consider performing a brief interview with team members to capture the current state of a system/application and then use those findings to generate a list of documentation deficiencies.
10. When you are making changes to documentation make sure to track what you changed in a "Revision History" or "Version Control Table".

06/06/2009

File Type Summary - FTS

Tags: EDiscovery
When working with a data for an Electronic Discovery project, clients usually ask... "What does my data look like?"

This simple question has a number of responses... it can be as simple as saying: "The data is comprised of 1045 files with a total size of 1.08 gigabytes." or better yet, the response is more detailled and looks at the following things: Native Files (ie: Microsoft Office files), Compressed Files (Winzip, Winrar, GZip, CAB, etc), Email Files (Microsoft Outlook EML, MSG, PST and OST, Microsoft Outlook Express DBX, Lotus Notes NSF, Other POP3/IMAP4/MAPI Mail formats, Microsoft Exchange EDB/STM Files), Backup File types (Typically Windows Backup BKF), and Known System Files (NIST).

A Detailed File Type Summary based on just the Extensions of the files, is a good starting place, however, there are users that do not necessarily conform to the default file naming extension practices that the newer releases of software provide by default, and they will change the extensions. A good example of this is when you think back to Wordperfect 5, 5.1, 6, etc... it was common practice to name a "Memo" as ".MEM" or a "Letter" as ".LET". So, depending on your users and on various software packages used through the dates involved in the litigation, it may be necessary for you to determine the true file type / format of files that are named with non-standard extensions.

Other considerations that may be important, is whether you should be extracting the Compressed Files and the Backup Files to their full original content. Email Files can be extracted to MSG/EML format to provide detailled analysis of the number of messages and attachments that are part of the collection. Some Email files need to be converted to a supported format (e.g. OST and DBX files need to be converted to PST).

Removal of "Known System Files" helps to reduce irrelevant documents and the total costs related to processing. A number of tools integrate the NIST Databases into themselves, so that any registered application executable / dll / library / etc will be removed from your data collection. To learn more about NIST, visit:
http://www.nsrl.nist.gov/

There are a number of tools available to be used some of the ones that I have used with great success include:
Trident Professional:
http://www.discoverthewave.com
Early Case:
http://www.earlycase.com

Each have their feature sets... and depending on what you really want to get out of the data, it may be necessary to look at other tools.

If you have any questions, or want to know more please feel free to comment.

10/03/2008

16,000 Books, a Drop in the Ediscovery Bucket...

Tags: EDiscovery General

09/16/2008

Data Centres: Getting Ready to Move your computers from one location to another...

Tags: IT Project Management
Over the Years, Companies will find that their Computer Rooms (aka: Server Rooms, Data Centres, or any physical location where a Computer is located) become to small for the amount of equipment that they are housing in it.  

Depending on the company's direction, there may be opportunities to:
- consolidate servers (using Virtualization Technologies like VMWare);
- replace older, bigger, and slower servers with newer, smaller and faster ones;
- move the equipment to a newer and bigger location

In this Blog, we will focus on the Last option - "move the equipment to a newer and bigger location".

Like any project you first need to look at:
- what exactly you are going to be doing - setting the goals and objectives
- communicating with Team Members, Managers, and Executive Management
- developing the plan, identifying the steps, risks (impact to company, clients, vendors, etc),
- determining the required resources (manpower / hardware / software / telecommunications / networking / co-location, etc) and the costs associated.
- determining the schedule (not just implementation, but also key milestone dates).

What has worked well for REW Computing is the following approach:

Initial Project Meetings / Interview:
A meeting is held with the Key Players / Decision makers and review the initial goals and objectives. Use this opportunity to also inquire about costs and their expectations. In some companies you may be told to do it as cheap as possible, and in others you will be told that the risk of having the re-location fail is too high, and that money is not an option.

Getting the Required Information:
Working with the IT Team, we request the following types of documentation:
- Physical Server / Network Switch / Disk Systems / Other Systems Physical Rack Layout within the Existing Computer Room.
- Network Diagrams and Physical Port Configurations (Telecommunication Links, and Network Routers / Switches / Firewalls)
- Existing Computer Room Configuration Details (eg: Current Cooling, Fire Suppression Limits, etc)
- Physical Server / Network Switch / Disk Systems / Other Systems Environmental Specifications (Heat, Power, Cooling, etc)
- Work with the appropriate vendors to get additional information or reccomended strategy for moving equipment.

Defining the Risk: Once you have all of the information, you should be able to identify the key systems/servers that are Critical (must have up and running) vs. Low Risk (move them but if they are not up and running it's ok, we can have a few days to work on them after the physical move).

Developing the Plan and Determining Costs to Implementation:
After the meetings and getting all of the required information, a staged approach is developed to outline exactly what needs to be done. Initially this plan starts off as high level bullet points, but as it grows and is refined it becomes a detailed step by step record of what needs to be done.

Other Documentation that gets created includes revised through out all the phases include (but not limited to):
- Network Diagrams
- Computer Room Rack Layouts
- Timelines
- Migration Plans for New Hardware / Systems
- Test Plans to ensure equipment / applications / access
- Communication Plan

Through out the development of the plan there are meetings with team members (internal and external vendors) to ensure that the plan is sound and the timing is appropriate. As each section of the plan is expanded and defined, any Costs associated are also incorporated into an Executive Summary that will be presented to gain final Approval.

Final Approval Meeting:
Another meeting with the Key Players / Decision makers is held and the entire plan and associated costs (and Options) are presented. The goal of the meeting is to get final agreement and approval to move forward with the purchase of any equipment / services required.  Upon Approval purchase orders are written and signed off and submitted to the vendors.

Pre-Implementation Planning:
With the approval given and the Purchase Orders submitted, we continue to revise the detailled plan and timelines for implementation. Working with the Team we will notify affected clients of the schedule maintenance and start notifying Critical Accounts with as much notice as possible. During this teim we also await the delivery of any new hardware.

Implementation:
Once everything is received and the Time arrives to perform the move, complete the testing and execute the communication plan to let clients / users know what happened.

There may be applications / services / servers that do not work after the move. Determine the Risk associated with having the server unavailable and decide what the action plan should be (ie: High Risk: need to address immediately; or Low Risk: can continue to operate without this but needs to be addressed within 5 Days)

Post Implementation:
Review what happened, what worked, what didn't. Develop Lessons Learned that can be used in the future for the next move. Review all documentation and ensure that everything is updated and finalized. Have a Post Implementation Meeting with the Key Players / Decision makers and review everything that happened. Review any outstanding items that need to be completed and ensure that the plan and timeline is in place to complete.


Calendar

Tags

Google Ads

Powered By

Domino BlogSphere
Version 3.0.1 Beta 8a