What is Throw Away Work Really?

Every information management project has a certain amount of waste; it is inevitable. Throw away work that is staging as a means to an end, in other words, a goal’s goal’s goal. The larger picture trumps what seems to be stupid at the doing level. Doers occasionally need to visualize their work as scaffolding. It is there to support the process temporarily, making it possible to work on the actual project. As the image suggests, no work is throw away, there’s always the experience and learning that is invaluable the next time.

The whole goal might be to move off of one platform and on to another. If you stay long enough at one company, you will experience this at least a few times… This type of goal depending on the size of your user dependency and content could be a Mt. Everest climb. The staging would be all of the interim work.

Interim Nuts and Bolts Stuff

Here’s a typical list of necessary Interim throw away activities:

• Upgrade the OS and database to meet the new software’s support requirements.
• Export content and metadata to a temporary storage area
• Map and process data to conform to the new build
• Train Users on new platform

Here’s what might not be necessary:

• Rewrite existing customizations to work on the new platform. The new software’s functionality will most likely leap frog these. A thorough analysis is warranted here.
• Migrate to a half-way point to meet a C’s deadline

1%er Deadline

If you are lucky enough to be a part of incentives to meet your company’s goals, then this may not interest you, but for the rest of us it should. For large projects, the incentives increase as you go from the doers, to the managers, directors, and C’s. These are usually tied to deadlines whether they are realistic or not. As I have said in other posts, quality and overall costs suffer when deadlines are imposed without total buy-in from parties involved. Capital is used for contractors who estimate work based on previous jobs and have a huge list of assumptions. Basically, it’s a trap of change orders within the big project’s budget.

What was really thrown away?

As the scaffolding is taken down, revealing the latest and greatest solution, we have to feel a sense of pride in completing it. No work is completely useless, it has worth; at least I like to tell myself that. Maybe you learned a new framework, or a coding language, or how to do a traceability matrix.

In retrospect, a project is never really finished anyways. There’re always follow up phases; “Nice to haves” put off until after go live. So try to take solace in being a cog in the process and look to the future of doing it with more coordination and influence the next time.

Budget Black Hole

Why is it that almost every IT project has a budget based on guestimates, bound by fuzzy scope, and goals that are usually too constricted? Every time a project methodology is executed, the budget is in the books, not to be revisited. It is just a given, not flexible and not based on specific enough goals. Management will assure us that changes can be made, but how often does that happen, and which projects take priority by the end of the quarter (or bonus time)?

Goals

You can’t just say, for example, that our goal is to do “x” to content by the end of the first quarter. The first you hear about a project, it’s your responsibility to ask, “What are the specific goals?” and “Were these goals fully funded?” Asking questions like these will give your project manager pause, especially if you ask, “What are the success criteria?”

Success Criteria

Large companies have ways to pay for projects from other capital budgets to assure some form of success. The issue is does this success include all of the long-term aspects associated with a strong solution. When it comes down to the wire, we know that testing and quality will suffer if corners are cut from lack of money.

Here are some tips on creating success criteria.

• Combine at least two aspects of success together, for example, migrate all content with 100% accuracy and on time. Notice I didn’t include how much it will cost.
•  Include a stabilization period after go-live because there are always unanticipated issues after a large deployment. This will give the extra confidence that managers and Users need that issues will be resolved in a timely manner.
• If a project is large, then don’t just break out the normal parts, breaking it out to smaller projects which can fulfill smaller goals, with the common understanding that whole will be larger than the parts.

Scheduled Scripting Jobs: from Documentum to OnBase 11

One of the biggest surprises of working with OnBase was when I couldn’t find a way to run a scheduled job to execute a script. As simple as it sounds, there’s way out of the box way to run a script when you want.

So here’s what I did to work around this:

First Solution: scheduling a scan queue sweep to fire off a VB script

Steps

• Put an empty file in a shared directory
• Set up a scan queue to sweep in the file
• Hooked the VB script to run on commit of the scanned batch which was configured to go through automatically
• Scheduled the scanning to run every 10 minutes

Outcome:

This worked ok, but was a kludge.

Second Solution: create a looping lifecycle with one doc in it that went in circles

Steps:

• Create a lifecycle with a work queue and a timer
• Add a Unity script to the timer’s action
• Add a doc to the workflow to trigger the timer and script execution

Outcome:

So far, so good

Hope this helps those of you who are stumped like me why this is not built into the product.

What Makes ECM Last Longer?

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them" -Einstein

On first reading of this, I thought it meant we need to think outside the box to solve future problems. However, after reading a few more times, I realized that he is also implying that solutions now are problems in the future, in other words, the effectiveness of the solution is directly related to the level of forethought given to it.

How does this relate to ECM issues? Take for example, storage. Why is it assumed that storage will always need to be expanded to accommodate new content? What if a better compression algorithm reduced the total size of the files by 100%? Or, a retention policy actually kicked in after many years of waiting and disposed of files? Thus, plan for 10 years of expansion, 10 years of Moore’s Law lowering storage costs, 10 years of fluctuating goals, and finally after 10 years, storage will shrink for retention policy content.

How about workflow? If you have a complex process which was “automated” in a workflow a few years ago and is now very expensive and time consuming to update, what do you do? You could simplify it by stripping out the parts that are not worth the hassle of updating. The “parts” are usually exceptions to the main purpose of the workflow. The exception will change, so a little change management forethought could save a lot of money in the long run.

So, what happens with ECM implementations when problems occur and the folks charged with fixing them were the ones who designed it? It depends of course on the issue, however the larger the issue, the more it makes sense to have an outside party analyze it to provide different logic on how it occurred and possible remedies. The nature of contracting is to get the next phase of work, so that is up to you. Given the analysis and options of fixing the problems, the in-house resources are usually the best folks to work on them, given the negative effects of not engaging them.

Where does data quality start in Healthcare IT?

You don't see anyone commuting with a muscle car from the 60's on the highway, so why do we tolerate old, upstream applications like patient registration, accounting, and interface hubs which introduce major data quality issues that cascade downstream to other dependent applications. Let’s try to frame these issues in the following ways:

1.       Historic Applications

a.       A patient registration system can be the oldest system in a healthcare setting, along with billing and accounting. This is the frontend system which feeds most other systems, why is it neglected?

b.      Any tier 1 applications which were deployed at a company were designed with requirements that lack the proper enterprise expanding capability. This is just inherent in any pipeline application.

c.       These apps are the most expensive and are most difficult to change. They have the oldest looking UIs.

2.       Over the wall responsibility        

a.       The application administrators work in their own silos. Take for example the typical groupings of IT: Financial/HR, Clinical, Imaging, Administrative, LIS, ECM, etc.

b.      Each of these has its own management hierarchy, therefore each has its own agendas and objectives.

c.       Differing departmental goal priorities often clash between these application groups. One Director has a goal which is aligned while another does not.

3.       The interface cannot hold everything together

a.       To accommodate the “historic” application’s lack of flexibility or expense to customize, the interface takes on the role of tracking and rules for filtering and routing data.

b.      In addition, to fill in the gaps that the “over the wall” mentality introduce between applications, interfaces help, however, on the flip side they create problems as requirements and applications change.

4.       Infrastructure Attitudes

a.       Systems admins don’t have the time to review new requirements, they are busy with storage and performance issues.

b.      DBAs can’t be bothered by development questions

c.       Storage and asset management manager only care about keeping the lights on.

It’s no wonder data quality suffers as historic applications become more rigid, departmental priorities clash, interfaces act as super glue, and infrastructure have their heads in the sand. There is not enough transparency and cooperation between the application “owners” to work as a true enterprise system. Of course, some companies are better at managing quality of information and have more resources to do so. However, a few foundation changes could make a difference:

1. Make sure the first applications which introduce information integrity are the best in market (change the budget if needed to achieve this!).
2. Create a system of living documentation for application requirements for all to see, understand, and modify.
3. Encourage sharing of ideas on how to reduce the amount of interface custom rules, pushing the business rules back closer to Users and front ends.
4. Reorganize through a program/project management office the influence that business analysts have on change management and how they can get results quicker from infrastructure and application engineers.

Sharing: a big component of project success

Throughout the many projects I’ve worked on, the most successful were those where the team members gave more than they got, in other words, they went out of their way to troubleshoot issues, to meet deadlines, to test, and most importantly to be honest.

Sharing is not trait that comes first when there are bossy personalities leading the project. A deadline driven outcome is just that, an outcome that meets someone else’s goals, not necessarily the goals of the project.
Sharing is not present in a project that relies too heavily on its initial requirements and assumptions. Sharing blends better with an Agile project, one which can expand or contract in scope given the inevitable changes with the business and competitive environment.

Sharing is surprising among teams that are not use to it. Usually when I go out of my way to figure out an issue or to do work closely with someone to figure out news of thinking about process automation, the person who I help is thankful and a little shocked. Maybe they are too used to the way contractors operate, that is, hearing, “we can do that, but it is a change request”. In other words, you pay for every little enhancement, no nice to have’s here.

Sharing is most effective during the initial and post-go-live phases of a project. Be honest and open with requirements without getting too bogged down with the “hows” of the software implementation. Set up the idea of “phase 1” and “phase 2” first thing when the project scope is increasing too much.
Sharing during post-go-live is key to finishing that phase and winning the next phase. Every project in ECM is endless… Some business leaders know it more than others. The game is to give as much as possible to assure the best quality of information and the best treatment of the Users who are in the trenches. Catering to the managers and directors only ask for long term issues.

Signs a project has problems

Who’s complaining?

If the IT team is complaining about the business not doing their share of the work, then the goals are not clear enough and are not tied to direct accountability. Why would you expect someone to go out of their way to help when that person has no “ownership” of the project? How many times has IT bulldozed an initiative through the business successfully without full cooperation and understanding from the business side? So, if individual team members of the IT team are annoyed, it’s time to reconsider the approach to implementing the solution; somewhere along the line a piece of the puzzle is missing, and it will be obvious when you look for it.

Dotted line agreements

Your project is large enough to span systems which integrate. There is a risk in planning a project with teams who have competing objectives. Scheduling the rollout of the project can be tricky. The dotted line between your project’s goals and the associated extended teams can be deceiving. Make sure there is enough oversight by a “steering committee” which will back up the project during the critical milestones and implementation.

It’s when issues come up

Designs and specs can fall apart when seemingly insurmountable problems arise. In large projects, issues always rear their ugly heads. This is when the team’s cohesiveness is tested. Will everyone rally to fix the issue in a timely manner? When a project schedule slips, there’s usually an issue. The root of the issue can be traced back to some assumption, scope creep, personnel change, etc. The root needs to be explained, transparent and fully understood. This is the learning moment and shouldn’t wait for a post mortem. Explaining what went wrong after the fact is lame and not as impactful. 

Retention Policy: ECM’s software solution vs. what is required

Scenario: you have hired a consultant who has experience in implementing an ECM software’s records management module. This consultant meets with various groups and gathers requirements with questions that pertain to the vendor’s out-of-box solution. The legal department is focused on complying with current laws and regulations around how long to keep their content. Many weeks have been spent on creating a folder structure that conforms to how the software works, that is, if a file is moved to that folder, a retention policy is applied, and the retention period starts. According to proven waterfall methodology, a pilot is executed and signed off on. During go live, there are issues with importing documents and the legal department can’t find their content.

So, what happened with the frozen situation?

First, just because an ECM suite has a product/module for sale that is named the buzzword you are trying to implement doesn’t mean that it actually helps automate the process or simplify the ongoing work involved. In many cases, the module is an “add-on” originally purchased from another company to fill in the ECM suite offering. This could mean that the solution solves issues of the companies who were involved with the pilot or beta of the product. It definitely is designed to meet many general requirements, but will miss 20% of yours, guaranteed.

Second, if the implementation analyst is a consultant, chances are good that something will get screwed up. A good technical assurance management is required to maintain a more balanced point of view, but most companies don’t have them. They may have review boards, but this is not the same as a person on the project who is directly responsible for successful implementation.

Third, if your company is implementing records management for the first time, or reviewing the retention policies in place, you might want to look at healthcare EMRs for reference. Hospitals have been working under HIPAA regulations for a long time. Their information management systems, AKA EMR systems, are all about taxonomies, access control, and retention. Chances are good that they currently keep all electric records indefinitely. This is not a bad policy because ways of organizing information change over time.

Fourth, as content/info management technology improves, overzealous records management implementations slow down upgrades, and changes in metadata and folder hierarchies become major headaches.

Five, personnel changes create havoc around migrating “ownership” of retained content. Does the system allow you to make user accounts “inactive”? If the owner is deleted, does the retention period get reset?

Six, as far as the pilot is concerned, it is typical for a consultant to run unit tests as a super user and for a power user to UAT the pilot. The actual Users are not mandatory participants which is the big mistake. They need to make the time during the pilot beyond executing test scripts in order to fully vet the implementation. The should expect many issues, if there aren't, there will be after go-live.

The bottom line is that retention policies are overrated. I believe the trend will be to simplify these implementations and make it easy to manage in the future not harder…

An IT Project's Soft Deliverables

As an ECM specialist, you know that every time you are involved with a project, there are requirements gathering activities. It doesn’t matter if the project is small, or that “there’s a ton of documentation”. It may be as simple as writing a document that references previous deliverables to build on them. Because content processing is in constant flux there is more a need to not only keep your documents up-to-date, but to keep the non-deliverables going smoothly as well. What do I mean by “non-deliverables”? Well, I’m glad you asked:

Here’s the standard list of hard deliverables:

• Charter
• High level Goals
• Budget
• Resources
• Milestones
• High level deadlines based on upper management goals
• Interviews
• Demos of software OOTB capabilities
• Brainstorming sessions
• Goals refined by business group’s focus, rolling up the high level goals
• Requirements
• Traceability matrix
• Functional Specs
• Logical Architecture
• Use Cases
• Test Cases
• Schedule
• Meeting minutes
• Pros and Cons
• Cutover Plan
• Communications
• Training materials
• Etc.

·       

I here’s a list of soft deliverables:

•        Trust and Presents
•        Quality and Inclusiveness
•        Dependable and Honest
•        Generosity

Let’s look at each of the above “soft” deliverables and how important they are and discuss why projects can be disasters without them.

Trust

I know this goes without saying, but trust is earned, it is not a given. Meeting face to face and getting to know the stake holder(s) and the team is essential. This is a mutual trust. If I say I’m going to do something, I do it, if they say they will do it, they should do it as well. Many times a stake holder will not have time to attend all the meetings. In this case, you have to make sure the stakeholder is delegating tasks to someone else. You also need to make sure that meeting notes are written and that issues and next steps are clear to everyone, with follow up emails stating the near term timelines to get things done. Managing expectations goes hand in hand with trust.

Quality and Inclusiveness

As you interview stake holders as to what their goals are and what they expect the project objects should be, you need to make you ask about whom to include in meetings, who is actually doing the work which will be automated. Pay attention to detail and use the tools such as Visio to visually show and review the processes. There is no such thing as a workflow which is completely done, every time I review a use case or flow on my own or with members of the team I find new exceptions and new ways to looking at the process. The quality of your attention and understanding is crucial. Including as many reviewers and encouraging feedback is also key to the success of the project.

Dependable and Honest

I am not going to preach about the differences between a full time analyst and a contractor, but I will say this, that a contractor is not going to be around for the long run (usually). This means they will say and do things that get the work done at hand. What about the future of the project? That’s someone else’s dime. The stakeholders need to be dependable as well. A project is doomed if the governance of the execution of the project is in flux. A project manager cannot hold to a schedule if the resources are double allocated.

Generosity

We all work hard. Going out of your way to make things happen “the right way” will always benefit the project. We shouldn’t just write documentation because we have to. We should write it because it will help during testing, it will help during the next upgrade, it will help you remember the approaches taken for your next project. Writing to a standard template may work for a contractor, but if you go the extra mile and write for quality and give your best, it will show in the project’s success.

The flow of IT in Healthcare

This diagram shows the information flow for a patient in the healthcare information realm. As you can see, the flow goes as fast as it can toward billing insurance. It does not necessarily care about the patient and the quality of the information. As long as there is an account number, it’s full steam ahead!

As a patient, you feel this. What’s the first thing you do when you go to the doctor’s? You don’t get triaged, you get asked for billing information and oh, by the way, what are you here for? Shouldn’t it be the other way around, like when you bring your car in for service? Have it checked out, then if there is an issue, talk about how much it’s going to cost, then agree or disagree to the service.

Information Technology is a patch applied to a system wrought with politics and policies which have been analyzed over and over again by the best consultants money can buy. It’s a wonder that IT has been this successful in pushing its automation techniques into the heart of healthcare. The disputes between nurses and doctors continue, IT is in the mix now. As Healthcare systems own insurance company, so do insurance companies own hospitals and physicians. Everyone is in line to make money to survive and grow.

Expanding healthcare is fine, but the issue is that the patient has to be vigilant more than ever to ask for all visit related and referred information. They will be tangled in the vines if they are not the keeper of their electronic records.

OnBase VB Script and Thick Client API to export all image pages

Link to other onbase scripts.

Below is an OnBase VB Script and Thick Client API to export all of an image's pages:

Sub Main35()

Dim objApplication, objCurrentDocument
Dim MZ_API, MZ_FIRST
MZ_FIRST = 0
Set objApplication = CreateObject("OnBase.Application")
Set objCurrDoc = objApplication.CurrentDocument
Dim filePath, memHandle, MZ_LOCALPATH, MZ_MULT_TIF4
memHandle = 0

Dim exportDirectory
exportDirectory = "\\share location\"

Dim mzApiSessionHandle, mzAPI
mzApiSessionHandle = ScriptAPI.Session
Set mzAPI = ScriptAPI.Object
Dim returnCode : returnCode = 0

'MsgBox "objCurrDoc.Handle is-" & objCurrDoc.Handle

returnCode = mzAPI.mzInitQueryByDocumentID(mzApiSessionHandle, objCurrDoc.Handle)
'MsgBox "1 returnCode is-" & returnCode


Dim mzApiQueryHandle
mzApiQueryHandle = returnCode
returnCode = mzAPI.mzExecuteQuery(mzApiQueryHandle, 0)
'MsgBox "2 returnCode is-" & returnCode

Dim returnDocumentHandle, outDocumentName, outDocumentType, outDocumentDate, outFileFormat, outRevision, outComment, msg

returnCode = mzAPI.mzGetDocumentInfo(mzApiQueryHandle, MZ_FIRST, outDocumentName, outDocumentType, outDocumentDate)
returnDocumentHandle = returnCode

Dim fileExtension, returnedFilePath
fileExtension = "TIF"

returnCode = mzAPI.mzGetDocumentPage(mzApiQueryHandle, returnDocumentHandle, -1, "Image File Format", 0, 1, 8, returnedFilePath, memHandle)
'MsgBox "returnCode: " & returnCode & vbcrlf & "returnedFilePath: " & returnedFilePath
returnCode = mzAPI.mzEndQuery(mzApiQueryHandle)
Set mzAPI = Nothing

Set fso = CreateObject("Scripting.FileSystemObject")
fso.MoveFile returnedFilePath, exportDirectory & objCurrDoc.Handle & ".TIF"
Set fso = Nothing

End Sub