As you plan your testing phase of your project, a word to what testing IS NOT.

It is NOT the time to add requirements.

It is NOT the time to express dismay over how something works.  Just because it works differently does not mean it does not get the job done.  Remember, our data is driven by the archived data, your screens are driven by the archived data, but LegacyInteract is all LDA.  If you still needed your old system functions, you should still run your old system. It is a cost/reward decision.

It is NOT the time to change your mind about how something should work or should be managed, i.e. how to manage your Accounts Receivable, how you are managing your bad debt, etc.  You can change that BEFORE - during REQUIREMENTS - but not during testing.

Testing is reviewing the application to make sure it meets your requirements.  The more specific you were about the requirements, the happier you will be with the test results. (I think I blogged about that before??)

I am headed out to Round 2 of a 3 to 4 round test plan at a client that is due to go live at the end of July.

How do you know how much testing is enough?  I believe that all depends on the data you are archiving and the functions that you will still be doing against the archive.

You most definitely have to balance and validate the data.  No way around that.  Then I would attack the remaining testing based on the functions - set aside a couple of days testing the functions you will use most and take it from there.  You may even want to just focus on the functions for a few days and move on to reports review and interfaces only after you feel comfortable that all the online functions are working as designed.

As far as how formal you get, that is up to you.  Dont document test cases just for the sake of testing, though.  Use REAL LIVE examples from your work flow of functions you can perform against the archive data base - almost like a parallel test.  This will guarantee that you will touch the system in a test mode very closely to how you will touch it in production.

As far as I am concerned, there is no such thing as enough testing.  You should be pounding on that archive data web application right up to the day you go live.

Need help? Have a question? Want to suggest a modification to your site that we host?  There are many ways to get support from Legacy Data Access.

If you are a current customer and registered user:

- Login to Legacy Link. Click GET SUPPORT in the upper right menu. Choose SUBMIT SUPPORT REQUEST from the left list.  Complete the form - make sure you choose the application you are asking about.  Click REPORT PROBLEM. You will get an email confirmation with a tracking number.

OR

- Login to an application within LegacyLink.  Click  SUPPORT from the green menu.  Complete the form - the application is defaulted to the current one. Click REPORT PROBLEM.  You will get an email confirmation with a tracking number.

OR

- Send an email to ldasupport@legacydataaccess.com.  THIS MUST COME FROM YOUR REGISTERED EMAIL ADDRESS.  We have had users send support requests from their home or gmail accounts; these are sent straight to SPAM and deleted. You will NOT get a response if you use a non-registered email address.

OR

Call 1-866-601-2416 and listen to the prompt or dial 111.

If you ARE a current customer but Not a registered user:

- Have your site System Administrator or User Provisioning department representative, who should be a registered user, send the email on your behalf to LDA support, asking that you become a registered user of LegacyLink.  If you require application access, we will need to know which applications you need to access and what your security role should be.  We will NOT accept self-generated access requests. **NOTE: You can be a registered user and not have any application access.  ** Also NOTE that some clients have their own User Provisioning department provide this access to LegacyLink so no email to LDA support would be required.

- Once you are a registered user, use the options listed above.

If you are NOT a customer or do not wish to become a registered user:

- Send inquiries to info@legacydataaccess.com

OR

- Call Call 1-866-601-2416 and listen to the prompts.

I am still over here in Northern California.  The weather has improved greatly from the beginning of the week - clear, blue skys, moderate temperatures.   I have this great Camero to drive around in, and yesterday I realized that as much as I have been here, I have actually never driven over the Golden Gate Bridge.

I plugged an address into the GPS and took off from the office.  The directions took me down 280 towards San Francisco.  The drive was beautiful.  Golden hills on one side of the highway and green, tree covered hills on the other.  Occasionally I would go over a lake or inlet and the houses on the cliffs were amazing - all styles and shapes (literally - shapes - I saw one huge complex of a house that was bright orange and it looked like a bunch of upside down coffee mugs).

Getting to the bridge is interesting - you exit on CA 1 and it stops being your typical "highway" after a bit and takes you right through the city.  That was the only harrowing part since it was late afternoon and traffic was heavy - but still interesting. I passed tons of row houses in all different colors - Pacific Heights-ish.  I went by SFSU which is a huge campus.  Then, finally, The Bridge.  Its massive red towers are just as impressive close up as they are far away. I was glad the speed limit was 25mph because I was having a hard time keeping my eyes on the road.

There is a pretty wide sidewalk on both sides of the bridge so there were a lot of runners, bikers, and tourists.  Great people watching!

Once I was over the bridge, I came around towards Sausalito.  I have been there before via ferry and walked around but from the highway you can really see all the houses that climb the hill and run down towards the water.  The sailboats were surreal.

As CA 1 turned into 101, I had to exit and turn around and retrace my steps to get back to Los Altos but I still felt like I had accomplished something.  I think driving across the Golden Gate is something everyone should do at least once.  When I was back at my hotel, one of the employees there told me he drove across it for the first time just recently - and he has lived here his entire life! Maybe next time I am here, I will go across on foot...

Everything we do in IT costs something - time, money, or opportunity.   "What does it cost" is one of the top 3 questions we get in every introductory meeting.  The issue I have with this is pure timing....why isn't the cost of moving, converting, archiving, destroying - whatever - part of the planning of the new install?? I don't understand how project planners are getting away with leaving it out.

When costing out a system replacement, the cost of the new system, hardware, software, people, etc are all included in the cost estimate that has to be approved, typically at the board level.  These estimates usually include any kind of ROI or savings that the replacement will bring, including the ability to drop maintenance on the old system, retire the hardware and software, etc.  These plans are not even shy about identifying opportunities to reduce support staff for the old system.  In the old days, conversions were a standard part of the project plan.  These tasks got time, resources, and MONEY.

Now that big vendors are limiting or eliminating the option to convert into their systems, the disposition steps for the old system are strangely missing from the planning process.    We are coming up behind a lot of large projects that have not had the cost planning done for the retirement and it makes ANY solution a hard sell.  Without the money available, many organizations are just leaving the old system running and trying to eliminate as many costs around it as possible, like maintenance, upgrade costs, and even internal support staff.  This is a dangerous game when you look at the amount and types of data in the retired system.

If you are planning a system replacement - or maybe you are already in the middle of one - you need to go ahead and spend the time and effort to cost out the retirement options as well.  Get board approval for the dollars, even if the timeline seems to be in the distant future.   If you are already done with your project and you did not yet get costs approved for the retirement phase, bite the bullet and do it.  Its not fun going back to the well but better to be proactive than reactive.

EVERYONE seems to know and assume that data conversions create bad data.  So why do we continue to do it? Why is it in our project plans?  I recently paid a visit to a client who had converted scanned documents into EPIC.  No one really knows, 2 years later, what the criteria was for selecting the images that got moved.  The patterns are elusive; the rumors abound.  Maybe if the patient was deceased, the data did not get selected? Others notice that if the patient had no recent visits, their data wasn't in EPIC.  No matter which is fact or which is fiction, it boils down to the simple truth that some of the data is in the new system and some of it is in the old clinical system.

I was recently meeting with a user at this institution trying to help them figure out what to do with all those records that did not make it to EPIC.  As she was showing me her workflow, she was constantly experiencing an error message in EPIC that she took to mean that the old data was not available. She assumed that this was due to bad data or conversion issues - so her use of EPIC was less than optimal. Come to find out, she had a bug in her version of EPIC on her desktop that was causing the error.  She was living with this for 2 years!  A quick call to the help desk, a new deployment of EPIC to her desktop, and she can
see the converted scanned documents (at least the ones that were moved into Epic).  Still not ideal in that data is spread somewhat haphazardly across both systems - but yet another example of how bad data conversions can impact an organization.

How many other folks experience application problems that they "live with" because they attribute it to the bad data conversion?  Better to not convert at all so “bad data” is not an excuse for process
disconnects and workflow issues.  If you have the old data in an archival solution (like LDA) then the go live date is a clean cut over into the new system.   The new implementation is at least not “spoiled” by the reality or perception of bad data.

Your data is exploding.  No, not literally.  But, like the universe itself, it is expanding.  FAST.

Part of the problem is that we don't like to delete things.  Having worked as an IT consultant in the past I've seen some crazy things.  People who routinely crash their company's Microsoft Exchange e-mail server because they never empty their "Deleted Items" folder.  "But you've already deleted it, why not just empty the folder?" I would ask.  "But what if I need it later?" was always the reply.  But things get even more crazy when government regulations are involved.  Now, not only are we storing all our data and never deleting it, we're also storing all of the data about who is creating, reading, updating, and not deleting all of the data that we're storing.

While poking around the internet one day a few weeks ago I found a very interesting article in the Communications of the ACM entitled "Got Data? A Guide to Data Preservation in the Information Age".  If you have the time and resources I highly recommend taking a look at it.  The article highlights four trends that affect data preservation today:

1. More data is being produced than we have the ability to store. That is, sometime back in 2007 we passed the data equinox and are now producing more data than we have physical storage to actually hold the data.  Even if we wanted to capture and retain all of this data, we are just plain out of luck.  This may sound odd, but there is a lot of data that most users never see.  There is the data we work with every day.  Then there are supporting data structures behind those -- the tables that hold lists of pre-generated responses to questions, data in the form of executable code that runs the programs, source code for the executables, compilers, libraries, logs, oh my!  And that doesn't even touch the realm of personal data, where most of the digital age's content is generated.  A picture from a 1 megapixel camera can run up to 3 MB in size, depending on the format.  And who carries around a 1 megapixel camera any more?  My phone's camera takes higher resolution pictures than that!

2. The number of regulations and policies mandating data preservation is growing along with the data. First it was the HIPAA-potamos, then came the Sarb-OXen.  More rules and regulations are being produced by well-meaning groups who obviously have not read point #1.  For those in the healthcare or financial sectors, no further explanation of this point is needed.

3. Data storage costs are plummeting!  Almost. Storage device costs are dropping faster than Enron stock and drives are getting bigger all the time.  But the energy costs of operating these devices is not dropping.  And the energy consumption of these devices is not a cost to be discounted as trivial.  Just ask Google.  Not only that, but all those laws from point #2?  They cost money to comply with.  They cost more money to NOT comply with, but the cost of compliance is still a cost, albeit a somewhat hidden and non-optional cost.  And last, but not least, is the cost of the men and women who know what to do with the storage to make all the data magic happen.  In our increasingly information-driven economy the salaries for people with the technical and non-technical skills needed to make an IT project successful are not going down.  There is always international outsourcing I suppose, but there are issues of stewardship and trust in those scanarios.  Not only that but I've found people feel much better when then is someone within reach (i.e. choking distance) when things go wrong.

4. The commercialization of data storage is increasing. But hey, that's good news!  Someone else on the hook for compliance and worrying about 4 AM power outages.  Really it is only the natural result of the first three points.  There is a need.  The market, and some very bright people in it, are creating solutions.  Others have observed that a whole data archival industry is in the process of emerging.  Having pioneered that very industry for the last ten years, we here at Legacy Data Access think it's about time!

For those interested in the full article:

Berman, F. 2008. Got data?: a guide to data preservation in the information age. Commun. ACM 51, 12 (Dec. 2008), 50-56.

You may know a lot about your data - what you have, where it is, what value it provides, and even how to get to it.  But are you fitting the pieces together that go together to take the best advantage of it all? Do you have the right pieces of information available to you at the right time?

Recently, I was renting a car in the SFO airport.  I had a reservation for the correct date and a great rate.  I had my directions to get to the car rental center and my driving directions. I was organized; I was set - my data was at my fingertips and working for me. I was going to be in and out of there and on my way in short order.  So I thought.

I get to the car rental center only to find the line horribly long. I am talking HOURS long.  Apparantly the rental car company had some sort of a system breakdown and their computers were just coming back online.  (And I can blog about the mishandling and customer service issues around THAT in future posts...).  I was frustrated and obviously did not want to wait that long.  I looked down at my reservation and realized I was missing one key piece of information - I take great pains to pay to be a "special" member at this particular company so that I don't have to wait in line.  My number was NOT attached to the reservation. Here was a KEY piece of information that made all the other pieces I had meticulously pulled together virtually meaningless.

Luckily, I pulled out my cell phone while in line and called reservations. I gave them my confirmation number and my membership number.  Their computers tied it all together (hmmm, no outage there...) and  I was out of there in 10 minutes.

SO no matter how well you know your data, are you using it all together correctly, at the right time, to meet your information needs and business goals??

Man they are a killer!  I am in NorCal with my 11 year old son...he is visiting a friend and I am spending the week with my client.  It is 2:30 am to my body but sleep is somewhere in my distant future.

The hardest thing to me about the time difference is trying to manage clients on both ends.  In Atlanta, it is part of my routine to keep myself available until 9pm at night to get my west coast clients bedded down at the end of the work day.  Since I am on the west coast this week, I am dreading the 5am wake ups so I can be fresh for 9am eastern conference calls. And don't get me started about my Outlook calendar!  I cannot adjust the time zone or it messes up all my recurring meetings and does not seem to ever want to put them back correctly...so my west coast meetings are all on eastern time zone in my calendar but my iPhone is reset to west coast time -  syncing is a huge issue. Although maybe this is that iPhone App that I have been trying to invent??

I wonder if the PMBOK has any pointers for managing multiple projects across multiple time zones?   I had a potential job once that involved managing a project across 5 different time zones - I don't remember anything else about the job but that one detail - and it scared me off.  It would be interesting to know what tips and tricks others use in this situation to keep the customers happy and the projects moving without killing your internal clock...

Due to a minor accident concerning a toilet (clean water, thank goodness), we experienced some major water damage.  This has pushed us over the edge to finally remodel our kitchen and most of our first floor.  Being an IT project manager, it is always interesting to see how non-IT projects are managed.  I have to say that it is a good thing I am not the contractor.  I would be overwhelming the team with task lists, flow charts, critical paths, and the like.  They probably would have all quit by now.

In reality, they just sort of go with the flow.  They know what needs to come out, what is staying that they have to work around, and what they need to have it put back together.  They show a sense of urgency when it matters, like when they had all removed all my windows and an outside wall and the sky was dark and ominous - they knew they had to get the framing done and the walls covered before the rain hit.

They don't panic either, and they take issues and changes in stride. The contractor does not throw fits about scope changes - he knows our budget and if we suggest a change that is going to impact that goal, he says so.  We discuss it and move on.  When they removed my back door and found the subfloor all rotted, no one had to stop work and write up an issue and escalate it to the "Steering Committee".  They simply sent someone to the local Home Depot for the missing materials, fixed the rot, and moved on.

It is kind of refreshing.  It is making me pause and think how we could bring some of that culture into IT projects.  Sure, we have to make dates and manage costs. But we can do it with a sense of calm and collaboration.  We can look at scope changes and determine if there is room in the budget and if not, figure out how to live without the change.

Before you go thinking I am contradicting all my other posts about project preparation and planning, think again.  My remodel project is VERY well planned.  We have drawings and swatches, measurements, materials lists, and expected costs outlined to significant detail.  In fact, I would offer that it is this planning (which was started over 2 years ago) that is allowing the project execution itself to seem so laid-back.

I will post before and after pictures when it is all done.  Meanwhile we are cooking and eating in our basement kitchen (part of the planning!), spending quality time in our basement den, and looking forward to our new space.