You have /5 articles left.
Sign up for a free account or log in.
Every tech person that I speak with agrees that the problems with healthcare.gov were totally predictable.
The basic lesson that the academic tech community seems to be taking from the healthcare.gov debacle is that something similar would never happen to us.
This is the wrong lesson.
We need to learn from healthcare.gov so as not to repeat the same mistakes that the federal government made in our new platform rollouts.
10 lessons:
Lesson #1. Never Over-Promise:
Everyone involved in the roll-out of a new platform, be it an LMS or an insurance exchange, needs to understand that bad things are bound to occur. Technology is always broken. The best we can hope for is that we can rapidly diagnose and fix the problems.
It is fine to talk about the benefits of the new platform. The reasons to make the change. But keep the focus squarely on the goals, not the means. The technology is the means.
In education the goals are around improving learning, lowering costs, widening access....etc. etc. Figure out and talk about your specific educational goals for your new platform. Then talk about why the technology is an important piece of meeting the goals - but be careful to communicate the limitations of the technology.
Be honest that there is going to be a learning stage, and that things will be harder before they get better.
Lesson #2. Test, Test, Test:
Testing takes place before the soft rollouts. Before the community ever touches the platform. Testing is with the internal team. Ample time for testing is built into the project. A new platform should never be released to the community until the team that will be running the platform has had plenty of time to beat on the thing.
Lesson #3. Do Pilots:
Is it really true that there were no full-scale pilots (with real people) of healthcare.gov? How could that possibly be? We are actually pretty good at doing pilots in higher ed. Part of our ability to do pilots is that we like to socialize decisions. Get more people on board. Have the decision to move to a new platform be a faculty led decision.
The benefit of pilots is of course you learn where things go wrong. The people involved in the pilots will have a higher acceptance for tech problems, and the academic technology team will able to focus more of its resources and attention on a limited number of users.
Lesson #4. Roll-Out in Stages:
Never, ever, ever do a "big bang" rollout. Even with all the testing and piloting in the world you will discover major problems when large numbers of users (and users with a different profile than the people in the pilot) start to hit the system.
Tech problems are normal. They are expected. A staged rollout will again allow your team to devote resources to a smaller number of users, while protecting the full community from the worst of the issues.
Lesson #5. Staff for Resiliency:
Campus wide technology rollouts are people intensive endeavors.
Everything that I read about healthcare.gov leads me to believe that the government offices responsible for the rollout were wildly understaffed. That the thought that they could rely on contractors and vendors to manage the new site. That is the worst mistake that any organization can make.
It is essential to hire your own quality people, and to do so in numbers large enough to handle the implementation, integration, training, and support problems that are going to occur. Vendors and contractors are a resource, they are not a substitute for the people responsible for introducing, maintaining, and supporting the system.
Lesson #6. Communicate Early, Openly, Honestly, and Frequently:
The communications project plan for a big new platform rollout is as important as the technology project plan.
The amount of time, resources, attention and expertise devoted to communication needs to be at a level that is near parity with the resources devoted to implementation.
This idea, of course, is very difficult idea to put into practice.
Resources are constrained. Technology experts are not communications experts.
Too bad.
It is nearly impossible, (at least I've never seen it done), to invest too much money in communications around a big campus wide tech rollout.
Lesson #7. Invite Dialogue:
Communicating is not enough. The goal should be to create an authentic and vibrant dialogue.
Both critics and advocates need to be addressed. There needs to be multiple platforms for two-way discussion. Many people in the organization need to be trained and given the authority to have these conversations.
Lesson #8. Have A Single Point of Accountability:
Any big campus wide tech rollout should have one person who is accountable for the project. It should be clear to everyone who that person is.
I have not heard anyone from the government take accountability for the healthcare.gov. Why is that?
Things will never improve until someone is willing to step up and say, "Yes, I am accountable".
Ideally, that statement should come well before the rollout ever takes place. Not after (the inevitable) problems occur.
People will respect someone who will confidently proclaim that, when it comes to the campus technology rollout, that "the buck stops here".
Lesson #9. Don't Blame the Vendors:
Perhaps the aspect of the healthcare.gov problems that are bothering me the most is that the government people responsible for the site are blaming the vendors for the problems. This is poor form.
The vendors work for you. You signed the contracts. You managed the partnerships. You are responsible.
Never, ever blame a company for a technology problem if you decided to work with that company. Take responsibility.
Lesson #10. Err on the Side of Transparency:
The last point is that whenever a decision comes up to share information or not, it is almost always better to share. Share information about the project plan. About the vendors. Where possible about the costs.
Share information about the staffing levels. Share information about what could go wrong. Share information about what is going wrong. Share your plan for fixing the problems. Share what you are learning.
We in higher ed should never assume that will know how to do things better than anyone else.
Our main response to the problems with healthcare.gov should be humility and humbleness. This could very easily happen to us.
That we are smarter or more prepared or more passionate or more experienced than the people responsible for healthcare.gov.
We can only guess at the challenges and constraints that that project team face.
What we can do is learn from the healthcare.gov rollout, and commit to do everything that we can not to repeat those mistakes.
What do you think are the lessons for academic tech from healthcare.gov?
