Most proposals treat a client's competency framework as a formality to map against. Four moves that treat it as the design brief it already is.
Nearly every organisation that buys leadership development already has a competency framework. Someone spent nine months and a considerable amount of money producing it. It went through committees. It is on the intranet, and in most cases it is on the performance review form.
And almost no proposal uses its language.
That is a strange thing to be true, because the framework is not an administrative obstacle sitting between you and the design work. It is the only document in which the organisation has already written down, argued about, and formally agreed what it wants its people to be able to do. Read properly, it does a substantial share of your analysis before you start.
The first is bringing your own model. Slide four of the proposal is a framework with your logo on it, mapped loosely onto the client's world. It looks like intellectual property and it reads like expertise, but it has quietly asked the organisation to operate two vocabularies at once. It will run one of them, and it will not be yours.
The second is subtler and far more common: the mapping table. A two-column appendix with their competency on the left and your module on the right. It satisfies a procurement reviewer. It survives a steering committee. And nobody reading it can tell what any manager will do differently on Monday morning.
The mapping table fails because it maps topics, and a framework is not a list of topics. It is a written agreement about what good looks like — and, more usefully, about what separates good from not-yet-good. That separation is the design brief. A mapping table discards it and keeps the labels.
A framework's headline competencies are nouns. Drives Accountability. Builds Inclusive Teams. Strategic Thinking. You cannot design against a noun. There is no observable behaviour in it, no practice activity that follows from it, and no way to tell whether it happened.
Underneath each heading, though, there are behavioural indicators, and that is where the verbs live. Design against the indicators rather than the headings, and quote them word for word rather than paraphrasing them into your own house language. The paraphrase feels like professionalism; it is actually where alignment leaks away. Objectives written in the organisation's own approved wording arrive pre-negotiated.
Most frameworks are levelled — emerging, proficient, advanced, or a numbered scale. The client rarely wants everyone better at everything. They want a specific population crossing one specific boundary, and they usually know which one.
So ask. Then put the two adjacent level descriptors side by side and look for the words that differ. The difference is usually three or four words long, and those words are the closest thing to a pre-approved learning objective anyone will ever hand you. Somebody had to defend that exact phrasing in a committee; whatever survived is what the business genuinely believes the step up consists of.
Before you design tightly into a framework, establish whether it carries any weight. Three questions answer it:
Is it on the performance review form? Is it used in promotion decisions? Could a manager name one competency without looking it up?
If all three answers are no, the framework is decoration. Designing hard into it buys you nothing, and the honest move is to say so — gently, and early. If any one answer is yes, it is load-bearing, and every word you decline to take from it costs you adoption you would otherwise have had for free.
Every framework has holes. Say which ones, in the proposal, before anyone else finds them.
Something like: your framework has nothing on decision-making under ambiguity; two of the five behaviours we are targeting sit outside it; here is how we will describe them, and here is what we would suggest you consider at your next framework review.
That paragraph does something no mapping table can. It treats the client's framework as a live system you are contributing to, rather than an obstacle you routed around. In practice it also tends to be the moment the conversation changes, because very few suppliers volunteer where the client's own instrument is thin.
Take a competency called Develops Others. At proficient level it might read: provides regular feedback and supports team members' growth. At the next level up: creates the conditions in which team members seek out development and act on it without prompting.
The difference is four words — seek out, without prompting. Which means the programme is not, in fact, about giving better feedback. It is about a manager building the conditions in which someone asks. Different modules, different practice, a different measure — and every word of that objective came out of the client's own document.
A programme that sits beside the organisation's existing system gets treated as an event. One that sits inside it gets treated as infrastructure. The framework is the cheapest available route from the first to the second, and reading it properly costs an hour that you were going to spend writing objectives anyway.