Why it matters: a new hotel gets one opening weekend, and our system sits behind every check-in, key card and charge. If it stumbles that weekend, it's the hotel's first bad review and the end of a reference account for us. The opening itself belongs to the hotel. Everything below is what we own to make sure our part doesn't hold it up.
Our system is ready for the Nov 16 soft opening, so we never become the reason the hotel's schedule moves.
Our PMS talks correctly to the hotel's door locks, POS, OTAs, payments and accounting before the first guest arrives.
Everyone the hotel hires can do their real daily tasks in our system, not just log in, however late they start.
Night audit closes on time in our system and revenue posts to the right accounts, so the hotel's finance team isn't cleaning up the opening month.
Our support team takes the account on Jan 15 with nothing on fire, every decision written down, and the project inside the hours sold.
Amber: Nov 16 is holding, with recovery actions in place on two hotel-side risks. The two things that could move it are hotel-side dependencies: door lock installs and late hiring.
The build is essentially done: the property is 97% configured, all 1,236 pre-opening reservations are reconciled, and payments and OTA channels are certified. What's left depends on the hotel's schedule. We can't certify the door lock interface until their contractor installs locks, and the hotel has filled 26 of 61 front-line roles (43%), which squeezes our training window to two weeks. On our side I've booked an engineering slot for the lock interface, pulled super-user training forward, and built a compressed training track. Both risks have a fallback that keeps Nov 16, so I'm not recommending any change to the go-live date.
Implementation philosophy: Execute · Assess · Improve · Repeat. Discovery at kickoff with the GM, owner's rep and director of finance set both the technical guardrails (interfaces, data, access) and the business outcomes we measure after launch.
Next decision point: go/no-go call with the GM, Nov 12.
180 rooms and 18 launch rate plans. 7 interfaces: door locks, POS (restaurant and rooftop bar), channel manager, payments, accounting export, housekeeping app, guest messaging. Staff single sign-on with the hotel's identity provider (SAML login, SCIM provisioning by role). This is staff access, not a guest-facing interface, so it isn't counted in the 7. Pre-opening reservation load. Training for about 70 staff: 61 front-line roles plus 9 managers and department heads. On-site support through grand opening.
Mobile check-in. The other 16 rate plans. Anything new after the Oct 2 config freeze goes through the change log.
Blocked: 18 scripts (12 door lock, 6 POS) waiting on hardware installs. +66 passed since last week.
What I'm watching this week and why.
Config freeze Oct 2. All 1,236 pre-opening reservations reconciled against central reservations after fixing a duplicate-import bug.
Payments, the channel manager, the housekeeping app and guest messaging are certified. POS and the accounting export are in testing. Door locks can't be certified until the hotel's contractor installs them on floor 2, so we're bench testing with the vendor's encoder on Oct 5 and holding an engineering slot the week of Oct 12.
Payments: webhook certification and automated reconciliation. POS / access control: API sandbox testing, payload validation, failover. Staff SSO: SAML with SCIM role-based provisioning across admin tiers.
Two tracks. Managers get admin setup, reporting, and how to handle exceptions. Front-line staff get role guides, one-page cheat sheets, and a super-user on every shift. The hotel has filled 26 of 61 roles, so I moved super-user training up to Sep 30 and built a compressed track for late hires.
Track A · Admin & executive steering: policy governance, audit reporting, exception workflows. Track B · Front-line enablement: role guides, quick-reference templates, train-the-trainer champions.
What the hotel doesn't see: our hours, our people, our engineering tickets, and the contract milestones go-live triggers.
What the 480 hours covers: implementation specialist and solutions engineer time from kickoff through the Jan 15 handoff. Training days and the on-site support engineer are billed separately under the training and hypercare packages.
How earned value is measured: each work package's budgeted hours × its % complete, rolled up every Monday.
Why SPI is under 1 while the date holds: most of the unearned work is UAT and lock certification waiting on hotel installs. Critical path float decides the date, not SPI.
Forecast: about 55 h over. Drivers are extra solutions engineer time on the lock bench test and re-cert, and me running smaller rolling cohorts for late hires. TCPI of 1.08 means we'd need to run 8% leaner than plan during the busiest weeks, which isn't realistic.
Options: (1) change request for 55 h, needs owner's rep approval by Oct 23. (2) cut on-site coverage from 14 nights to 10, saving about 48 h. Option 2 means we can't verify the 14-of-14 night audit goal in person, so I'm recommending option 1.
I'm the hotel's single point of contact for our company, and I coordinate the third-party vendors that connect to our PMS. The hotel owns its opening, hiring and construction.
C = current, D = desired.
| Stakeholder | Unaware | Resistant | Neutral | Supportive | Leading | Gap note |
|---|
One accountable person per decision, so nobody finds out on Nov 12 that two people thought it was theirs.
R = does the work · A = makes the call · C = consulted · I = informed
| Decision | GM | Owner's rep | Director of rooms | Implementation specialist (me) | Account management |
|---|
| Milestone | Owner | Baseline date | Forecast date | Variance (days) | Predecessor | Status |
|---|
Agreed with the GM and director of rooms at kickoff (Jul 7). Half are gates for go-live, half prove it worked once guests arrive.
| Criterion | Target | Now | Measured at | Status |
|---|
Weekly snapshot every Monday. Dashed line is the target for go/no-go. After launch these hand over to adoption metrics: in-platform transaction rate, first-time user error rate (< 1.5%), 30-day CSAT/NPS and hypercare resolution speed.
The hotel owns hiring. I track it because it decides how many people we can train and when. Mitigation: asynchronous learning packs for new hires and rolling super-user cohorts, so every user is ready before launch regardless of start date.
Score = likelihood × impact (1 to 3 each). Tagged by who owns the cause: us, the hotel, or a third-party vendor. Even when the cause is theirs, the mitigation listed is what I do about it. Reviewed at the Thursday steering call.
Strategies use PMBOK terms. Threats: Avoid, Mitigate, Transfer, Accept, Escalate. Opportunities: Exploit, Enhance, Share, Accept.
| ID | Cause → Risk → Effect | L × I = Score | Cause owner | Response owner | Strategy | Trigger | Contingency | Secondary risk | Residual score | Status |
|---|
So the support team inherits the reasons, not just the settings.
5 / 12 criteria met
Must-pass met: 5 of 9
| Criterion | Type | Waiver authority | Due |
|---|
If door locks aren't certified by Nov 12, the fallback is go-live with manual key encoding at the front desk and a vendor tech on site, not a delayed opening. That call belongs to the GM.