I've watched three separate companies try to roll out Last Planner System software. One of them made it stick. The other two bought licenses, ran a lunch-and-learn, and quietly went back to the printed bar chart taped to the trailer wall within a quarter. The difference wasn't the software. All three tools were fine. The difference was the handful of people put in charge of making it real on the jobsite — and whether the company actually gave them the room to do it.
If you're standing up a look-ahead and weekly work planning tool across your organization, the team you build to drive it matters more than the platform you pick. Here's how to assemble one that survives contact with a live jobsite.
Start with the honest reason it fails
Last Planner isn't a software feature. It's a discipline: your last planners — the foremen and superintendents who actually commit crews to work — make reliable, made-ready promises in a weekly work plan, and you measure how many of those promises land with Percent Plan Complete. The software is just the place that discipline lives so everyone can see it.
Rollouts die when nobody owns that distinction. The tool gets installed, a few schedules get built, and then the first busy week hits. Someone skips the Monday plan because they're chasing a concrete pour, PPC stops getting tracked because nobody's job it is, and within a month the whole thing is a dead login. Your implementation team exists to prevent exactly that drift. So build it around the two things that actually break: field credibility and sustained attention.
The roles you actually need
Forget org charts with eight boxes. On a real rollout, a few roles carry the weight. Everyone else is support.
Executive sponsor — the one who protects the calendar
You need one senior person, ideally someone the field respects rather than just an office title, who will do three concrete things: fund it, defend the time it takes, and show up. Not "champion the vision." Show up. When the sponsor drops into a weekly planning session and asks a foreman what his PPC was and why two commitments slipped, the whole company learns this is real. When the sponsor never appears, the field correctly reads it as another office initiative that'll blow over. The single most common cause of a stalled rollout is a sponsor whose attention wandered off to the next fire in month two.
Implementation lead — the person whose actual job this is
This is the make-or-break hire, and the most common mistake is naming someone who's already at 100% capacity and telling them to do it "on top of your regular duties." That's how you guarantee failure. The lead needs real, protected hours — at minimum a day or two a week on a serious rollout — to build templates, run the training cadence, sit in on sessions, and chase down the reasons commitments are missing. A good lead is part project manager, part coach, part nag. They track adoption weekly and they know which superintendents are quietly not using it before it becomes a pattern.
Project champions — field-credible or don't bother
Here's the rule I'd tattoo on the wall: your on-site champion has to have swung a hammer or run a crew. A brilliant coordinator from the office who's never had to make a real crew commitment will get politely ignored by foremen. It doesn't matter how well they know the software. Pick the superintendent or lead foreman who's respected on that job, and make them the one who runs the weekly plan and coaches the subs through their first few sessions. Credibility transfers; software knowledge you can teach in an afternoon.
Champions are also your early-warning system. They're the ones who'll tell you the truth — that the sequencing view is confusing to the drywall foreman, or that nobody's entering their commitments until Tuesday. Listen to them harder than you listen to the vendor.
A methodology coach and a tech point person
On a bigger org, split these; on a small one, the same person wears both hats. The methodology side owns the "why": what a good weekly work plan commitment looks like, how to run a pull-planning session, how to make work ready, how to actually use PPC and variance reasons to improve instead of to punish. The tech side owns setup — building the schedule templates, wiring up trade-flow sequences so the tool enforces your real construction logic, getting crew leaders onto the mobile app, and fixing the login problems that will otherwise become someone's excuse to quit. Both matter. A team that's all methodology builds beautiful plans nobody can operate; a team that's all tech configures a gorgeous system full of garbage commitments.
Size it to the org, then cut it down
Rough guidance, and I mean rough:
- Small shop (a handful of active jobs): two or three people, mostly part-time. Often it's one committed lead, one field champion per active project, and a sponsor who checks in.
- Mid-size: four to six, a mix of a dedicated lead and part-time champions on each project.
- Large / multi-region: a small dedicated core team plus a champion embedded on every project running the system.
Whatever number you land on, err smaller and more committed over larger and diffuse. A team of three people who actually have the hours beats a team of nine who all treat it as a side quest. Diffuse ownership is how a rollout ends up owned by nobody.
Pick people for credibility and time, not enthusiasm
The volunteer who's most excited in the kickoff meeting is not automatically your best champion. What you want on the team:
- Field credibility — peers listen when this person talks about how work actually sequences.
- Genuine available time — protected and real, not "I'll find some." If you can't free up the hours, you're not ready to start.
- The ability to persuade a skeptical foreman — because half this job is winning over people who've seen initiatives come and go.
- Enough patience to sit in bad early sessions without declaring the tool broken.
Notice what's not on that list: being a software power user. That's the most teachable thing on the team.
Train the methodology before the buttons
The training mistake I see constantly is starting with a screen tour. Two hours of clicking through menus, everyone nods, nobody changes their behavior. Flip it. Train the discipline first — what a reliable commitment is, why you only pull work into the weekly plan once it's genuinely made ready, how to run the six-week look-ahead so constraints surface early enough to clear them. Then, and only then, show how the tool holds all of that. When people understand the "why," the software stops being extra data entry and starts being the obvious place to do the work they now believe in.
Keep the software training short, hands-on, and role-specific. A crew leader needs to know how to open the mobile app and see this week's plan for their location — that's it, don't drown them in the scheduling features they'll never touch. The superintendent building the plan needs the full picture. Match the training to the job.
Run the rollout on its own look-ahead
This one's a little tongue-in-cheek, but I mean it: manage the implementation using the same short-interval discipline you're trying to install. Put the rollout activities on a rolling look-ahead. Make the team's own commitments visible. Track a "PPC" on your rollout tasks. It builds the muscle, it proves you actually believe in the method, and it keeps the team honest about slippage instead of letting the whole effort drift.
Practically, that means a short weekly coordination touch — fifteen minutes, what's committed, what slipped, why — plus a deeper monthly look at adoption and PPC trends across projects. Don't over-meet. The team should spend far more time on jobsites than in a conference room.
Bring in outside help, but don't outsource the ownership
A good Last Planner consultant or a solid vendor onboarding team can save you months of learning the hard way, especially on your first project. Use them. But keep the ownership internal. The failure mode here is letting a consultant run your first rollout so well that all the knowledge walks out the door with them when the engagement ends. Pair every outside expert with an internal person whose explicit job is to absorb what they know. External help builds your first success; internal capability makes the second, third, and tenth project routine.
Measure the right things, and don't confuse them
Track two categories separately. Adoption tells you whether people are using the system — logins, whether weekly plans are actually being built, whether crew leaders open the mobile app. Effectiveness tells you whether the discipline is working — PPC trending up over time, variance reasons that show you're catching constraints earlier, fewer surprise crew standdowns.
Watch out for the trap of high adoption with garbage output: everyone logging in, plans full of vague or unready commitments, PPC that never moves. That means people are checking a box, not changing how they plan. It's a coaching problem, and it's exactly what your field champions and methodology coach exist to catch. Conversely, don't punish an honest early PPC of 50%. That's a team telling you the truth about how unreliable the old way really was — which is the whole point of measuring it.
Plan for the boring part: continuity
Rollouts that succeed for two years and then collapse usually collapse because the one person who held it all together got promoted, transferred, or burned out. Guard against it. Document your standard templates and session cadence so they don't live only in one person's head. Have a backup for every key role. Rotate fresh champions in as projects wrap. And watch for burnout on your lead — sustained rollout energy is genuinely tiring, and a fried, cynical lead poisons the whole effort faster than any technical problem.
The bottom line
The software for look-ahead and weekly work planning — LookAheadWall included — is the easy part of this. It'll do what it's supposed to. What determines whether short-interval scheduling actually takes root in your company is a small team of credible field people, given real time, backed by a sponsor who shows up, coaching the discipline before the clicks and measuring whether it's working. Get that team right and the tool almost implements itself. Get it wrong and the best software on the market ends up as another dead login. Build the team like the outcome depends on it, because it does.