For weeks, the error-ridden launch of healthcare.gov has dominated the headlines, but to CIOs, there’s nothing newsworthy about the idea of forging ahead with project that isn’t ready. And in fact, most have been in a similar situation. According to the November healthsystemCIO.com Snap Survey, 71 percent of CIOs have been associated with an initiative that stumbled out of the gate, and a whopping 86 percent have felt pressured to forge ahead with a project that was fraught with errors.
Times like these require CIOs to “stand up and lead,” which means gathering all the facts, making the tough decisions, and standing their ground, one respondent noted.
“I was able to negotiate changes in scope so that date could be met,” said another. “I would have resigned if not. It is better to leave with conviction than to hope it will work and fail.”
Unfortunately, “There are always folks that are afraid to hold up the stop sign. They fear that the outcome for their inability to meet the established deadline would be worse than moving forward with something that is just not ready,” according to one respondent. But ultimately, a failed implementation will leave a much more scathing mark then a delayed project, respondents found.
The most common reasons for postponing go-lives were poor planning and competing priorities within the organization, with one CIO adding that any plan must “have flexibility to allow for scope and resource adjustments.” The more time spent carefully planning a project, the more likely an organization is to be able to foresee potential issues and successfully meet deadlines.
Interestingly, the majority (57 percent) of respondents indicated that they weren’t surprised that the government forged ahead with the insurance exchange despite the red flags. “No one in government is ever held accountable for blowing past the budget and not delivering on the stated promises,” one CIO stated.
(SnapSurveys are answered by the healthsystemCIO.com CIO Advisory Panel. To go directly to a full-size version of any individual chart, click on that chart.)
1. Were you surprised that the government moved forward with the launch of healthcare.gov, despite the potential issues?
Yes, it should have been delayed
No, they were under too much pressure to postpone it
- Haven’t we ALL been in this position before?!
- This has near nothing to do with what is correct or right. It is 100 percent a political hot potato…
- But I could tell from how our state exchange was going that there would be major problems. All governments should just face the fact that they can’t manage an IT project. Their record is far worse than healthcare IT. A call to Amazon or Google would have been less costly and would have worked on time. Governments tend to try and recreate the wheel when it comes to IT projects.
- Politics — it was all political and a huge mistake. Typical Chicago politics.
- Yes and no — it’s fairly apparent that politics is winning over rational thought and the fact that no one in government is ever held accountable for blowing past the budget and not delivering on the stated promises.
2. Have you ever been associated with a project that failed or stumbled out of the gate?
- Implementation of an EHR in 1991 was very difficult due to immaturity of product and clinician adoption.
- Had bumps, required scope change, etc. But any senior worth their title knows the importance of testing and expectation management.
- Not of this magnitude. No one outside government would survive this debacle.
3. Have you ever felt pressured to forge ahead with a project that wasn’t ready to launch? (If answered ‘Yes,’ please explain in the comment section how you reacted to the situation.)
- No one remembers a delay, everyone remembers a failed implementation. Always delay if risk is high.
- I got all the facts together. I put them in writing and put in writing what the proposed launch date should be. It does no good to say, ‘We’re not ready’ if you don’t have a proposal for when you will be ready.
- Against my better judgment in the past. Now I’ve been stronger at arguing for a different posture.
- I’ve reacted differently depending on my role. As CIO, I will not allow projects to move forward that aren’t ready.
- This is more common than not. With facts at your side, this is where a senior executive earns his/her keep. It is about risk management, but under no circumstances would I ‘allow’ a launch if we had facts that supported a failure… and we should have them.
- I was able to negotiate changes in scope so that date could be met. I would have resigned if not. It is better to leave with conviction than to hope it will work and fail. Unfortunately many of my peers don’t follow this advice.
- The vendor pushed very hard to implement a major upgrade that wasn’t ready for prime time. They argued that they would be onsite and would fix any problems discovered after go-live. I pushed back and ultimately delayed the upgrade by 4 to 5 months. This exchange prompted a search for a new EHR vendor.
- That is when you have to stand up and lead. At least make certain all stakeholders take part of the risk.
- There are always folks that are afraid to hold up the stop sign. They fear that the outcome for their inability to meet the established deadline would be worse than moving forward with something that is just not ready.
- There was pressure from the top down because the Board and Medical Staff were promised a go-live date. It was not a “failure,” but we knew exactly what issue existed that could have been avoided with another 30 days. We spent the next year recovering from the user backlash.
- Meaningful Use is making this happen every year.
- We did the best we could, but those decisions were made above me. It came back to bite us.
4. In your experience, what has been the most common reason for having to delay a major project?
Lack of resources
- Change management/control
- Projects always fail at the beginning — not at the end. A project consists of resources (financial and human), a scope, and a timeline. The scope drives the resources and timeline. For an 18-month plan, you should spend 4 to 6 months just creating the plan. It should have flexibility to allow for scope and resource adjustments. If you spend 6 months planning a large project, you are more likely to hit the date and if not know way ahead of the date that there is a problem.
Competing priorities within the organization
- No one really prioritizes as well as they think they are, and no organization has static resources. That means you get in a pinch periodically that requires tough decisions. There are worse things than missing a projected go-live date that was set without having full information
- Competing priorities in both my organization AND our vendor partner organization.
External factors (government mandates, etc)
- Lack of valid or appropriate testing
- Testing encounters major issues. I was overseeing a major infrastructure upgrade. We encountered major connectivity issues as we did our final testing two weeks before go-live. We had communicated the go-live extensively and had resources scheduled. We made the decision we could not go live and hoped we would resolve the issues in time, or it would not be as bad as we thought. We ended up delaying twice. We finally went live and had no issues. The executive staff supported us not going live when I documented the risks.
- All of the above
5. What is the biggest downside in asking to delay a major project?
Reallocation of funds or resources
- Delaying a project costs money. Most likely this money is not part of the project budget, so you need to get creative. The earlier you know that a project is in trouble the better able you are to make adjustments with budget. If you are first finding out about this 30 days before go-live, then reallocation becomes more difficult and the other two items (loss of credibility with board and reprioritizing other projects) come into play.
Loss of credibility with board
- Or rather, loss of credibility with organization.
Having to reprioritize other projects
- The others are just collateral impacts.
- Extra expense
- Loss of credibility with internal executives. IT is judged on bringing projects in on time and on budget, so it is always a loss of credibility when a communicated go-live is delayed or postponed. The other issue is that it usually backs up other projects, creating other resource issues.