Home  |   Subscribe  |   Resources  |   Reprints  |   Writers' Guidelines

April 2014

How to Keep HIT Projects on Track
By Robert N. Mitchell
For The Record
Vol. 26 No. 4 P. 28

To prevent HIT projects from veering off course, industry experts say it’s important to plan, build in change management processes, and regularly engage with system users and champions throughout the process.

Dave Gravender, CIO at Alameda Health System in Oakland, California, knows staff engagement can make or break any HIT deployment. In fact, he says if change control mechanisms have been planned and built into the process, then there’s no reason for a project to veer far off track. Should something go awry—perhaps caused by “scope creep,” which occurs when a project is not properly defined, documented, or controlled—it’s important that the change control processes kick in.

Katya Osipova, an associate director in Alameda Health System’s project management office, recommends health care organizations be proactive rather than reactive, be tactical, and regularly engage with key stakeholders throughout the project.

Why Delays Occur
Roni H. Amiel, CIO and chief information security officer at Blythedale Children’s Hospital in Valhalla, New York, says no matter the amount of time and effort an organization spends preparing, delays are an inherent part of any IT project. Often unavoidable, the hold-ups can occur for various reasons, including design errors, changes in the project’s scope, procurement or contracting ambiguities, and the project’s overall complexity, he says.

Because poor planning is a chief reason for project delays, Gravender’s team monitors the effort’s scope to make sure tasks stay on course. If they begin moving in an unfavorable direction, the issues are addressed and realigned where necessary.

Aaron Mulder, chief technology officer at Chariot Solutions, a Pennsylvania-based consulting firm, says delays typically are caused by one of the following:

Incomplete requirements: This occurs when the application or pieces of the application are ready but don’t meet the user’s needs. “Often what looked good on paper doesn’t match how real users work with the application or the application handles the most common cases but does not handle rarer, but equally important, cases,” Mulder says. For example, regulatory reports that end up being more complex than originally expected fall into this category.

Missing requirements: Some necessary piece of the application is missing or, during the time the application was being developed, new requirements arose and must now be incorporated into the schedule.

Integration problems: Because the integration often isn’t fully tested, if something fails, there’s no time left at the end of the project to troubleshoot or effectively fix the problem.

Are Delays Acceptable?
The tumultuous nature of HIT projects begs the question, is it ever acceptable for a project to be off track? Amiel says potential delays can be overcome. “You realize that a project schedule is not permanent because tasks and stakeholders’ needs are constantly fluctuating,” he says. “The project schedule is really an assumption about what may happen and when. It’s my job to continue to understand the reason for variances and make appropriate adjustments to meet the changing landscape, which has been built into the project’s contingency plans.”

Should an HIT project hit a bump at Alameda Health System, hospital leaders look to modify its scope and/or timeline to meet the original go-live date. On occasion, this means readdressing the deliverables if one phase has to be delayed. “For example, if you’re going to roll out three ambulatory clinics sequentially … and you discover an issue at the first that has to be addressed before you can proceed, we may decide to roll out the affected part of the system later to all three clinics at once,” Gravender says.

“Part of IT project planning and keeping a project on track is that, historically, CIOs have tried to encapsulate the business and IT into the scope of the project when it is purely a business or clinical initiative and not an IT project. Or there has been a significant underestimation of the size and scope of the project,” says Russ Branzell, president and CEO of the College of Healthcare Information Management Executives (CHIME).

“What I tried to practice when I was a CIO, and also what I’ve taught at the annual CHIME CIO Boot Camp, is the most highly performing organizations have clearly defined business and ownership objectives as part of the project plan and are truly responsible for the overall success and delivery of the project,” he adds.

Building Timelines
Detailed schedules are important to project planning and execution as well as understanding key knowledge areas and processes, Amiel says. “A timeline that considers strategy, functional requirements, budget, and stakeholders is likely to be successful,” he notes.

Setting and managing expectations are key considerations when building and managing timelines. Because staff members often are eager to meet management’s objectives, no matter what’s been asked, Gravender seeks feedback on what they consider to be reasonable. “They may say they can complete a task by the end of the week. It’s then the team’s responsibility to make sure that the revised completion date is a reasonable timeline,” he says. “Then, if it’s agreed upon, I hold the person accountable for what’s been agreed upon.”

Gravender occasionally will push back if he believes a timeline is unrealistic. For example, if someone suggests an ambitious schedule, he’ll investigate to determine whether the proposal is feasible. He takes into account the staff member’s other responsibilities and gathers the details on how the project’s goals will be met. “Often during these discussions, the person realizes they were setting an unattainable goal and agrees to a more manageable timeline,” he notes.

For regulatory projects with a strict deadline, flexibility is limited, says John Witt, director of the enterprise project management office at Alameda Health System. “We’re using an all-hands-on-deck approach for the ICD-10 project, including multiple resources and paying attention to what other hospitals are doing,” he says. “We’ve built in change management and escalation procedures to address any issues that may arise so we can respond rapidly to prevent delays from occurring. Also, because the project impacts the entire organization, there’s support from within the entire health system’s leadership team.”

One of the best ways to build reasonable timelines is to break larger projects into smaller milestones. “Often smaller parts of a larger project can be delivered separately and still contribute substantial value,” Mulder says. “There are several advantages to this: Smaller milestones can be estimated more accurately, and each delivery gives insight on the velocity of the development team and the accuracy of the estimates.”

No matter the timeline established, every HIT project must have clearly defined business and clinical ownership rules. “There must also be commitment and buy-in, and as the project plan comes into sharper focus, you must regularly go back to leadership to work through organizational relationships and collaborate among various leaders,” Branzell says. “This includes prep work and the governance that needs to be in place, and ownership for the project.”

— Robert N. Mitchell is a freelance writer based in King of Prussia, Pennsylvania.