11 minutes

Writing impact on people into the charter

A six-field section you can add to any project charter, the five moments to reopen it, and how to keep it honest when the answer is “we do not know yet.”

What you’ll be able to do

Write an impact-on-people section into a project charter that names who is affected, whose expertise is missing, the burden the design creates and the trade-offs accepted, and set the points in the project where the section will be reopened.
Compare the responses to this question and explain your choice: Where does adding the section do the most good?
Draft a project charter section on impact on people for your work, including who this affects, and who is most affected, whose expertise is missing, burden this design creates, and who carries it.

Why the charter, and not a separate form

Most organizations already have somewhere equity and accessibility questions could live: a review form, a checklist held by another office, a note in a plan. The reason to put them in the project charter instead is not that the charter is better written. It is that the charter is the document the project actually uses. A sponsor signs it. A project manager reads it at status meetings. A contracting colleague refers to it when drafting a solicitation. A new team member reads it in their first week. A question that lives in the charter gets asked. A question that lives in a separate form tends to be completed once and filed.

The section below is short on purpose: six fields, no specialist vocabulary, each answerable in a few sentences. It is not an assessment of anyone, and it produces no rating. What it produces is a record. This is who we believed the work affects. This is what we did not know and who we asked. This is the burden we accepted and who carries it. This is who decided. That record is what makes later questions answerable, including the hardest one: if this design harmed or excluded someone, what would accountability and repair require?

A project charter section on impact on people

Six fields you can copy into a project charter, scoping document or change request. It fits on one page and is meant to be reopened at five points across a project.

Who this affects, and who is most affected Name the groups of people the program or service touches, specifically enough that a reader can picture them and check later whether the design worked for them. Go beyond “applicants” or “Minnesotans”: people applying for the first time, people renewing, people who live far from a county office, people who read English as a second or third language, people who use a screen reader or magnification, people who rely on a family member or supporter to complete a step, people without reliable internet at home. Mark the groups most likely to be harmed if the design is wrong. Describe groups, never individuals, and record no one's private information.

Whose expertise is missing List the knowledge the project does not have: people who use the service, families and supporters, interpreters, disability-led organizations, culturally specific organizations, and division staff who take the first call or send the first letter. For each, record the arrangement you are offering — co-design, advisory review, targeted consultation or testing a draft — what is still open to change, how access will be arranged in advance, and how people will be paid. Community contributors are co-designers and advisors, not learners.

Burden this design creates, and who carries it Walk the process as a person would and write down every task it assigns: documents to find, calls to make, time to take off, trips to arrange, explanations to repeat, signatures to obtain, deadlines counted from a printed date. For each task, note who it is heaviest for and what happens to someone who cannot complete it. Flag anything the process asks for that the division already holds.

Access, language and format decisions Record decisions, not intentions: which channels exist and which is the default; which formats are produced and when; how a person tells the division what they need to take part; how interpretation and translation are arranged and paid for; which accessibility requirements are written into the requirements and acceptance criteria rather than left to a final check; and which of these are already fixed by a system or contract the project does not control.

Trade-offs accepted, and who decided Write down what the project chose not to do and why: a path deferred, a review shortened, a format postponed, a pilot narrowed. For each, name who is left out or delayed, what they will be offered in the meantime, who made the decision, and the date it will be reviewed. A trade-off with no name and no date tends to be rediscovered later as a complaint.

How we will know, and what we will tell people Name the few things you will look at to learn whether the design worked for the groups in the first field — not only completion and volume, but who stopped and where. Say when you will look and who will look. Say what you will tell the people who contributed: what changed because of them, what did not and why. Include how someone raises a problem with the service and what happens when they do.

Copy the six fields into the charter of one project you are working on now. Complete what you can in one sitting, mark each unknown with the person you will ask and a date, and reopen the section at requirements, before the contract, before the pilot, before launch and once after.

Browse and download only. Staff notes are not typed or saved on this page.

Five moments to reopen the section, and what to ask each time

When requirements are written

Does every requirement that assigns a task to a person appear in the burden field? Which requirements exist only because the process has always asked for them? Are the access, language and format decisions written as requirements with acceptance criteria?

Before a solicitation posts or a contract is signed

Which access and language commitments are named deliverables with a test attached? What could the division refuse to accept, and on what grounds? Contracts and procurement staff are the natural owners of this check.

Before a pilot

Does the pilot include the groups the design is most likely to fail, or only the places where it is easiest to run? How will pilot participants tell the team something is wrong, and in what languages and formats?

Before launch

What did testing with people who will use the service show? What is still unresolved, and is it recorded as a trade-off with a name and a date? What will the people who raised an issue hear back?

Once after launch, at the agreed point

What happened to the groups named in the first field? What did each accepted trade-off actually cost, and who paid it? If the design harmed or excluded people, what would accountability and repair require, and who owns that work?

When the honest answer is “we do not know yet”

What you can change

You control whether an unknown is written down with a question, a name and a date, or left blank, or covered with a general phrase.

What to watch for

Do not fill a field with a sweeping statement so it looks complete. “All Minnesotans” in the first field tells the next reader nothing and hides the people the design is most likely to fail.

Your next step

Wherever you do not know, write the question, the person or organization you will ask, and the date you expect an answer. Then put that date in the project schedule alongside the other dependencies.

What this section is not

Not a rating of a project, a team or a person.
Not an approval step. The offices that approve a charter, a solicitation or a launch still make those decisions.
Not a substitute for a required accessibility review or a language-access obligation.
Not a place for anyone's private information or a description of an individual's disability.
Not finished when it is first written. Its value comes from the few minutes spent reopening it.

Which entry in the “who this affects” field is most useful to the next person who reads the charter?

“All Minnesotans who use division services.”

“People renewing this service each year, including people who do not read English comfortably, people who use a screen reader, people who rely on a supporter to complete forms, and people without reliable internet at home. The last two groups are most likely to be harmed by an online-only default.”

“Applicants and their authorized representatives.”

“Anyone with a disability, as required by law.”

Try a situation

A senior leader sponsors four division projects. Their charters use a standard template: scope, milestones, budget, risks and dependencies. One project is writing requirements. One is drafting a solicitation. One is in build. One launched last quarter and has drawn complaints that nobody can trace to a specific decision. The leader asks whether an impact-on-people section is worth adding, and where.

Where does adding the section do the most good?

Add it to new charters only, so projects already underway are not disrupted.

Add it to all four, sized to where each one is: the full section for the projects writing requirements and drafting the solicitation, and a shorter version for the project in build and the launched project that records who has been affected, what burden the design created and what repair would take.

Add it to the launched project first, since that is where the complaints are.

Carry this forward

A charter is where a project's questions become official. A question that is not in the charter is one somebody has to argue for later, usually when the schedule is tight.
Six short fields carry most of the value: who is affected, whose expertise is missing, burden and who carries it, access and language decisions, trade-offs and who decided, and how we will know.
The section earns its place by being reopened at a few moments — requirements, contract, pilot, launch and once after — for a few minutes each time.
“We do not know yet” is a sound entry when it names who will be asked and by when. A field filled with a general phrase to look complete is not.
The loop closes when the people who contributed hear what changed because of them, what did not and why.

A scenario about a sponsor with four projects at different stages, a charter section completed for one real project, an accordion of five reopening points, and a knowledge check on what makes an entry usable.

Copy the six fields into the charter of one project you are working on now. Complete what you can in one sitting, mark each unknown with a name and a date, and take the section to the next project meeting.

Your next step

Which project will you bring the charter section to first?

Name the project and the decision point it is approaching

Complete the first two fields — who this affects and whose expertise is missing — before the next project meeting

Put the five reopening moments into the project schedule next to the milestones they belong with

Browse and download only. Course notes are not typed or saved on this page.

Mark this lesson complete

Participation and course completion in this program do not count toward DHS-required training credits unless management, a director, or DHS leadership expressly approves an exception.