PHA SOP Development

Every public housing authority (PHA) has standard operating procedures (SOPs) somewhere. Some are followed daily. Some haven't been opened since the day they were delivered. Most fall in between: bookmarked once, technically available, quietly going stale.

SOPs tend to reflect the conditions that created them: tight timelines, borrowed templates, writers who understood the regulation but not the workflow. They land complete, get filed, and quietly drift from how the work actually gets done.

If your agency is going to invest in SOPs, the result should be worth keeping. Procedures clear enough for a new hire to follow on day one. Documentation that outlasts the staff who wrote it.

Is This You?

You may need SOP work if:

Your policy documents have procedure language buried in them, but it's vague, passive, and no one can find it
Staff turnover has left institutional knowledge in the heads of people who already left
New leadership wants operations documented and standardized
Your RFP for SOP development has grown to include workflow assessments, gap analyses, process maps, and automation recommendations, and you're not sure which you actually need
A corrective action plan includes SOP deliverables

Start with What You Already Have

Most PHAs already have procedures. They just don't know it.

Model policy documents contain procedure language woven into the policy text: steps for processing applications, conducting inspections, calculating rent. Staff reference these documents regularly. But the procedure sections are thin, written in passive voice, light on examples, and indistinguishable from the policy around them.

The most practical path is often to improve those procedures where they already live. Identify the procedure content, mark it clearly as procedure, and strengthen it: specific steps, better examples, cross-references where one process depends on another. A 500-page document may become 700 pages. No one reads it cover to cover. It's a reference, and better reference material means fewer errors. A single reference means it won't get lost.

For some agencies, procedures should live outside the policy document entirely. Policy updates follow the annual PHA Plan cycle. Procedures need to move faster: when a workflow changes, when software updates, when a new PIH Notice changes how something gets processed. Separating the two means your team can update a procedure without waiting for a board vote. The tradeoff is that standalone procedure documents need their own home and their own maintenance cycle. Make that decision before anyone starts writing.

Sometimes procedures need to be built from scratch: new programs, operational areas the models don't cover, or processes specific to your agency's structure and systems.

Getting the Scope Right

RFPs for SOP work routinely bundle workflow assessments, gap analyses, process maps, and automation recommendations under a single heading. These are different workstreams with different costs. Bundling them inflates scope, timeline, and price.

Standard operating procedure (SOP). Step-by-step documentation of how your agency performs a specific function. Written for the person doing the work. This is the core deliverable most PHAs need.
Workflow assessment. An examination of how work actually moves through a process: who does what, in what order, where it stalls. A narrower form of operational assessment. It tells you what to fix before you document anything.
Gap analysis. A comparison of current practice against regs or internal policy. Identifies where the agency is exposed. Produces findings, not procedures. Often part of an operational assessment or policy review.
Process map. A visual diagram of a workflow. Looks great in a deliverables binder. Doesn't get opened again. Unless your agency is an ISO 9001 candidate, skip it.

When an RFP bundles these under one heading, proposals vary wildly. Our approach: draw clear boundaries. What we deliver, what falls outside the written scope, and what could be added later. Our default format is narrative SOPs: clear, operational, written for the person at the desk. The format matters less than whether anyone uses it.

How We Scope

A mid-size PHA could document hundreds of procedures across every program area. No one will maintain them. We start with the 20 to 25 that matter most: the ones that drive compliance, that new staff need on day one, that break when someone quits. Intake. Eligibility. Recertifications. Interim actions. Inspections. Rent calculations. Move processing. The work that keeps the lights on.

Broader coverage can follow. But starting with everything is how SOP projects fail. Starting with what matters is how they last.

How We Work

The people who process the files, enter the data, and handle the calls know things management doesn't. SOPs written from a conference room don't match what happens at the desk. That's where the work starts.

A question most engagements skip: how will these documents be maintained after the contractor leaves? Who owns them? Where do they live? Does your team have the tools and formatting skills to keep them current? We address this before anyone starts writing, not after.

What You Get

Narrative SOPs in editable format. Organized by program area. Clear enough for day one.

The engagement may also include:

Any format you need. Outline, playscript, flowchart, Q&A, checklists, hybrids, bespoke. Format follows function.
A procedure inventory. What your agency has, what's missing, and what's buried in policy documents but not usable as written.
Staff training on new procedures. An SOP no one has been walked through is an SOP no one follows.
A maintenance framework. Who updates what, when, and how. Not a service contract. A plan your agency can execute internally.

Why ProjectLogic

We're a boutique firm. The person who interviews your staff is the same person who writes your procedures. No handoffs. No junior staff learning on your project.

We work exclusively with PHAs. No one here needs you to explain what an interim reexam is or how portability works. The programs, the regs, the software your team fights with every day: that's the world we work in.

Output is a binder. Outcome is a team that can follow the procedure without calling someone. That's what we're after.

SOP Development