Every skills initiative starts with the same question: what skills actually matter here? Not the generic list from an HRIS vendor. The specific, measurable capabilities that define what good looks like in your organization, and what separates "meeting expectations" from "ready for the next level."
The answer lives in a competency framework. The definition, the four build methods, and a worked example are in Competency Framework: How to Build One. This article is the other half: the project plan for the person who has to run it.
Because the framework itself is the easy part. The real work is political, not technical. You are making explicit what was previously assumed, and assumptions, once surfaced, start arguments. A 30-day plan gives those arguments a place to happen, a deadline, and a way to end.
How Long Does It Take to Build a Competency Framework?
A first competency framework for one job family of five to eight roles takes about 30 days from kickoff to first assessment results, and roughly 60 hours of people's time spread across a sponsor, a framework owner, four to six subject-matter experts, and the managers of the pilot group. Week one fixes scope and the people; week two drafts the competencies and the proficiency scale with the people who do the work; week three calibrates the drafts in workshops and settles the disagreements; week four sets required levels per role, runs the first assessments, and ships the framework to the pilot group. Organizations that try to cover every role at once take six to nine months and usually stall a third of the way through. Organizations that pilot one job family finish in a month and repeat the cycle for the next family in three weeks.
The rest of this article is that month, week by week, with a data center operations job family as the running example: facilities technicians, shift leads, and a site operations manager across two sites.
Before Day One: Decide These Five Things
The 30 days start when these are written down, not when the kickoff meeting is booked.
- Purpose. Assessment and development, compliance evidence, promotion criteria, or hiring. One primary purpose; it sets the level of detail and decides who has to agree.
- Pilot job family. One family, five to eight roles, where the need is loudest. For the data center, operations: certification currency is an audit item and shift leads are promoted on instinct.
- Sponsor. A named executive who will sit in the week-three calibration session. If nobody senior will give you 90 minutes in week three, you do not have a sponsor.
- Framework owner. One person who runs the project and holds the pen. Usually L&D or talent. Not a committee.
- Where it will live. A spreadsheet is fine for the pilot. Decide now what it moves into afterward.
Who Does What
The framework is written by the people who know the work and owned by the person who maintains it. This table is the whole governance model for a pilot.
| Activity | Sponsor | Framework owner | Subject-matter experts | Managers of the pilot group | L&D / talent |
|---|---|---|---|---|---|
| Set purpose and scope | Accountable | Responsible | Consulted | Consulted | Informed |
| Draft competencies and anchors | Informed | Accountable | Responsible | Consulted | Consulted |
| Choose the proficiency scale | Informed | Responsible | Consulted | Consulted | Accountable |
| Calibration workshops | Attends week 3 | Facilitates | Responsible | Responsible | Consulted |
| Set required level per role | Accountable | Responsible | Consulted | Responsible | Informed |
| Run first assessments | Informed | Accountable | Informed | Responsible | Responsible |
| Own the framework after day 30 | Informed | Accountable | Consulted | Consulted | Responsible |
Two things to notice. Experts draft; L&D facilitates and formats. And managers own calibration and assessment, because a framework they didn't help calibrate is one they will quietly ignore.
Week 1: Scope, Sponsor, and the Pilot Roles
Time budget: about 8 hours, half of it the framework owner's.
Confirm the five decisions in writing, one page, circulated to everyone in the table. Then inventory the roles in the pilot family. Not titles, roles. The data center has eleven titles across two sites that collapse into three roles: facilities technician (two levels), shift lead, and site operations manager. Titles are cheap to create; roles are what the framework hangs off.
Recruit four to six experts: two top performers, one manager, and one person who consumes the work, here the site operations manager who lives with a bad shift handover. Ask each for four hours over two weeks, and book the week-three workshops now, because that is the meeting that slips.
Close the week by agreeing the proficiency scale: four or five levels, one scale for the whole framework, labels people will say out loud. The data center chose four: Foundational, Working, Advanced, Expert. How to anchor a scale is covered in proficiency levels; week one only decides which scale, so week two's drafts all use it.
Week 2: Draft With the People Who Do the Work
Time budget: about 20 hours, mostly subject-matter experts in two-hour blocks.
The framework owner runs three two-hour sessions with the experts. The first answers one question per role: what does someone in this role need to be great at, not just good? Write down everything, then cut to eight to twelve competencies for the family: three to five every role shares, three to seven that vary by role. Twelve is the ceiling. Past it the framework becomes an assessment burden managers avoid.
The data center group landed on five shared competencies: critical systems operation, method-of-procedure execution, incident response, compliance and evidence, and people leadership, plus vendor coordination for shift leads and capacity planning for the site manager.
The second and third sessions write the anchors: one observable sentence per competency per level. "Understands incident response" is not an anchor. "Recognizes alarm conditions and escalates within the defined thresholds without prompting" is. Each expert drafts the competencies closest to their own work, then swaps. The rule for writing a competency definition applies to every anchor: a verb, an object, an observable standard, no evaluative adjectives.
By Friday there is a draft grid: competencies down the side, four levels across, an anchor in every cell. It will be wrong in places. That is what week three is for.
Week 3: Calibrate, Argue, Settle
Time budget: about 18 hours, including the sponsor's 90 minutes.
Calibration means walking every competency and level past the managers who will apply it and asking two questions: do you agree with how this level is defined, and can you name someone on your team who is at it? If two managers can't agree on what Working looks like for incident response, the anchor is rewritten in the room. If neither can name anyone at Expert, the level describes a job that doesn't exist here and gets pulled down.
Run two 90-minute sessions with managers and experts together, then a third with the sponsor present. The third is not a review. It is where the sponsor settles what the first two couldn't. There will be three disagreements, and they are political, not technical.
The argument about who is already Expert
Someone senior is about to assess at Advanced in a competency they believed they owned, and their manager will push to soften the anchor. Keep the anchor and reframe the result: the framework describes the role's bar, not the person's worth, and a gap at the top of a role is a development target, not a verdict. If the sponsor won't hold that line in week three, the framework will be bent to fit people for the rest of its life.
The argument about whose language wins
Two sites describe the same competency differently and each is certain theirs is correct. Ask which version an auditor or a new hire would understand without a translator, use that one, and record the other as an alias. One competency; two vocabulary entries.
The argument about scope creep
Halfway through calibration someone will point out that the maintenance team has almost the same competencies and should be included. They may be right. Write it down as the second pilot and refuse to change the first. The plan works because the scope is fixed; the moment it flexes, the deadline goes with it.
End the week with the sponsor saying, in front of the managers, that this grid is the definition of good for these roles until the next revision.
Week 4: Required Levels, First Assessments, Rollout
Time budget: about 14 hours, mostly managers assessing.
Monday, set the required level per role in each competency. Facilities technicians need Advanced in critical systems operation and Foundational in people leadership; the site manager needs the reverse. This is where the framework becomes useful: required minus actual is a gap, and a gap is a thing you can close.
Tuesday and Wednesday, run the first assessments. Dual assessment works best: each person rates themselves against the anchors and their manager rates them independently, fifteen minutes each way. The distance between the two ratings is data in its own right; it shows where anchors are unclear and where a conversation is overdue. Which methods produce trustworthy data is covered in skills assessment methods and tools.
Thursday, review the results with managers before anyone else sees them. Look for three things: self-ratings a full level above manager ratings, which means an ambiguous anchor; required levels nobody in the role meets, which means the bar or the anchor is wrong; and gaps clustered in one site, which means a training need, not a framework problem. Fix the anchors that need fixing. Don't touch the ones that just produced uncomfortable answers.
Friday, roll out. Each person sees their assessed levels, the required levels for their role, the gaps, and the anchors for the next level. Managers get the team view; the sponsor gets the aggregate. Nobody gets a PDF. The framework goes into a system that keeps anchors, assessments, and gaps together, so the competency framework and the proficiency assessment results are never in two places.
The Template
The pilot runs perfectly well in a spreadsheet. Ours has four tabs: a competency worksheet with a column per level for anchors, a scale tab, a role expectations matrix, and a calibration checklist with the questions for each workshop. It is the structure large enterprises use, cut down to a one-family pilot. Download the template and week one's paperwork is done in an afternoon.
What to Measure at Day 30, 60, and 90
Three checkpoints tell you whether the pilot worked.
Day 30. The framework is signed off, every person in the pilot group has a completed dual assessment, and every manager has reviewed their team's gaps. Missing any of the three, the pilot is not done, whatever the calendar says.
Day 60. Each person has at least one development action tied to a specific gap, and the anchors have been revised at least once from assessment results. A framework unchanged after 60 days wasn't examined.
Day 90. One question for the sponsor: has a decision been made because of this framework that would otherwise have gone differently? A promotion, a training purchase, a staffing choice, an audit response. Yes means the framework is infrastructure and the second job family starts. No means it is a document, and the next pilot fixes the reason first.
The Month Is the Method
Most framework projects fail the same way: everything at once, generic language, no calibration, no connection to anything. The 30-day plan makes each failure structurally difficult. One job family forces scope. Experts writing anchors forces specific language. Week three forces calibration. Week four forces the connection to assessment. The framework that comes out is smaller than the one most organizations set out to build, and it is the one they use.