I interviewed with an attorney this week. Her company dumped what might turn out to be a major IT project in her hands. She talked to one of my best friends who recommended she talk to me.
The first phone call was frantic... for the attorney and for me. As is typical, her mind was down at the field and controls level and I had to a. figure out what she was saying and b. make it look like I knew what I was talking about.
After about a half dozen questions, I realized where she's at and why she's in trouble.
This company gets sued a lot, I guess, there are a lot of in-house attorneys and, to use her words, "...hundreds of Outside Counsel."
Legal Discovery
Unfortunately, the legal profession uses the same word we IT folks use when we start a project: Discovery. Seems that in a civil lawsuit, Discovery occurs when someone sues someone else. Both sides have to give copies of relevant data (documents, spreadsheets, e-mail, etc.) to the other side. Turns out my new friend's company does this manually. In this day and age!
Thankfully, the company is throwing some resources her way and we may be able to solve her problem.
The company is adding some enterprise tools- but these tools aren't connected to anything in the current plans. Yep. No data store, no way to search, no history of use, no ability to browse using a taxonomy and no way to create and send a digital package of documents/data to opposing counsel, much less e-mail confirmations and an audit trail.
So the poor lady has two problems: where do we put all the nicely tagged and redacted data items and once they're there, what happens?
She has 3 Terabytes now. How do we get disparate databases connected (including non-company hosted systems) and then once all that stuff is properly stored in a data center somewhere- how do the other attorneys find and use the documents.
She was mostly concerned about the data store and what she kept calling "the index." She's right. The search engine needs to be able to pull records based on a lot of metadata. At least the metadata tagging will be automated!
Her IT Department has no resources to help her. Its been ravaged by lost and unfilled positions caused by the economy and several company reorganizations.
No wonder she was going nuts. Heck, if I was facing that and didn't know anything about content management, data mapping, batch ETL (Export/Transform and Load. No? It means connect all the databases and make them work nicely together) and the ways and means of attacking and solving the problem (project management and business analysis) and designing a solution (at the abstract and the wireframe levels, certainly), I would have been much more upset than she was. Hey, I can't write a brief or represent someone in court for money...why would her company expect her to be able to do what I do? I don't.
IT Discovery
Here's what the Project Discovery Phase looks like from my perspective- the Business Analyst:
The goal of this phase is to find the new system's boundaries (this will help define the Scope of the project), gather and organize functional requirements and settle on technology and architecture. Once the deliverables (the stuff I hand the client when that part of a project is completed) are in, the customer/company/client then has enough information to intelligently deal with how it wishes to proceed.
I advise and suggest while the company does everything except figure out how to pay for it and decide whether its going to do it. I guess they think that stuff is proprietary and private. OK by me.
I'm a sort of combination resource-subject matter expert-adviser. The Project Manager (if we have one) and I are what's called 'client-facing.' This is a silly term for: we talk to the client/customer.
I usually go in with a Project Manager (if we have one) but much more importantly-- a really smart technical architect or Lead Developer. We grab as many Word Docs, Excel Spreadsheets and paper, passwords, user ids and network paths as we can.
Then we sift and read. I then draw what the company is doing now (called an As-Is Decomposition) and a proposal for automating one or more processes (called a To-Be Decomposition). The architect and I are beginning to design a possible solution. I start setting up interviews or meetings so I can ask questions and define the high level requirements. The architect is doing a parallel study for the technology (development languages and basic coding standards) and architecture (identifying the likely service layers and a beginning of the database table design). We constantly confirm and reconfirm the validity of the existing process and what the stakeholders tell us the business needs (business rules).
I write my functional (functional - that means a description of what it does, not how it does it) requirements, a few fancy pictures (remember I told you Technical Writers to always have one graphic in color in anything you write that's more than two pages? The company folks you're working with need as many diagrams and pictures as possible top help them sell the project- preferably in color). I usually add a couple of 'artist concept' wireframes of a basic interface and a lot of diagrams.
The architect is writing up his/her technical document. If it's going to be written in .Net, there's a lot of cutting and pasting from the Microsoft Development Network website onto our wiki- I never watched where the J2EE architects steal, sorry, borrow their documentation from but I assume its on the Sun site somewhere or maybe at SourceForge.net.
I then edit the technical document because I have yet to see a developer, even at Microsoft, who knows how to write. I'll also help here with any diagrams or flow charts the architect wants (which I 'suggest' forcefully, see the parenthesis two paragraphs up).
From these two documents (and maybe a Business Case), the company can count function points, bid the project or put everything on hold. Hopefully, the last option doesn't occur because I usually....no...always need the work.
For some unknown and mystical reason, my company gets the contract for the Functional Requirement Document I just wrote. every time. How do you like that? Amazing streak of good luck, no?
My new friend wanted a proposal in plain English. This sparked friendship. I hate lousy writing. But she wanted complete explanations. So I spent most of yesterday evening and this morning writing it. It was seven pages long. I thought I went overboard. But my original friend said I didn't so we'll see what happens.
I think the two color flowcharts and the lovely Activity Diagram will help, as will the seven PowerPoint slides with animation and reuse of the graphics.
I ain't no dummy.
Stay tuned. Let's see if the winning streak continues.
The first phone call was frantic... for the attorney and for me. As is typical, her mind was down at the field and controls level and I had to a. figure out what she was saying and b. make it look like I knew what I was talking about.
After about a half dozen questions, I realized where she's at and why she's in trouble.
This company gets sued a lot, I guess, there are a lot of in-house attorneys and, to use her words, "...hundreds of Outside Counsel."
Legal Discovery
Unfortunately, the legal profession uses the same word we IT folks use when we start a project: Discovery. Seems that in a civil lawsuit, Discovery occurs when someone sues someone else. Both sides have to give copies of relevant data (documents, spreadsheets, e-mail, etc.) to the other side. Turns out my new friend's company does this manually. In this day and age!
Thankfully, the company is throwing some resources her way and we may be able to solve her problem.
The company is adding some enterprise tools- but these tools aren't connected to anything in the current plans. Yep. No data store, no way to search, no history of use, no ability to browse using a taxonomy and no way to create and send a digital package of documents/data to opposing counsel, much less e-mail confirmations and an audit trail.
So the poor lady has two problems: where do we put all the nicely tagged and redacted data items and once they're there, what happens?
She has 3 Terabytes now. How do we get disparate databases connected (including non-company hosted systems) and then once all that stuff is properly stored in a data center somewhere- how do the other attorneys find and use the documents.
She was mostly concerned about the data store and what she kept calling "the index." She's right. The search engine needs to be able to pull records based on a lot of metadata. At least the metadata tagging will be automated!
Her IT Department has no resources to help her. Its been ravaged by lost and unfilled positions caused by the economy and several company reorganizations.
No wonder she was going nuts. Heck, if I was facing that and didn't know anything about content management, data mapping, batch ETL (Export/Transform and Load. No? It means connect all the databases and make them work nicely together) and the ways and means of attacking and solving the problem (project management and business analysis) and designing a solution (at the abstract and the wireframe levels, certainly), I would have been much more upset than she was. Hey, I can't write a brief or represent someone in court for money...why would her company expect her to be able to do what I do? I don't.
IT Discovery
Here's what the Project Discovery Phase looks like from my perspective- the Business Analyst:
The goal of this phase is to find the new system's boundaries (this will help define the Scope of the project), gather and organize functional requirements and settle on technology and architecture. Once the deliverables (the stuff I hand the client when that part of a project is completed) are in, the customer/company/client then has enough information to intelligently deal with how it wishes to proceed.
I advise and suggest while the company does everything except figure out how to pay for it and decide whether its going to do it. I guess they think that stuff is proprietary and private. OK by me.
I'm a sort of combination resource-subject matter expert-adviser. The Project Manager (if we have one) and I are what's called 'client-facing.' This is a silly term for: we talk to the client/customer.
I usually go in with a Project Manager (if we have one) but much more importantly-- a really smart technical architect or Lead Developer. We grab as many Word Docs, Excel Spreadsheets and paper, passwords, user ids and network paths as we can.
Then we sift and read. I then draw what the company is doing now (called an As-Is Decomposition) and a proposal for automating one or more processes (called a To-Be Decomposition). The architect and I are beginning to design a possible solution. I start setting up interviews or meetings so I can ask questions and define the high level requirements. The architect is doing a parallel study for the technology (development languages and basic coding standards) and architecture (identifying the likely service layers and a beginning of the database table design). We constantly confirm and reconfirm the validity of the existing process and what the stakeholders tell us the business needs (business rules).
I write my functional (functional - that means a description of what it does, not how it does it) requirements, a few fancy pictures (remember I told you Technical Writers to always have one graphic in color in anything you write that's more than two pages? The company folks you're working with need as many diagrams and pictures as possible top help them sell the project- preferably in color). I usually add a couple of 'artist concept' wireframes of a basic interface and a lot of diagrams.
The architect is writing up his/her technical document. If it's going to be written in .Net, there's a lot of cutting and pasting from the Microsoft Development Network website onto our wiki- I never watched where the J2EE architects steal, sorry, borrow their documentation from but I assume its on the Sun site somewhere or maybe at SourceForge.net.
I then edit the technical document because I have yet to see a developer, even at Microsoft, who knows how to write. I'll also help here with any diagrams or flow charts the architect wants (which I 'suggest' forcefully, see the parenthesis two paragraphs up).
From these two documents (and maybe a Business Case), the company can count function points, bid the project or put everything on hold. Hopefully, the last option doesn't occur because I usually....no...always need the work.
For some unknown and mystical reason, my company gets the contract for the Functional Requirement Document I just wrote. every time. How do you like that? Amazing streak of good luck, no?
My new friend wanted a proposal in plain English. This sparked friendship. I hate lousy writing. But she wanted complete explanations. So I spent most of yesterday evening and this morning writing it. It was seven pages long. I thought I went overboard. But my original friend said I didn't so we'll see what happens.
I think the two color flowcharts and the lovely Activity Diagram will help, as will the seven PowerPoint slides with animation and reuse of the graphics.
I ain't no dummy.
Stay tuned. Let's see if the winning streak continues.
Powered by ScribeFire.
Posts
No comments:
Post a Comment