Everything I need to learn about HIPAA I learned from Y2K

HIPAA news tends to ramp up, die down, ramp up, and die down. A year ago, you heard about HIPAA issues all the time, and today, the discussion is less obvious. Perhaps the focus of the government on terrorism has delayed some of the regulations associated with HIPAA. But some of the changes are still planned for Fall 2002. Where the due date of Y2K could never be moved, the delays and regulatory changes associated with HIPAA have many companies under-investing it what could become the biggest project their company has ever done.

Success comes from being aware of history and not repeating it. In my project work, I have found that most companies repeat the same mistakes on their projects. In these companies, no time is taken to audit a project after it is done. No time is invested to capturing and sharing the lessons learned from a project. For this reason, HIPAA projects are doomed to follow many of the same mistakes made in Y2K projects. The Y2K and HIPAA projects themselves share the following characteristics:

•   Large size project

•   New technology

•   Complex and perhaps changing requirements

•   Fixed due date

•   Insufficient budget allocated

•   Large political interest.

If your company did some post project review of their Y2K efforts (or SAP, etc.), it would be great to look at these lessons learned before you get too far planning your HIPAA efforts. If they did not, take the time to find the project managers and ask them what they would do differently.

Because of this similarity, Y2K projects experienced many of the challenges that HIPAA projects will experience including the risk. See Exhibit 1.

It's Not the Code

The Gartner Group estimated that of all the hours spent on Year 2000 compliance, 10% was spent on analyzing the impact on existing processes and technology (inventory), 20–25% was spent coding, 10% was spent putting the changes into production, and 60% was spent on testing (see Exhibit 2). It's not a tough leap to realize that more spent on getting the requirements clearer (analysis) would influence less money to be spent on testing. In addition, testing late ripples through more components of the deliverables, and is much more costly to project progress in terms of both time and people resources. Learning to test early and often is always more effective, and will be so in HIPAA projects.

Based on the Gartner statistics, the biggest bang for the buck comes from figuring out how to do a better job on testing and doing a better job analyzing the need so that the testing will not be so time-consuming. These are the same figures preached in the 70s to sell structured development, and are the current stats behind much of the agile methodologies work.

Given these numbers, it makes sense to dedicate your limited project resources to the highly business dependent work of analysis and testing. Grow the skills in these two disciplines now. Consider outsourcing the more rote and less impact activities, including implementation and coding, to grow your staff's business knowledge in analysis work. Notice how coding tools potentially impact only 10% of your project, so may not be the best place to invest. Businesses have had success moving offsite and offshore, specifically to India, to get their coding done, but only when the business analysis and testing remain in-house.

Exhibit 1

img

Exhibit 2

img

Exhibit 3

img

Triage as a Way of Life

Even if you have started, it is highly unlikely that you will be able to get it all done. Many CEOs and CFOs are still not taking it seriously. Many HIPAA project managers are struggling with selling the need—no one seems to get the urgency and impact of HIPAA regulations. Start thinking about “What will stop the business?” Sell HIPAA through specific, measurable “down time” issues and regulatory fees. Prioritize the analysis to focus on these mission critical areas and work on them first. Like in Y2K, be prepared to fix the holes during maintenance. Many businesses “accidentally” incur much of the implementation cost avoided during maintenance. When there is under-investment in analysis and testing, there will be increased investment in rework after implementation.

Do You Still Need This?

If you can't fix everything, why fix something you don't need anymore? Just like moving, this is a good time to pitch the stuff you really aren't using, or shouldn't be. It's a bit like the old trick of stopping the reports one day to see who notices. This might be a good time to move the business area toward standard architecture, and wean off nonstandard platforms. This may be too much chaos for an already chaotic time, but consider freezing the nonstandard applications for now, with the hope of transitioning them after HIPAA is over. Fixing a bunch of nonstandard applications will be too costly for most businesses during the HIPAA efforts.

Compliance: Who Else Has This Data?

Many companies are not even looking at things outside traditional systems. For example, who's responsible for the internal health records of your own employees and where do they go? There is a great deal of focus on the health records of customers, but less focus on the health records of employees.

On a more practical matter, what if core systems software doesn't really work even though the vendor promised it would? Should you test it? Should everyone test it? Create a test plan for all of these types of dependencies. Count on it…external code is going to screw you up. Many Y2K projects were negatively impacted by the external code, not the internal code. Consider contracting up front for response levels and systems quality. Here is a process to consider—see Exhibit 3.

It's Too Late for Shopping

When the going gets tough, the tough go shopping. If you haven't started installing packaged software by now you may not make it before the first regulations take place. Projects planning to acquire vendor software to replace noncompliant systems should be well under way—the more lead-time the better.

If you are getting into this late, consider jumpstarting your efforts by doing the following:

•   Find out what company's that are similar are doing. Visit an HIPAA user group meeting. What vendor's names keep coming up? What are the problems companies are having with these vendors? Can you leverage other people's knowledge?

•   Search the trade articles of case studies about HIPAA vendors. These are not always 100% reliable, but it might give you a starting place.

•   There are lots of HIPAA resources available on the Internet, and most are free. Take the time to build your knowledge through research. Time box time to learn as you go.

ROI: Capital vs. Expense

HIPAA project work, like Y2K work is an accounting nightmare because the work is strictly expense—millions of dollars worth. An expense, unlike an investment, comes right out of the profit. Investment work can be depreciated, and there can be tax benefits. Expense, specifically HIPAA work, is not an investment and the only return is that you avoid large fines. If you build the project around some new business need or development, you can capitalize it but that expands the scope.

Managing Scope

Any time you start to make changes in software there is a tendency to expand the scope, which with HIPAA is pretty big already. Most agreed that the scariest words in Y2K were “While you're in there…” Managing the scope tightly is the #1 critical success factor for HIPAA projects. Just because changes are being made, is not a good reason to make additional changes that are in the backlog. The backlog needs to be frozen as much as possible so that the proper attention can be spent on HIPAA.

The things you can negotiate and manage are in Exhibit 4.

Exhibit 4

img

Liability

Have you thought about calling the legal department? The stockholders may be able to hold CIOs, CFOs and CEOs financially liable if the company value plunges due to its foolish handling of HIPAA. This may be just the negotiating tool you need to get the resources you must have to succeed.

Why Mission Critical Projects Always Fail

Did you ever wonder why those unimportant, pilot projects always go great and why the important real projects always fail? It's simple—they fail because they are important. The most significant reason is the people.

Look at what has happened time and time again. The project gets started and everyone is optimistic. They are all willing to give their all toward success. Unfortunately, unlike a pilot project, no one is really sure what success looks like. In this HIPAA example, some of the regulations aren't even finished yet. Certainly the goal is to be compliant, but large, complex projects need more to track progress. Formal project management, including a project manager, a project definition and a detailed project plan, are more critical in cases like this, when there is more risk. Ironically, the more critical the project is, the more anxious the project team is to jump into quickly without doing adequate analysis and planning. Strategy is quickly compromised to speed. One of the most important first steps is to create clear roles. Here's a sample Project Organization for HIPAA:

Then the first glitch happens. Most likely, people who are critical to the prioritization of the project work are unavailable for meetings. The wrong people, again in difference to the schedule, make decisions. The important project is now a little behind. Psychologically, the shine has started to wane on the project. The team who started thinking this was an exciting project now starts to see that this project may be similar to all the others. They begin to lose faith in the project, and their ability to deliver.

This is an important project, so it is very visible. The Project Sponsor calls the Project Manager to stress the importance of this project, adding pressure. The Project Manager demands that everyone put their nose to the grindstone maybe even pitch in a little overtime. There is now more pressure to sacrifice good project management technique for schedule.

Exhibit 5

img

Exhibit 6

img

As people isolate themselves into their “real” work, nobody communicates with anyone else. Nobody has the time to talk; they are too busy doing real work. In the short term, this attention to work pays off and seems to help the project progress. Lots of interim results reinforce this “work harder” mentality. However, in the longer term the individuals have begun to define success in their own individual way, shooting at different targets. Eventually the project will run into a large roadblock, with people on the project team redoing or destroying work done by other members that they didn't know about.

Notice there are two things to do when things get tough—improve the process or do the same process more. Most project teams doing the same process more—more overtime, more people and more trying. When you do the same process more, it appears to work in the short term. Adding overtime hours, for example, adds 25% more performance. The other eight hours aren't improved at all; in fact, they may be degraded because the people are tired from all the overtime. So, sliding performance quickly overtakes the initial improvement. Exhibit 6 is model that helps improve the process.

When you stop to improve the process, your short-term progress suffers. But by making the way you do work more efficient, all the work done from that point forward is improved. The whole eight-hour day more efficient, so a person doing eight hours of work today may generate the equivalent of an energetic person doing 10 hours of work with the old process. It makes long term sense, especially in a mission-critical project with lots of unknowns, to take the time to step back and look at how the work is being done, not just doing it as quickly as possible, nose to the grindstone. Intuitively, it is the opposite of what most people choose to do given a political pressure and an optimistic schedule. It takes great courage to set project work aside and risk getting behind in order to improve the way the whole project is being done.

Exhibit 7

img

The cost of not stepping back is total failure. As everyone's nose is to his or her own grindstone, the project strays even farther off course. The Project Manager screams at everyone to try harder. The communication is now gone completely since people's tunnel vision limits their ability to understand what others are doing. The project is doomed.

Part of the solution is something that must be done from the very start; it is almost impossible to retrofit in times of stress. Keeping a clear vision of success (why are we doing this project?) and communicating constantly and unfailingly, especially when it changes, is the full time job of the Project Manager. If the Project Manager cuts back time for communication (which is normally the first thing to go on important projects) the important project will fail. Exhibit 7 is a checklist for things that are needed in a project of this size and complexity.

HIPAA is a large, complex, unstable, time driven initiative. Other than that, it shouldn't be any problem at all. All these characteristics speak to a large risk of failure. As risk goes up, intentional project management activities should go up as well. A good HIPAA project manager will time box plenty of time for stepping back, thinking about the effectiveness of the project strategy, and stepping courageously forward to adapt the strategy as necessary. The lessons learned during Y2K can be summarized in one phrase—flexible structure. Companies that maintain a tight HIPAA plan at all times, to address the more specific issues covered in this white paper, while being willing to adapt the detail when needed, will succeed, just like theY2K projects ahead of them.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 · San Antonio, Texas, USA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.