Every POS deployment feels like a custom job, leading to client headaches and squeezed margins, even when your team delivers quality work. Stop the guesswork. We've distilled the complex world of POS deployments into a clear, five-phase playbook that shows VARs stepping into larger projects how to make every project predictable and profitable with a defined scope of work (SOW).
This playbook guides you through a deployment by breaking it into five distinct phases:
Throughout, you’ll hear directly from VARs who run these deployments for a living: Thomas Greenman, President and Co-Owner of Skurla’s POS Solutions; Jeremy Julian, President and CRO at CBS Northstar; and Farrell McKenna, President US for Ravyx. Their perspectives come from different-sized operations, but the failure points they describe, and the fixes they’ve built to catch them, land in remarkably similar places.
Every POS deployment that runs into issues often has a common root cause: someone missed a question during discovery. Usually, it’s not a major failure but rather a small oversight like an unmentioned detail, an unnoticed integration, or an untested network requirement. By the time you realize the problem, you’re already committed, and fixing it directly impacts your profit. Addressing these small gaps early on can save you time, money, and stress down the line.
This phase isn’t just about securing the deal; it’s about ensuring that the deal you land is something you can confidently deliver on time and within budget. When you approach discovery as a mere sales formality rather than a meaningful operational checkpoint, you might be unintentionally setting the entire project up for challenges right from the start – before even drafting the first line of the SOW.
Research on service firms shows that scope creep can impact margins by 10% to 20%, and PMI data indicates that more than half of all projects face some form of scope growth. Specifically, in POS deployments, many integration issues stem from a few common causes: insufficient testing environments, unresolved data sync conflicts, missing rollback procedures, and poor documentation.
None of these issues should be a surprise. The problem is that most sales engineering teams don’t ask the questions that would surface problems until after the contract’s signed, because nobody wants to slow down a deal that’s ready to close.
Greenman points to networking as one of the most common places this appears. Customers routinely want to handle their own network to save money, then expect the VAR to bail them out anyway the moment something breaks. He now has an upfront conversation with the customer to head off issues: “It’s Friday night. Something goes wrong, and it’s clearly a network issue. Are you going to point the finger at us, or are you going to take care of it? If the client isn’t prepared to own that call, the network belongs in the SOW as our responsibility.”
“It’s Friday night. Something goes wrong, and it’s clearly a network issue. Are you going to point the finger at us, or are you going to take care of it?”
Thomas Greenman, President and Co-Owner, Skurla’s POS Solutions
A statement of work built on guesswork isn’t a statement of work. It’s a wish list with a price tag attached. Before your team writes a single deliverable, you need firm answers in four areas:
Understanding the hardware and integrations needed for a deployment is one thing, but ensuring that the specific units ordered will genuinely work in the client’s environment is another. McKenna has seen this go awry in one of the worst ways possible: equipment ordered and delivered for the wrong operating system, incompatible with the site from the start, and no one realized it until it was already sitting in the store.
This kind of mistake usually happens not because someone skipped the discovery step, but because people assumed compatibility rather than verifying it during the ordering process. To prevent this, make a clear compatibility check a non-negotiable part of your procedures. This isn’t just about identifying the needed hardware; it's about asking, “Have we confirmed that this specific model and software version work well with this particular environment?” before shipping.
Greenman reminds us that the person who signs the contract and agrees to what’s included isn’t always the same individual who’s present during installation or involved in later discussions. “Sometimes the sales team works with someone, and they sign the paperwork, but that person isn’t our main contact when we’re on-site,” he explains. This is how even a well-documented agreement can lead to misunderstandings on the ground: the signature is genuine, but the person in front of your technician might never have seen the contract firsthand.
Think of this as its own discovery question rather than an assumption. Verify who approved the scope, and separately, find out who will actually be present and working once the project kicks off. If they are different people, make sure both have reviewed the same documentation before your team arrives. This way, everyone is on the same page from the start.
Discovery only protects you if the answers actually make it into a document the client signs. Greenman’s team splits the SOW into two exhibits: one covering what the customer is paying for in parts and equipment, and a second covering exactly what services will, and explicitly will not, be performed. In his experience, the second exhibit matters most. Spelling out what’s excluded in writing turns a scope disagreement into a calm conversation before the contract’s signed, rather than a tense one on-site.
Not every deal requires the same level of investigation, and pretending otherwise doesn’t help anyone. Greenman explains it clearly: a small shop can’t always dedicate “a hundred hours on a two-register system,” so it becomes a matter of judgment to decide which customers might need that extra attention and which ones don’t.
He’s candid that his read isn’t always correct. Sometimes a job he thought would be straightforward takes more time than he planned, and that’s on him. It’s a natural risk-versus-reward situation, not a flaw in the process, but having a baseline still makes sense: even your quickest, simplest deals should meet the core requirements mentioned earlier. What can vary is how much extra time you’re willing to spend beyond that baseline.
We’ve built out a discovery checklist covering current-state hardware and network, integration points, physical site requirements, business rules, and client-provided requirements, so your team has a repeatable tool to run before any SOW gets drafted. The goal here isn’t to memorize every possible question. It’s to ensure the same rigor applies to every deal, whether it’s a single-location coffee shop or a 40-store rollout.
Free download
POS Deployment Discovery Checklist
It’s tempting to see this process as friction that slows down your sale. But in reality, it’s like the most affordable insurance you could get for your project. Spending just an extra hour walking the site and asking a few key questions is a small price to pay. On the other hand, missing an important integration issue and only discovering it three weeks into the project can cost you the trip and labor, the schedule slip, and often the customer’s confidence. So, by getting your questions answered before signing the contract, you’re solving most of the problems that might otherwise crop up later.
Discovery reveals what the customer needs, while planning and mobilization help transform that into a clear, manageable project. Here, you define who’s responsible for each part, how decisions are made, and the sequence of tasks that need to happen before a single terminal goes live. Skipping or rushing through this crucial phase to meet a tight timeline might seem tempting, but it can lead to delivery challenges, where you’ll find yourself reacting instead of executing your plan smoothly.
A 2023 McKinsey report, mentioned by project management experts Galorath, highlights that organizations with solid governance structures can reduce project failure rates by as much as 30%. Additionally, research rooted in the Standish Group’s well-known Chaos studies repeatedly shows that about 30% of project failures are linked to weak stakeholder engagement.
Neither number is about technology. They’re about who’s in the room, who’s accountable, and whether the right people agreed to the plan before work started. A POS deployment touches point of sale, network, payments, and often kitchen or warehouse operations, so it pulls in people from IT, operations, finance, and sometimes corporate leadership on the client side alone. If you don’t establish ownership before mobilization, you’ll renegotiate authority mid-project, usually at the worst possible moment.
There’s a step that’s easy to skip when a deal’s fresh and everyone wants to move fast: an internal kickoff. Julian’s company runs this as a standing part of the CBS Northstar process. The implementer reads through the order and every CRM note, and sales and implementation talk through whatever doesn’t line up. Sometimes it’s a client who wants the install performed within the week but has no capacity to support it. Sometimes it’s a discontinued component. Julian points to a pattern behind why this friction is so predictable: sales reps tend to be detail-glossing, big-picture personality types, while implementers tend to be detail-obsessed.
That reconciliation matters because it’s cheap to have the discussion internally and expensive to have in front of the client. A gap between what was sold and what’s actually deliverable is far easier to close in a five-minute internal conversation than after a client’s already anchored on a date or a configuration that isn’t realistic.
A second checkpoint belongs right after that internal reconciliation, and it’s client-facing rather than internal. McKenna builds this into his process directly: once the implementation team has reviewed what sales documented, they go back to the client to confirm it, not to reopen the conversation, but to make sure everyone’s actually working from the same understanding. “Does this jibe with what your understanding of the project is?” is the question his team asks before work starts. It catches a different gap than internal kickoff meetings. Sales and implementation can agree perfectly on what the order says and still be wrong if the client understood something different from what was actually sold.
“Does this jibe with what your understanding of the project is?”
Farrell McKenna, President US, Ravyx
Governance doesn’t need to be complicated, but it does need to be explicit. At minimum, you need three tiers on both the VAR side and the client side: an executive sponsor who holds contract and budget authority and only gets pulled in for real escalations, a primary point of contact who owns day-to-day decisions and communication, and a backup contact who can keep things moving when the primary is unavailable.
This is a different problem than the signer gap flagged back in discovery. That was about confirming who will actually be present once work starts. This is about formally assigning who owns each decision once they are.
The single point of contact piece matters more than most VARs give it credit for. Without one, requests and questions scatter across whoever happens to answer the phone, decisions get made twice (or not at all), and nobody can tell you the project's current state. Naming a backup solves the other half of the problem: the project doesn’t stall when your primary contact is out sick, or the client’s champion is on vacation.
A project everyone talked about isn’t a project everyone agreed to. That’s the difference between a master project plan and a hallway conversation. Once the client-facing kickoff is done, the engineer of record takes over and builds what Julian’s team calls a workback schedule: a Gantt chart built backward from the install date. If the install is set for September 15 and today is August 25, the schedule maps every task that has to happen in between and flags resourcing gaps as soon as they show up, not after they’ve already caused a delay.
Your master plan needs three things working together: milestones that mark real, verifiable progress (site survey complete, hardware staged, network cutover, staff training complete, go-live), the dependencies between them (you can’t train staff on a system that isn’t installed, you can’t cut over payments before the merchant account is provisioned), and the resources assigned to each phase, so it’s clear whose calendar a delay actually affects.
Dependencies are where POS projects most often get their timelines wrong. A delayed ISP install pushes back your network cutover, which pushes back terminal configuration, which pushes back training, which pushes back go-live.
Once the plan is running, keep it visible. Weekly status meetings with a shared task list, where every open item has a named owner, do more to protect a timeline than any amount of individual follow-up. When something’s overdue, it stays overdue in front of everyone until it’s resolved. Julian’s team treats an unmet weekly commitment as a direct conversation, not a quiet reschedule: “you didn’t get it done, why didn’t you get it done?” It’s blunt, but it keeps accountability from becoming optional.
Add a second layer where your systems allow it: verify commitments objectively instead of taking a client’s word for it. If your solution is cloud-based, you can easily confirm directly whether a client actually completed a task, like finishing a menu build or running required test transactions, rather than relying on them to tell you. That single shift, from asking to checking, closes off one of the most common sources of late-stage surprises.
Two numbers are worth tracking on every project, not just at the end, but as it’s running. McKenna’s team tracks hours sold against hours actually used, and treats anything within about 10% of the original estimate as healthy. Consistent overages beyond that aren’t one-off exceptions anymore; they’re a signal to look at whether you’re scoping too tight or executing inefficiently. His team calls this a resource utilization rate. The second number is velocity: the time from project start to completion, typically six to twelve weeks for a standard POS install. A project that’s running far outside that range in either direction, barring a genuine external constraint like new construction, is worth a look before it becomes a pattern instead of an outlier.
The kickoff meeting is where governance and the master plan become real to the client. It’s not a status update; it’s the moment you get formal agreement on scope, roles, and schedule from everyone who can slow the project down later if they feel like they weren’t consulted. A kickoff that just walks through a deck leaves too much unsaid; a kickoff built around a charter forces the specific decisions (who signs off on scope changes, what the escalation path actually is, when the site needs to be ready) to get made out loud, in the room, while everyone relevant is present.
We’ve put together a sample project charter and kickoff meeting agenda you can adapt for your own engagements. It’s built to walk the client through governance, milestones, and expectations in a single session, and to leave the room with signatures, not just nods.
Free download
Sample Project Charter and Kickoff Meeting Agenda
Once governance is locked and the schedule is set, the work moves to the warehouse. This is the phase most sales engineering teams underrate, because it happens behind the scenes, away from the client. But staging and configuration is where your margin actually gets protected or destroyed. Every minute you save prepping a unit in a controlled environment is a minute you don’t pay a technician to inefficiently try to work on-site. Think like a factory floor manager here: the goal is a repeatable, inspected, assembly-line process, not a series of one-off setups.
Sidebar
Why staging is where deployment speed actually gets won
The data on this is consistent across the IT hardware world, not just POS. Network hardware vendor Transmode found that pre-staging equipment in a controlled facility reduces on-site time by up to 50% compared to deployments that skip pre-staging. Integration firm LookingPoint reported an even sharper example: moving a switch deployment into their staging center turned two months of sequential on-site work into one week of focused execution.
The logic is simple. On-site labor is your most expensive, least controllable resource. Every problem you catch on a bench, under fluorescent lights, with your full toolkit and internet connection available, is a problem you never pay overtime to solve at 11 pm in a back office. Staging isn’t overhead. It’s where you buy back hours from the most unpredictable part of the project.
Before you kit a single terminal, you need one verified, tested configuration that every unit of the same model gets cloned from. That’s your golden image: the operating system, POS software, security settings, and any site-agnostic configuration baked in and validated once, then deployed identically everywhere. Build it, test it against every integration point from your discovery checklist (payment gateway, KDS, loyalty, inventory sync), and treat it as locked once it passes. If you find yourself hand-configuring the same setting on unit after unit, that setting belongs in the image, not in your technician’s muscle memory.
A golden image also gives you your fastest path to root-causing a problem later. If a terminal misbehaves on-site, the first question is always whether it matches the image. If it does, you’re debugging a site issue. If it doesn’t, you’re debugging a staging process gap, and that’s a fix that protects every future deployment, not just this one.
Kitting means every terminal ships with everything it needs to go live the moment it’s unboxed: the terminal itself, printer, cash drawer, card reader, cabling, power supply, and any site-specific mounting hardware, all packed together and labeled for a specific location. The failure mode kitting prevents is a technician standing in a client’s store, phone in hand, because the customer-facing display got left on a shelf back at the warehouse. That single missing peripheral doesn’t just cost you a trip. It costs you a client’s confidence in the entire crew.
Treat your staging bench like an assembly line, not a workbench. Stations should move in one direction: unboxing and inventory check, imaging, configuration and integration testing, peripheral pairing and kitting, final QA, then packing for shipment. Each station does one job well instead of one technician doing everything for one unit start to finish. That specialization is what lets you scale from five terminals to fifty without your timeline growing. Give each station the tools it needs permanently mounted (imaging stations, label printers, testing rigs) so nothing gets carried back and forth, and keep a clear staging queue so nobody’s guessing what’s next.
Every device that crosses your bench needs an asset tag and a status the moment it arrives: received, imaged, kitted, QA passed, shipped. If you can’t answer “where’s terminal 14 for the downtown location” in under a minute, your tracking system isn’t good enough yet. Asset tags also matter well past go-live. When a unit fails six months into service, a clean asset history (serial number, image version, staging date, QA technician) turns a support call into a five-minute lookup instead of a guessing game.
Menu building is historically one of the most time-consuming parts of configuring a restaurant POS, item by item, price by price, modifier by modifier. It’s also increasingly a place where automation can save real staging time. Tools that pull configuration data from a client’s prior POS system, or scrape an existing web ordering menu to auto-populate the new system, are starting to replace a meaningful chunk of that manual entry. It’s not a replacement for QA (every imported item still needs to be checked against the golden image and tested through the full transaction flow), but it’s a legitimate way to compress the slowest part of configuration without cutting the verification steps that actually protect you at go-live.
The rule that should govern every staging process is unforgiving on purpose: nothing leaves the warehouse unless it would work if a technician plugged it in and walked away. That means every integration tested, every peripheral paired, every credential loaded, every QA checkbox actually checked, not assumed. A device that’s 95% ready isn’t almost done. It’s a support ticket waiting to happen on-site, where it costs ten times more to fix than it would have on the bench.
Everything up to this point--discovery, planning, staging--exists to make this phase boring. A good installation and go-live shouldn’t leave surprises. If your technician arrives on-site and encounters a problem nobody warned them about, that’s not bad luck. It’s a gap somewhere earlier in the process. This phase is about making sure the person standing in the store has everything they need in their hands, and nothing left to guess.
The research backs this up directly. Aberdeen Group’s analysis of repeat service calls found that insufficient or incorrect parts on-site account for 51% of repeat visits, technicians lacking the right training or experience for the job account for 25%, and insufficient time allocated to the job accounts for another 13%. None of those are technician skill problems. They’re preparation problems, and every one of them is preventable with the right checklist and the right handoff from staging.
Why repeat Service calls happen
51%
of repeat visits trace to insufficient or incorrect parts on-site
25%
trace to technicians lacking the right training or experience
13%
trace to too little time allocated to the job
Source: Aberdeen Group analysis of repeat truck rolls
Field service benchmarking also shows the payoff of getting this right: organizations with the strongest first-time fix rates run at a median around 70%, compared to roughly 55% for lower-performing teams. That gap is almost entirely a function of how prepared the technician was before they ever knocked on the door.
Julian’s team learned this lesson at real cost. Once, before they tightened their pre-travel requirements, they shipped around $50,000 in hardware and software to a site, only to arrive and find no doors installed, active construction still underway, and no dust-free environment to work in. Now nothing ships, and nobody travels, until the client sends current photos of the install site and a copy of the Certificate of Occupancy. It’s a cheap check against an expensive mistake, and it belongs in your pre-arrival checklist as a hard gate, not a nice-to-have.
McKenna points to an even sharper version of what’s at stake when scheduling and coordination break down: a retailer clears their entire front-end checkout area, expecting new equipment to go in that day, and the install team isn’t there because of a coordination failure. “That’s a day of lost sales for them,” McKenna says. There’s no equipment mishap or wiring mistake involved, just a mismatch between when the client thought the crew was arriving and when they actually did, and it’s arguably the worst outcome a go-live can produce, since it costs the client real revenue before your team has done anything at all.
Your technician needs three things in hand before they leave for the site, and none of them should live only in someone’s head. First, a site readiness checklist confirming what discovery and planning were supposed to lock down: power and data at each terminal location, network connectivity live and tested, old equipment scheduled for removal, and a confirmed on-site point of contact who’s expecting them. That checklist should also confirm the site photos and Certificate of Occupancy have actually been received and reviewed, not just requested.
Second, an escalation contact list with names and direct numbers, not a general support line, for the VAR technical lead, the client’s primary point of contact, and anyone who can make a fast call if something’s wrong that the technician can’t resolve alone.
Third, clear, written instructions for de-installing old equipment, including what gets removed, what gets left, who owns disposal, and whether any data needs to be wiped or preserved before old hardware leaves the building.
One honest caveat: a checklist only works if the client answers it truthfully. Greenman, Julian, and McKenna all share that retailers under deadline pressure will sometimes overstate how ready a site actually is. Confirmations backed by photos and documentation are harder to fudge than a verbal yes, but no checklist fully closes that gap.
A pre-installation walk-through isn’t a formality. It’s the last chance to catch a mismatch between what discovery documented and what’s actually true on the ground today. Layouts change. A counter gets moved. A new outlet never got installed. Walking the site with the on-site manager before opening a single box confirms the plan still matches reality, and it does something just as important on the relationship side: it puts you and the client’s on-site staff on the same page before work starts, instead of after something’s already gone wrong.
That conversation with the on-site manager matters throughout the day, not just at the start. Retail and restaurant staff are trying to run a business while you’re disrupting their workflow. A technician who checks in at clear points (before starting, before any downtime that affects customers, before final cutover) keeps the client’s team informed and avoids the kind of tension that turns a smooth install into a tense one.
Sidebar
When more than one vendor shows up
Not every install is just your team and the client. Some deployments, especially self-checkout rollouts, involve a hardware manufacturer’s representatives on-site alongside yours. McKenna describes this directly: his team’s self-checkout installs sometimes require a Toshiba representative on-site for portions of the work, arriving separately from his own crew.
That adds a coordination layer the standard pre-installation walk-through doesn’t automatically cover. If your team and a manufacturer’s team aren’t working from the same schedule, and the client isn’t looped in on both, you get the same failure mode as any other scheduling breakdown, except now with two outside parties instead of one showing up out of sync with what the client expected and prepared for. Confirm arrival windows and on-site responsibilities with every party involved, not just your own crew, before the install date is set.
Go-live itself should follow the same order every time: confirm the staged, QA’d unit matches its assigned location, connect and test each peripheral individually before testing the full transaction flow, run a live test transaction through the actual payment processor, confirm data is flowing correctly to inventory, loyalty, and any other integration points, and only then remove the old system from service. Never take the legacy system offline until the new one has proven itself end to end. A go-live that requires falling back to the old system is inconvenient. A go-live where the old system is already gone, and the new one isn’t working is a crisis.
Don’t treat “test the payment processor” as a single generic step. CBS Northstar runs real transactions, actual $1 charges across every card network the client will accept (Visa, Mastercard, Amex), and confirms the funds land in the correct merchant account before calling the terminal live. That level of specificity exists because of past issues: account-routing errors that weren’t caught until real customer money was involved. A sandbox test proves the connection works. A live, tracked transaction proves the money actually goes where it’s supposed to.
A good site-level sign-off document does two things: it confirms, in writing, exactly what was completed and tested at that location, and it gets a signature from someone on the client side with the authority to confirm it. It should list every terminal by location and asset tag, confirm each integration was tested live (not just configured), note any open items with an owner and a date, and capture the on-site manager’s or client point of contact’s signature and the date. Without that document, “the install is done” is just something someone said. With it, you have a defensible record if a dispute comes up later about what was and wasn’t delivered.
Remember, a POS deployment isn’t truly finished until you officially close the project. This step matters because, without it, the project can keep quietly using up your team’s time with no clear end, which can hurt your profits. Taking the time to formally wrap things up can make a big difference for your bottom line and help ensure everything is settled properly.
The most important factor in whether a deployment really succeeds isn’t just what happens during the initial setup or go-live; it’s whether the client’s staff truly feels confident using the new system once your team has finished. McKenna emphasizes that training offers some of the best returns for a retailer following a deployment, and sadly, it’s often the easiest part to overlook. Usually, it’s the last task on a long, busy install day. The technician is exhausted, running behind schedule, and already thinking about the next project. As a result, training might be rushed through, turned into a quick walkthrough, or even skipped altogether with the hope that “they’ll figure it out” on their own.
The cost of that shortcut doesn’t show up immediately. It shows up downstream, when staff who were never properly trained start calling for help with things a real training session would have covered. McKenna is direct about where that lands: “help desk is not prepared to go through training to prepare to respond to triage issues,” so an undertrained client turns your support desk into an unplanned extension of your install team, at exactly the moment hypercare is supposed to be catching real issues, not answering basic how-to questions.
Treat training as its own deliverable with its own time budget, not something squeezed into whatever’s left of the install day. Come with an actual training agenda and a prepared FAQ, not an improvised walkthrough. And leave something behind: videos, documents, and written guides the client’s staff can return to after your technician is gone, so a new hire six months from now isn’t dependent on someone remembering what was said on install day.
Hypercare is the short, deliberately time-boxed window right after go-live where your team provides heightened support: faster response times, closer monitoring, and hands-on availability to catch the issues that only show up once real transactions, real staff, and real customers are running through the system. Industry usage generally puts hypercare somewhere between one and eight weeks, with the actual length driven by defined exit criteria rather than a fixed date: no open critical issues, key workflows running reliably, service levels being met, and the client’s own team able to handle most questions without escalating to you.
CBS Northstar runs a two-week hypercare window with a dedicated implementer as the client’s single point of contact, essentially on call for the duration. Julian is direct about what makes that possible, though: it’s a luxury of scale. Smaller VARs often can’t cleanly separate sales, install, and support into distinct roles the way a larger operation can, so a two-week, fully dedicated hypercare period may not be realistic for every shop. The principle still holds at any size: define how long heightened support lasts and who owns it, even if that person is wearing three hats instead of one.
The first week or two after go-live tends to produce a wave of minor requests, a missing menu item, a tax rate that’s slightly off, a small workflow tweak, and handling each one as a one-off is a fast way to burn hypercare capacity on things that don’t actually block the business from running. CBS Northstar’s fix for this is simple and worth adopting directly: tape a pen and a piece of paper next to each terminal during the early rollout period, and have staff write down issues as they come up during their shift. The implementer collects everything and pushes one consolidated fix, rather than making real-time edits every time a request comes in.
The only exception is anything mission-critical, meaning it actually stops the business from operating. Everything else waits for the batch. Clients are told this upfront, usually framed as living with minor rough edges for about a week before a single clean update lands. Julian’s rule of thumb captures the logic well: “do your changes once, get sign-off once, don’t keep playing whack-a-mole.” It protects your team’s time during the project's highest-demand week and gives the client a predictable rhythm instead of a constant trickle of small changes that never feels finished.
“Do your changes once, get sign-off once, don’t keep playing whack-a-mole.”
Jeremy Julian, President and CRO, CBS Northstar
This is the part sales engineering and delivery teams underestimate most. A project without a formal close doesn’t disappear when nobody’s tracking it anymore; it becomes what’s increasingly called a zombie project: still consuming your team’s time and attention, but no longer generating billable value or moving toward a defined outcome.
A 2026 Atlassian and Censuswide survey of 8,000 office workers found that 44% had already started the year carrying at least one zombie project, and more than 90% of those workers said it was actively causing problems. Separate research on project governance puts the cost of that kind of drift at roughly $97 million in waste for every $1 billion spent, largely because nobody has clear authority (or a clear process) to declare a project done.
CBS Northstar tracks this with a simple internal benchmark: implementation should roughly break even, meaning the implementer’s billed time should match what it actually costs to run that person through the department. When a project’s still eating hours well past its close date, that benchmark is the fastest way to notice, before the drift turns into a real margin problem. It’s the same margin-protection logic as the utilization and velocity numbers from planning, just measured at the finish line instead of mid-project.
A clean closeout has four parts, and skipping any one of them is usually what turns a project into a zombie:
The end of a project is also your best moment to ask for something back. A client who just watched their new POS system go live smoothly, get supported through the rocky first weeks, and hand off cleanly to ongoing support is in the best possible mood to say yes to a reference call, a testimonial, or a case study. Ask at the closeout meeting, while the win is recent, rather than months later when the details have faded, and the ask feels out of nowhere. A well-run closeout doesn’t just protect your margin on this project. It’s free marketing for the next one.
Successful POS deployments usually come down to a few simple ideas. Keep a record of communication (whether that’s an internal kickoff, a recorded meeting, or a signed exhibit) so everyone stays on the same page. Projects often stumble not because of the technology, but because of assumptions: compatibility, readiness, understanding, or accountability.
The good news is, the solution is pretty straightforward across all phases: write things down, confirm them clearly, and assign someone a name and deadline to take ownership. This approach helps ensure everything stays clear, accountable, and moving forward smoothly.
None of this requires a large operation to execute. Greenman, Julian, and McKenna run businesses of different sizes, and each of them independently arrived at some version of the same discipline: checklists that get followed, not just written; handoffs that happen out loud, not by email; and a defined ending to every project, so client care doesn’t quietly turn into unpaid labor.
Julian summed up the underlying habit better than any checklist can: preparation and consistency separate a deployment that goes smoothly from one that doesn’t, and it should take two to three times longer to prepare for a meeting than to run it. That’s true of a kickoff call, a site walk-through, or a closeout meeting. The work you don’t see, done before anyone shows up, is what makes the work everyone does see look effortless.
Use the five phases, adapt the downloadable tools to your own operation, and treat this as a starting framework rather than a fixed script. The goal isn’t to run every deployment exactly the same way. It’s to make sure nothing important is ever left to chance, memory, or good luck.