Twelve to eighteen months is the standard timeline for a full MEDITECH Expanse upgrade, and most hospitals burn their first ninety days just deciding who works on it. That’s the part nobody budgets for. You’ve signed the contract, the kickoff deck looks great, and then someone in the steering meeting asks the obvious question: who’s actually doing the build? If your answer is “we’ll figure it out,” you’ve just added a quarter to your timeline before a single analyst touches a dictionary.
I’ve sat in enough of those kickoff rooms to know the pattern. Every hospital needs the same four roles staffed, in the same rough order, and every hospital tries to fill them with the same three people. Fixing that mismatch is the difference between a go-live you’re proud of and a hypercare period that lasts until the next fiscal year. MEDITECH Expanse implementation support from an outside team can fill the gap, but only after you know which gap you actually have.
Who actually does the work on a MEDITECH Expanse project?
Strip away the org chart and an Expanse upgrade is four jobs. One of them has to be in-house, and it’s not the one most CIOs protect first.
| Role | Owns | Typical capacity
|
| Project manager | Timeline, risk log, vendor escalation | 1 person, full time |
| Application analyst | Build, dictionaries, workflow testing | 4 to 12 people, by module |
| Clinical informaticist | Translating bedside reality into build specs | 1 to 3 people, part time |
| Training and ATE lead | Curriculum, credentialed trainers, at-the-elbow coverage | 1 lead, then a rotating bench |
The analyst bench is the one that breaks budgets. Expanse touches inpatient, ambulatory, revenue cycle, reporting, and every interface in between, and each module needs someone who understands how that department actually works. Borrow three nurses and call them analysts and you’ll be rewriting their builds in month seven, on overtime, with the go-live date already printed on the badges.
One more thing worth saying out loud: your best clinical analyst is probably the person who complains the most. They know where the current system fails because they’ve been documenting workarounds in a notebook for two years. That notebook is your requirements document. I’d rather have that person in a build role than a dozen analysts who’ve never charted a note under pressure.
Which roles to hire, borrow, or outsource
After the build phase, you need a much smaller group to keep Expanse running, and your staffing plan should shrink on purpose. Here’s the split that holds up in practice.
- Keep the project manager in-house. Someone on payroll needs to own the schedule when the vendor’s account manager rotates off your account.
- Rent the specialty analysts. Radiant, revenue cycle, and reporting builds are seasonal work. You need deep expertise for four months, not a permanent headcount.
- Keep one strong clinical informaticist. This person keeps build decisions tied to how care actually gets delivered, and they outlast every outside contract.
- Rent the training bench, then convert two or three of them. When outside trainers leave, in-house superusers carry the knowledge forward.
That third bullet is the one leadership argues about most. My read: clinical informatics is the capacity center for the whole project, and cutting it to save a salary line is the false economy that shows up as slower adoption and louder hypercare tickets. Keep that role funded before you fund anything else.
The hidden cost sitting in your travel budget
Staffing models look cheap on a spreadsheet until you add travel. A consultant flying in Sunday night and out Thursday afternoon burns four nights of lodging, two travel days, and a rental car to deliver three working days. Multiply that by six analysts across a nine-month build and the number gets uncomfortable fast. This isn’t a niche observation, either. According to research from Harvard Business Review, heavy travel is one of the most common reasons skilled professionals leave a job, and the strain lands hardest on the people whose institutional knowledge you can least afford to lose.
That’s why I favor blended coverage over plane tickets. Put a remote consultant on build and dictionary work, where everything happens in the system. Fly someone in only when the work genuinely requires a room full of people: workflow validation, dress rehearsals, go-live command center. You’ll cut travel spend by half and your clinical leads will stop dreading Thursday afternoons.
The same logic applies to your own staff. Pulling a nurse analyst out of a department for six months is a real cost, and it usually lands on their coworkers as extra shifts. Handle that openly with the unit manager before the project starts, not after the schedule falls apart.
How to pick a staffing partner without getting burned
Ask three questions, listen for dodges, and you’ll sort the field quickly.
- Which of your consultants have worked in a customized MEDITECH environment, not a vanilla one? Nearly every hospital runs custom dictionaries and nonstandard workflows. Generalists fall apart there.
- What happens to my project when one of your people gets reassigned? A partner without bench depth will answer in vague terms. A good one names their backup coverage.
- Who owns knowledge transfer, and when does it start? If the answer is “at the end of the engagement,” you’re renting expertise you’ll have to rent again next year.
One risk deserves its own flag: key person dependency. When a single outside consultant holds the only working knowledge of your lab interface, you’re one resignation email away from a stalled project. Name your internal counterpart for every outsourced role and schedule shadow sessions on the calendar like any other milestone. For ongoing projects, pairing outside capacity with your own staff is a plain business continuity move, not a luxury.
Don’t interview staffing firms the way you interview software vendors. Software companies sell features. Staffing partners sell people, so ask about the people.
A simple staffing plan you can defend
The approach I keep coming back to is a capacity floor, which just means this: before any phase starts, you name the minimum internal headcount and the maximum outside headcount, and you write both numbers into the project charter. The floor doesn’t move when a department manager protests a vacancy, and the ceiling doesn’t move when a consultant conveniently becomes available at a discount.
Here’s how it plays out on a real-style timeline. During design, you need one project manager, three internal analysts, and two outside specialists covering your most customized modules. During build, the analyst bench grows and your informaticist’s hours double. During validation, outside headcount drops and internal testers take over the workflows they’ll live in. Through go-live and hypercare, the outside team shrinks to a command center presence like the one HPG runs for health systems, while your credentialed trainers hold the floor. Every phase has a number before it has a calendar.
Managers who plan the human side this way tend to retain their clinical analysts, because the work stops feeling like a second job layered on top of a first one. That outcome is worth more than any tooling decision on the project.
Hiring for a skills gap is normal management, not a failure. Checking your headcount assumptions early, before the kickoff deck is even finalized, is the cheapest risk mitigation available on the whole upgrade. Pull up your project charter this week and count the names assigned to design, build, validation, and go-live. If any phase has fewer people than the one before it, you’ve found your first real project issue, and it’s cheaper to fix now than in hypercare.
