Why Competence Isn’t Optional in Project Teams
- Sarah Verity
- Jan 22
- 5 min read
Why Capability Matters in a Team: When “Good on Paper” Isn’t Good Enough. Transparency, Cadence, Accountability: The Cure for ‘Good on Paper’ Syndrome.
Through my consulting and delivery experience, I’ve seen firsthand how delivery success hinges not just on frameworks and plans — but on the actual capability of the people doing the work.
Most of us remember the group assignments handed out at university. Even if you didn’t go to uni, you’ve likely experienced the familiar tension of being assigned to a team — a mix of people you may not know well, or worse, people you do know and already suspect may not be up to the task.
Project teams can feel exactly the same. A group of individuals brought together from across the business, selected for their (perceived or proven) experience and capability, and tasked with delivering outcomes within a defined timeframe.
But what happens when, only a few weeks into the project, you realise that one of the key people you rely on simply isn’t delivering? How do you address it constructively without jeopardising team balance, stakeholder confidence, or project momentum?
This reflection explores one such experience — and the lessons it reinforced about capability, transparency, and the real cost of inaction.
When Capability Gaps Surface
In this case, the team member in question was a Key Project Resource — a pivotal role in any project team, and one a Project Manager depends on heavily to facilitate workshops, analyse information, and produce core artefacts.
Most PMs (myself included) can and often do wear multiple hats. While it’s possible to step into analysis or change roles when needed, it’s far from ideal. The DNA of a PM is delivery — structured, time‑bound, outcome‑driven — and that mindset can conflict with the exploratory, analytical nature of those disciplines.
In projects, having dedicated project resources is a privilege. Budgets are tight, teams are lean, and every role needs to count. When you do have resources, you want to know they’re capable and able to meet the needs of the project.
I’ve worked with exceptional individuals across disciplines — SMEs, business analysts, change managers, comms and L&D leads, tech leads, data architects, solution architects and more. Many have become trusted partners I’ve brought into future engagements by choice.
But what happens when your key project resource just doesn’t have the capability to deliver?
The Early Warning Signs
I realised something was wrong around Week 3.
There’s always a grace period for new starters — time to read the business case, understand the context, review action plans, learn the stakeholder landscape, and begin forming a view of current and future state.
But by Week 3, nothing was moving. By Week 4, stakeholders were flagging incomplete work — including a BRD with no context, no purpose, and a list of NFRs copied from another project. By Week 5, there were still no tangible outputs. No drafts. No working notes. No evidence of synthesis.
Key artefacts were now blocking other leads from planning their work. Stakeholder groups were still not identified. And the key project resource continued to insist they were “reading and synthesising,” yet nothing could be shared.
It felt like being back in a uni group assignment where someone wasn’t pulling their weight — except this time the stakes were real.
Taking Action: Creating Transparency and Accountability
Because the team was small and newly formed, I introduced structure and cadence early:
twice‑weekly stand‑ups
an internal showcase using MS Teams Planner (Kanban style)
visible, accessible work‑in‑progress
real‑time feedback and a view to help install a collaborative uplift
This created transparency, accountability, and a shared understanding of progress — or lack thereof.
By Week 3, my instincts were telling me the Key Project Resource wasn’t walking the talk. By Week 4, stakeholders validated the same concerns. By Week 5, it was clear the individual was not suited to the environment — a lean project team, shifting organisational structures, and a transformation strategy requiring conceptual thinking and stakeholder engagement.
To be clear: I didn’t hire this key project resource. Someone experienced did — and they were equally surprised when the capability gaps emerged.
When “Good on Paper” Isn’t Good Enough
You might assume that with clear evidence of non‑delivery, a project resource (and if a contractor) would recognise the mismatch and work through a plan to handover and /or exit gracefully. Not so.
Instead of reflecting on the feedback, the key project resource blamed the transparency, the stand‑ups, and the showcase process — claiming the visibility made them feel poorly, rather than acknowledging the competency gaps that were now undeniable. This is where capability gaps shift from a performance issue to a behavioural one. And behavioural issues, left unaddressed, become delivery risks and reputational issues both to the project practice and the people supporting it.
So What? Why Capability Matters — and What to Do When It’s Missing
Capability isn’t a “nice to have” in project delivery. It’s the foundation that ensures:
momentum is maintained
dependencies can progress
stakeholders stay engaged
risks are managed early
delivery remains credible
A team member who is only “good on paper” can quietly derail timelines, block others, and erode trust long before the issue becomes visible.
When capability gaps emerge, leaders must act early:
create transparency through cadence and visible work
validate concerns with stakeholders
provide clear, constructive feedback
offer opportunities to uplift — but set boundaries
escalate or replace when delivery is at risk
Because at the end of the day, capability and competence aren’t optional. They are the difference between a project that moves forward and one that stalls. And when someone can’t deliver what the project needs, the cost of inaction is far greater than the discomfort of addressing the issue.
Reflection: How This Experience Shapes My Professional Practice
Through my experience and consulting, I’ve seen how capability gaps — when left unaddressed — can quietly erode delivery confidence, stakeholder trust, and team cohesion. This particular engagement didn’t just reinforce that truth; it made it personal.
It reminded me to trust my instincts as an experienced delivery leader. When something feels off, it usually is. Early signals matter, and delaying action rarely serves the project, the team, or the individual involved.
It also strengthened my commitment to transparency. Visible work, clear cadence, and open communication aren’t just delivery tools — they are protective mechanisms that surface issues early and create shared accountability.
Most importantly, it sharpened my understanding of the difference between capability gaps and integrity gaps.
Capability can be coached. Behaviour can be developed. But when someone chooses avoidance over accountability, or deflection over dialogue, the risk profile changes entirely.
I carry this lesson forward into every engagement:
I set expectations early.
I create visibility from day one.
I intervene sooner rather than later.
I balance empathy with boundaries.
I protect the team and the delivery environment.
And when I encounter someone who is “good on paper” but not in practice, I now recognise the signs (a little more) faster — and act with greater clarity and confidence.
This experience didn’t just shape how I lead projects. It shapes how I lead people. And it continues to inform my practice, reminding me that strong delivery is built on capability, integrity, and the courage to address gaps before they become risks.
----------------------------------------------------------------------------------------------------------------------------------
If you’re considering project management or business advisory support for your next idea, delivery or transformation, feel free to reach out and Say Hello!
Two In The Hand Consulting — business and technology advisory services
Comments