Three community colleges in a manufacturing corridor are writing a joint workforce proposal. They have been talking for months about aligning their machining and biotech programs to serve regional employers. The partnership is real. Industry advisory boards are engaged. Faculty have visited each other's labs. The program design is strong.

Now they need the evaluation section.

Dr. O, who coordinates the lead institution's workforce programs, has written NSF proposals before.

Names and scenarios in this guide are composites, drawn from presentations, case studies, professional experience, and evaluation research across multiple programs and regions. Any identified programs or individuals that are featured have opted in to share their experience and program information in support of the community. She knows the language of formative and summative evaluation, of logic models and theory of change. She drafts an evaluation plan that emphasizes embedded assessment, participant portfolios, and a participatory model where industry partners co-define success metrics.

Then the state workforce office sends the actual solicitation guidelines. The required metrics are: number of participants enrolled, number of credentials earned, percent placed in employment within 90 days, percent retained at 180 days, and median wage at placement. The evaluation section template has three bullet points and a word limit of 400 words.

Dr. O looks at her two-page participatory evaluation plan and realizes it answers questions the funder is not asking.

Her NSF colleague down the hall, meanwhile, is working on a Technology, Innovation, and Partnerships proposal where the evaluation section gets two full pages and the reviewers explicitly want to see how the program will generate new knowledge about workforce development processes -- not just whether it meets output targets.

Same region. Same industry partners. Same fundamental program. Two completely different evaluation languages.

This is the moment where most teams either dumb down their evaluation to match the simpler funder or overcomplicate it for the funder who wants outputs. Both approaches lose. The teams that win understand that different proposal contexts require different evaluation translations -- and that your underlying evaluation design can serve both if you architect it correctly.

The disconnect between what you know about good evaluation and what different funders require is not a knowledge problem. It is a translation problem.

State and federal workforce programs -- those funded through workforce investment acts, Perkins grants, state economic development offices, and Department of Labor initiatives -- are built around an accountability structure that measures outputs. How many people entered the pipeline? How many earned credentials? How many got jobs? How many kept them? These metrics connect to labor market data, regional economic projections, and legislative mandates. They exist because policymakers need to justify investment at scale, and headcount-to-employment ratios are the simplest way to do that.

These metrics are not wrong. They measure real things that matter. But they measure the endpoints and miss the process. They can tell you that 71 percent of participants got placed. They cannot tell you why those participants succeeded, what the program did that produced that result, or how to improve the 29 percent who did not make it.

NSF and similar research-oriented funders operate differently. Programs like ATE (Advanced Technological Education), the TIP (Technology, Innovation, and Partnerships) directorate, and initiatives that grew from the American COMPETES Act are designed to generate knowledge, not just outcomes. They want to understand how workforce development processes work, not just whether they hit targets. Their evaluation expectations include understanding program mechanisms, documenting participant development trajectories, and producing findings that other programs can learn from.

The problem is that most workforce development teams write evaluation plans for one type of funder and then awkwardly adapt them for others. The result is either a sophisticated evaluation crammed into a three-bullet template or a thin output list stretched across two pages with filler language about "continuous improvement."

Neither approach serves you or your funders well.