The pre-project skills check nobody runs

A project plan rarely slips because of the task everyone flagged as hard. It slips because of the task nobody flagged at all – the one that looked routine on the Gantt chart, because somebody, somewhere, assumed the person assigned to it already knew how to do the specific thing it required. A pivot table that needed refreshing against a new data source. A scheduling dependency in Project that needed re-linking after a milestone moved. A report that needed a query rewritten, not just re-run. These gaps can go unrecorded in a RAID log because nobody has questioned whether the assigned person can complete the specific task.

We see this pattern constantly: running hands-on Excel, Power BI and SQL training for project teams, almost always after the fact, in a debrief rather than a planning session. The task owner wasn't incompetent. They'd done the task before, just not this version of it – a lookup across two systems instead of one, a dashboard that now needed to refresh automatically, rather than be rebuilt by hand each week. They assumed they'd figure it out as they went because that's usually true of familiar tools. It stopped being true the day the task quietly needed a skill they didn't have, and the gap wasn't visible to anyone until the milestone was already missed.

A standard project kick-off checks capacity (does this person have the time?), and ownership (is this person accountable for this deliverable?). It rarely checks capability at the level of the actual tool interaction the task requires, because that level of detail feels like micromanagement to ask about directly. 'Can you handle the reporting for this phase?' nearly always gets a yes, not because the answer is dishonest, but because the person answering is picturing the parts of the job they're confident about, not the one specific function they've never needed before.
 
A risk register built from team self-assessment has the same blind spot from the other direction: people flag the things they know are hard but may miss a tool-specific skills gap until they attempt the task. The result is a plan that looks fully resourced on a RAG-status view, and still slips on a task that, taken in isolation, would have taken fifteen minutes for someone who'd simply seen the specific technique before.

The fix doesn't need a formal competency framework, or a training needs analysis that takes longer than the project itself. It needs a short, task-specific check, run once, early, against the actual deliverables in the plan, rather than against generic role titles.
 
Pull the handful of tasks on the plan that depend on a specific tool, technique, rather than general familiarity – not "use Excel," but "build a pivot table that refreshes against a live data connection," not "update the schedule," but "re-sequence a dependency chain without breaking the critical path." For each one, ask the assigned owner to walk through, in two or three sentences, exactly how they'd do it – not whether they're comfortable with the tool in general, but the specific, mechanical steps for this specific task. The answer provides an initial indication of where support may be required. If someone only describes the intended outcome, ask a follow-up question about the steps involved before drawing conclusions about their skills.
Add a quick demonstration using a sample file for tasks that could delay a milestone. Ask the owner to complete the crucial step and check the result. This will make the conversation more concrete and help to distinguish between a missing skill, unclear instructions, missing access, and a problem with the data.
The part that matters most is how the answer gets used. This isn't a performance review, and treating it like one is exactly what makes a skills check something people route around, rather than answer honestly next time. A gap identified this way isn't a mark against the person – it's a scheduling input, no different from finding out someone's on leave during a critical week. Fold it into the plan the same way: either a short, specific brief on the one technique needed (often faster than it sounds, because the gap is usually narrow, rather than general), a pairing with someone who has done this specific thing before, or a reassignment if the timeline doesn't allow for either. All three are cheaper than discovering the gap at the point the deliverable is due.

The right moment to run this is right after task assignment, and before the plan is baselined, when a reassignment or a half-day of targeted help still costs nothing to the schedule. Run it later, and the same conversation becomes a crisis conversation, happening the week the deliverable is overdue, with far fewer good options left on the table.
 
None of this requires new software or a formal assessment process. It requires treating 'Can this specific person do this specific thing?' as a planning question worth fifteen minutes per task, asked early enough that the answer is still useful. The tasks that sink a schedule are rarely the ones anyone was watching.