← All posts

IT & Data for Mission-Driven Teams

Project-management habits that keep technology from becoming the problem: scope, ownership, access, backups, software selection, change control, clean data and government tech compliance.

This guide collects a ToyBox series in one place. Each section is also shared, one at a time, on ToyBox's social channels.

1. Tech projects fail at scope, not at code.
2. Who owns this spreadsheet? Meet the RACI chart.
3. The offboarding checklist nobody writes until it's too late.
4. Synced is not backed up. The 3-2-1 rule.
5. Choose software with a requirements list, not a demo.
6. "Can it also just…" Scope creep and the change request.
7. Clean the data before you move it.
8. Government tech compliance: accessibility, privacy and records.

1. Tech projects fail at scope, not at code.

Most technology projects don't fail because the software is bad. They fail because nobody agreed on what the project was.

ToyBox founder Katoya Palmer holds the CompTIA Project+ certification. The pattern she sees is consistent. A new database, a website, a CRM. Everyone has a different picture of what it will do. Halfway through, the picture changes. The budget doesn't.

Scope is the fix. Before anyone buys anything, write down what's in, what's out, who makes the final call, and what "done" looks like. One page is enough. If it's not on the page, it's a change, and changes get decided, not absorbed.

It feels slow at the start. It's the fastest way to finish.

Technology is not a luxury. It's governance, and scope is where governance starts.

Try this: What's a tech project at your organization that never quite finished?

2. Who owns this spreadsheet? Meet the RACI chart.

Every organization has a spreadsheet nobody owns and everybody edits.

A RACI chart fixes that with four letters. Responsible: the person who does the work. Accountable: the one person who makes the final call and answers for it. Consulted: people whose input you need before deciding. Informed: people who need to know after.

The rule that matters most: only one person is accountable for each item. Two accountable people means nobody is.

Use it for your systems as well as your projects. Who is accountable for the donor database? The shared drive? The website? The password manager? If the answer is "kind of everyone," the answer is no one, and the first time something breaks, you'll find out.

A system without an owner is a liability with a login.

Try this: Which system at your organization has no clear owner?

3. The offboarding checklist nobody writes until it's too late.

When someone leaves an organization, their access should leave with them. In a lot of small organizations, it doesn't.

Former staff still in the shared drive. A volunteer still holding the only admin login to the website. A vendor portal tied to a personal email nobody can reach. None of it is malicious. All of it is risk.

A short offboarding checklist covers most of it. Transfer admin rights before the last day, not after. Turn off email and file access, and forward what needs forwarding. Change shared passwords, and move them into a password manager if they aren't already. Check vendor and funder portals. Get devices back and wiped.

Then do the same checklist in reverse for onboarding, so new people get exactly the access they need and nothing they don't.

Access isn't a perk. It's a responsibility, and it ends on the last day.

Try this: When was the last time your organization checked who still has access?

4. Synced is not backed up. The 3-2-1 rule.

If a file gets deleted in a synced folder, the deletion syncs too. That's why synced is not the same as backed up.

The 3-2-1 rule is the simplest standard to remember. Keep three copies of your important data. Store them on two different kinds of storage. Keep one copy off-site, or in a separate cloud account, so one fire, theft or ransomware attack can't take everything.

Then the step almost everyone skips: test a restore. Pick a file, pretend it's gone, and get it back. A backup you've never restored is a hope, not a plan.

Start with what would hurt most to lose: the financial records, the grant files, the donor or client database, and anything a funder or auditor could ask for later.

Prevention isn't theory. It's infrastructure.

Try this: When did your organization last restore a file from backup on purpose?

5. Choose software with a requirements list, not a demo.

Software demos are designed to impress. They show the best features on perfect data. Then you buy it, and your real Tuesday looks nothing like the demo.

Write your requirements before you watch anything. List what the system must do, what would be nice, and what it absolutely can't do. Bring in the people who will use it every day, not just the people who sign the contract.

Then ask the questions vendors don't volunteer. "How do we get our data out if we leave?" "What does it cost in year two and year three?" "Who do we call when it breaks, and how fast do they answer?" "Does it meet the accessibility and security standards our funders require?"

Score each option against your list, not against the demo.

The best software is the one your team will actually use.

Try this: What's a tool your organization bought that nobody uses?

6. "Can it also just…" Scope creep and the change request.

"Can it also just…" are the four most expensive words in a technology project.

Scope creep is how a three-month project becomes a nine-month project without anyone deciding it should. Each request is small and reasonable. Together, they move the deadline and drain the budget.

A change request process doesn't mean saying no. It means deciding on purpose. Write the change down. Estimate what it costs in time and money. Have the accountable person approve or decline it. Then update the plan, so everyone is working from the same version.

Some changes are worth it. The point is that someone chose them.

Speed without structure doesn't equal progress. It just moves the problem.

Try this: What's the biggest "can it also just" your organization has said yes to?

7. Clean the data before you move it.

A new system won't fix messy data. It will import the mess faithfully and then make it harder to find.

Before any migration, whether a new CRM, accounting system or database, clean first. Find the duplicates, like the same donor entered three ways. Decide which fields actually matter, and stop carrying the ones nobody uses. Standardize formats for names, dates, addresses and phone numbers. Archive old records you're required to keep but don't need in the new system.

Then do a test migration with a small slice of the data, check it with the people who use it, and fix the rules before moving everything.

It's tedious. It's also the difference between a new system people trust and a new system people work around.

Bad data migrates perfectly.

Try this: What's the messiest data your organization would have to clean before a move?

8. Government tech compliance: accessibility, privacy and records.

When an organization takes public money, the technology comes with rules too. Three show up most.

Accessibility. Two federal rules adopted in 2024 set WCAG 2.1 Level AA as the standard: the DOJ ADA Title II rule for state and local governments, and the HHS Section 504 rule for HHS-funded organizations with 15 or more employees. Compliance dates are now April 26, 2027 for governments serving 50,000 or more people, April 26, 2028 for smaller governments, and May 11, 2027 for covered HHS recipients. That covers websites, online forms and the documents you post. Don't wait for the date. Accessible is better for everyone now.

Privacy. Federal award rules expect organizations to take reasonable steps to protect personal information they collect. Think client records, case notes and anything with a Social Security number.

Records. Award agreements usually require keeping records for a set number of years, and public agencies have public records laws on top of that. If you can't find it, you can't prove it.

Your agreement and your funder's guidance decide what applies to you. Read them, then build the habits.

Standards don't erase community culture. They protect it.

Try this: Has a funder ever asked about your website's accessibility?

General information, not legal, tax or accounting advice. Your award agreements and your funders' rules come first.

---

Sources

• DOJ ADA Title II web accessibility rule (2024)
• DOJ extension of compliance dates (April 2026)
• HHS Section 504 extension of compliance dates (May 2026)

Get ToyBox's lessons in your inbox. Out the Box arrives once a month with practical lessons from ToyBox's work, recognitions and a note from Katoya. Subscribe to Out the Box →