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

• 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.

• 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.

Parallel Launch

• 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.

• 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.

Phased Launch

1. All service providers on board at first, but with limited functionality
2. Some service providers on board at first, but with full functionality

• 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.

• 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.

Pilot Launch

• 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.

• 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.

• 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.

Conclusion