Launch Strategies

 So you're ready to launch HIFIS 4 in your community. Congratulations! But there's still one question remaining.  How, exactly, are you going to flip the switch? 

Look at a single individual staff. One day, they're going to be doing things the old way (whether that's entering things into HIFIS 3 or taking notes with pen and paper), and then the next, they'll be expected to start using HIFIS 4. This can be a little intimidating, not to mention confusing for staff. 

That's why it's important to have what's called a changeover strategy. In other words, having a strategy or a plan in place that ensures a smooth changeover or transition from doing things the old way to doing things the new way. 

There are multiple ways that a changeover could work, in practice, but a key component of a good changeover strategy is communication. Everyone involved - and that includes all the administrators, supervisors, and those on the front lines - need to know what to expect and when to expect it. Otherwise, things could get messy. 

There are four main changeover strategies that you have to select from. Which one you pick depends on what your needs are, since they all have some pros and cons. 

Plunge Launch (a.k.a the Big Bang) 


In a plunge launch, you're flipping the switch and never looking back. At 11:59, everybody's doing things the old way, and at 12:00, they're doing things the new way. Everyone switches to HIFIS 4 all at once and discards their old systems. 

 Like ripping off a Band-Aid. 
  • Everyone will be on the same page. Everyone knows that since it's after 12:00, they're supposed to be using HIFIS 4. This is helpful for staff that work part time at multiple agencies, or are involved in multiple programs. They don't have to worry about remembering which programs are on the old system and which are on the new.
  • There are various efficiencies to be had: everyone can be trained at the same time, you can dedicate support resources to only the new system and stop supporting the old one.
  • Users end up getting trained faster (there's more urgency).
  • System-wide benefits can be enjoyed immediately. For example, shelters may be promised that HIFIS 4 will save them time because they won't have to redo intakes for clients first served at other shelters.  If only a few service providers are on board in the beginning, the advantages are lessened.
  • Leadership may be perceived as strong for making such a bold step.
Cons: High risk, high reward.
  • This is the riskiest proposition. It's possible that something can go horribly wrong. For example, the server might become overloaded because it wasn't built to anticipate the volume of use, and it might crash or become laggy. If something does go wrong, it'll affect a large number of users, who could become frustrated and have lowered morale. You might hear things like "at least we knew the old system didn't have this problem."
  • Poor data quality for the time period surrounding the changeover. While in an ideal world, you're training all the staff right before they switch to the new system, it's still going to be new. They will make mistakes and forget how to do certain things they learned in training. As a result, there will be some initial data entry errors, which could impact your reporting and statistics.
To mitigate the potential issues, it's great to do a risk assessment prior to changeover day. Identify all possible risks ("what could go wrong?") and develop a contingency plan for each. Then make sure that the leadership team understands the risks and is still on board. That way, if something does go wrong, leaders are prepared and have contingency plans in place. This goes a long way towards generating buy-in and decreasing panic. You know what they say, hope for the best and prepare for the worst. And hey, why not have a party after the successful launch?

Parallel Launch


Comparatively speaking, a parallel launch seems a lot safer. For a period of time, users start to use HIFIS 4 while continuing to use their old system. This is done until leadership is satisfied that the new system is working the way they want it to.

Pros: Safe.
  • This approach eliminates the risk of something going horribly wrong in the new system. There's a redundancy in place so even if the server crashes or the internet goes down or there's a zombie apocalypse, we have a back-up system we can use.
  • Staff also have time to adjust, getting used to the new system.
  • Theoretically, this should lead to better data quality after the parallel launch period.  You would use data from the old system until you're satisfied that staff are entering things consistently in the right places.
Cons: Slow and cumbersome.
  • Many staff will probably hate the idea of having to double-enter everything, and may not have enough time to do so. Or they might have the time, but tell you they don't because they don't want to.
  • If users feel they don't have the time to enter data into two databases, they may make a choice and only enter data into the database they like better. This could result in half of the staff keeping the old system and the other half using the new system. So instead of getting better data (because there's a database and a redundancy in place), you get worse data (because neither database has complete data).
  • Staff might have the perception that they're not committing to HIFIS 4 yet (perceiving it to be more of a pilot project than an actual changeover) and may allow themselves to formulate negative perceptions of the new system (and share those perceptions with others).
  • You'll need to continue providing support for the old system and the new system during the parallel launch phase, which can require a lot of resources over a prolonged period of time.
  • Could drag on for a long time if stakeholders express a lack of confidence in the new system.
To deal with these issues, try establishing a "drop-dead" date by which the parallel phase is going to be over. Without a drop-dead date, the parallel phase could drag on too long. Also, start championing (and get other leaders to help championing) the benefits of the new system as soon as possible. For example, if you have to report monthly or weekly stats, celebrate how easy it was to pull that period's data out of HIFIS 4. Be clear to staff that this changeover is happening, and the sooner the data quality is good, the sooner they won't have to double-enter things any more. Also, once the changeover period is completed, why not have a party to celebrate?

Phased Launch


Essentially, a phased launch means that you're starting with the new system but not all at once. There are two major ways this could be phased:
  1. All service providers on board at first, but with limited functionality
  2. Some service providers on board at first, but with full functionality
For example, you might decide that you're going to launch HIFIS 4 first with all of your shelters, and only do basic shelter functions (e.g. book ins, book outs). Then a few months later, expand to include housing programs and case management. Or you might decide that because your service area is very large, you're going to start only with service providers within a smaller geographic region of your service area, then gradually add on other regions. Or maybe you have a few agencies that are really excited about using HIFIS 4, so you can start with the most enthusiastic agencies first and then bring on other agencies who are more change-adverse.
Pros: More resources available to focus on smaller details.
  • This also reduces the risks of widespread system failure, much like a parallel approach.
  • Because administrators and trainers are not focused on everything all at once, you're able to dive deep into a specific program area. This feels like personalized attention and makes users feel more confident that their needs are being addressed.
  • Theoretically, this also improves data quality because closer attention can be paid to each user's training needs. Users may only be trained on one part of the software at a time, so the amount they're being asked to learn would be lessened. Or maybe users are being trained on the whole thing, but it's a smaller group of users, so if there are issues, they can be addressed individually.
Cons: Fatigue; long changeover period.
  • This approach can be more onerous for the HIFIS 4 implementation team. They devote all their attention to one aspect, and when that gets implemented, they now have to devote attention to the next aspect, then the next, then the next. They could begin to just want it to be over. If the implementation team becomes fatigued, it could be difficult to keep up excitement for subsequent phases.
  • The users could also become fatigued if they are constantly being trained every month or two on something new, and may become frustrated by the pace at which components are rolled out (too fast or too slow).
  • Your staff may become confused if part of their job falls into two or more phases. For example, maybe they work at a shelter and they also do case management, and basic shelter functions are part of phase 1 but case management is part of case 2. They might think that they aren't part of phase 1 because they're a caseworker and that's phase 2.
  • Staff might also become annoyed if they have to use one data system for part of their work and another data system for a different part, like the previously mentioned shelter/case worker.
  • System-wide benefits won't be realized immediately. For example, if we start by only launching with shelters but then we have to make manual referrals to the Housing First team because they're not on HIFIS 4 yet, that will lessen the benefit of shelters entering in assessment and acuity information into the new system to begin with.
To ensure the best phased implementation possible, try to shorten your phases as much as possible. If you're planning on one phase per quarter, can you make it every two months? Six weeks? One month? Don't let yourself get delayed, necessarily, if one phase is taking longer than expected. Consider skipping that phase if possible or launching two phases very close to each other. Finally, be sure to be specific about the timing of your phases and especially your overall project completion date. That helps to reduce questions from staff and clarify expectations.  Then, when you're fully launched, have a party (and you could send me an invitation)!

Pilot Launch

This can be a variant on any of the above strategies. Start small, with just a small group of people using the new system, then expanding to include the remaining users. This could look like:
  • Plunge pilot: have one supportive housing provider start using HIFIS 4 and work out some of the kinks before inviting the other supportive housing providers on board.
  • Parallel pilot: get some users to start entering their rent bank issuances in HIFIS 4 while also recording it in the old system, and then checking to see if the numbers match before training all users on the new system.
  • Phased pilot: get some users to start using the new case management module and provide you with feedback before you implement case management system-wide.
Pros: Imperfect action > perfect planning. Gets this ship moving quickly.
  • Allows you to start using HIFIS 4 without having spent months and months planning every detail. Pilot users know they're essentially testers, so you have the freedom to try something and develop policy as it comes up instead of trying to plan in advance for every eventuality. You have the opportunity to refine and troubleshoot as you go.
  • Problems are only known to a small group of users, which helps keep enthusiasm up for everyone else.
Cons: Building the plane while flying it.
  • If your pilot launch wasn't as thoroughly planned or vetted, you could make decisions that you regret. Maybe you started recording a client's emergency contacts into the Contacts module, then realized that you now have a privacy issue on your hands. Certain things in HIFIS can't be undone.
  • Other cons are similar to the phased and parallel approaches: system-wide benefits won't come until later; the pilot phase can drag on for a long time; and the implementation team could get fatigued.
  • There could be the perception that the leadership team is unwilling to commit to a change, which may express a lack of confidence in the new system.
  • There may be negative feelings (such as resentment) within the community about why a particular group was selected to be the pilot group.
To address these issues when doing a pilot, use some of the strategies suggested above. Communication is key - in this case, communicating why pilot testing is important within your community. Again, communicating timelines for how long the pilot will be, when other groups will be coming on board, and when the whole project will be complete are also important.  And I suppose you could have a party after your pilot project, too.


 There are multiple different ways you can think about your launch plan, and there really is no correct answer. Each option offers various positives and negatives. However, there are a few common best practices. You need to have a strategy that includes solid timelines and a communication plan. If you check those boxes, then you'll be prepared to deal with whatever issues arise. 
Converting Data to HIFIS 4: What You Should Know
Waterloo's Privacy and Consent Training Video


There are no comments yet. Be the first one to leave a comment!