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…