Writing a Portal RFP

Director of Digital Renée Okafor joins host Amara Obiledu to talk through the member-portal RFP NANA issued this month: why the current system can't support single sign-on across all six chapters, what NANA is asking vendors to solve, and why the selection process is deliberately slow.

• Renée Okafor — Director of Digital, NANA. Owns the member-portal project from RFP through launch.

• 00:00 Intro

• 01:25 Why the current portal can't keep up

• 07:00 What the RFP actually asks for

• 13:10 Single sign-on across six chapters

• 18:30 The unified resource library requirement

• 23:40 Why NANA hasn't picked a vendor yet

• 28:15 What the evaluation process looks like

• 31:40 Chapter directories and why software matters here

• 34:20 How chapter chairs shaped the RFP

• 36:30 Budget pressure on the project

• 37:40 Outro

Host: Renée, NANA just put out an RFP for a new member portal. Start with the problem. What's wrong with the one we have?

Renée Okafor: The current system was built for a NANA with one national membership and loosely connected chapters. It does that fine. What it doesn't do is give a member a single login that works whether they're looking at national benefits, their chapter's roster, or the resource library — right now those are three separate logins, sometimes three separate password resets, and every chapter has its own patchwork of spreadsheets and shared drives filling the gaps the core system doesn't cover.

Host: So this is fundamentally a single sign-on problem?

Renée Okafor: It's the anchor requirement, yes, but it's not the only one. The RFP asks for four things together: single sign-on across national and all six chapters, a unified resource library so a member isn't hunting across three portals for a document, event registration built into the same login, and chapter directories that are actually current, not a PDF someone updates twice a year.

Host: Walk me through single sign-on specifically. Why is that harder than it sounds?

Renée Okafor: Because the six chapters aren't identical systems today — some run on spreadsheets, some have a lightweight local tool, Great Lakes has something closer to a real database. Whatever platform we pick has to either absorb all of that or integrate cleanly with what a chapter already depends on, without forcing a chapter that's happy with its own tool to rebuild from scratch on our timeline. That's the part of the RFP I expect to generate the most vendor questions.

Host: What does the unified resource library requirement solve that the current system doesn't?

Renée Okafor: Right now, a research brief, a course, and a chapter's own meeting notes live in three completely different places, with three different search boxes, or none. A member who wants everything NANA has published on, say, dues modeling has to know to check the resource library, then separately check whether there's a related course, then maybe email someone about whether a chapter has relevant material. We want one search that returns all of it.

Host: Has a vendor been selected yet?

Renée Okafor: No, and I want to be direct about that, because I know people are curious. The RFP just went out. We're not naming a finalist, we're not leaning toward one, and anyone who tells you otherwise is guessing ahead of us. The selection process runs through the spring, and I'd rather take the time than rush it and pick wrong.

Host: What does the evaluation process actually look like, mechanically?

Renée Okafor: Written responses first, scored against the four requirements plus cost and implementation timeline. Then we bring finalists in for live demos, and critically, those demos include chapter staff, not just national digital team — because the chapters are the ones who have to live with whatever we pick day to day, and a system that only works for national headquarters isn't a system that works.

Host: What's the single biggest risk you're trying to avoid in this process?

Renée Okafor: Picking a platform that looks great in a sales demo and then rolling it out to all six chapters at once, only to discover in month two that it breaks for the chapter with the most idiosyncratic existing setup. I'd rather over-scope the RFP requirements now, even if it slows vendor responses down, than discover a gap after we've signed a contract.

Host: Is there a target date for when this actually launches?

Renée Okafor: I'm not going to put a date on air before we've even picked a vendor — that's exactly the kind of promise that gets you in trouble later. What I can say is the plan is vendor selection this year, build after that, and I'd rather under-promise the timeline than have members holding me to a date I named before we knew what we were building on.

Host: You mentioned chapter directories being current as one of the four requirements. Why does that need vendor software at all — isn't that just a matter of chapters keeping their own list updated?

Renée Okafor: In theory, yes, but in practice each chapter maintains its own roster in whatever tool it's comfortable with — a spreadsheet, a shared drive folder, in one case an actual paper binder that gets scanned periodically. Nobody's being careless, it's just that six chapters independently maintaining directories with no shared system means the national-facing directory drifts out of date the moment any one chapter's roster changes and doesn't get manually synced. A single system where a membership change updates the chapter directory automatically removes an entire category of manual syncing that currently depends on someone remembering to do it.

Host: How involved are the chapter chairs themselves in writing this RFP, versus it being a purely national digital-team document?

Renée Okafor: More involved than a typical national IT project would usually make them, deliberately. I did a call with all six chapter chairs before we finalized the requirements, specifically asking what breaks for them today that a new system needs to fix. Priya Ranganathan at Great Lakes flagged that her mentorship-pairing program needs a way to track pairings over a twelve-month cohort, which isn't something I would have thought to put in the RFP without her raising it. That's exactly the kind of requirement that only surfaces if you actually ask the people using the system daily, rather than writing the RFP purely from national's vantage point.

Host: Last question. What's the one thing you most want vendors to get right in their proposal?

Renée Okafor: Honesty about what their platform can't do out of the box. Every vendor's response is going to say yes to all four requirements. The ones I trust are the ones that also tell me which of those four is going to take custom work, because that's the answer that actually tells me what implementation is going to look like, not the answer that's optimized to win the bid. A vendor who tells me on the first call that single sign-on across six independently-run chapters is genuinely hard, and here's specifically how they'd approach it, earns more of my trust than one who tells me it's trivial.

Host: Is there budget pressure on this project, or is cost mostly a secondary factor next to getting the requirements right?

Renée Okafor: It's a real factor, not a secondary one — the board approved this project with a defined budget range, and part of the evaluation scoring weighs cost against the four core requirements rather than treating cost as a simple pass or fail line. What I've told my own team is that the cheapest proposal that meets all four requirements completely is a better outcome than the most fully-featured proposal that blows past the budget range, since a project that runs out of funding mid-implementation helps nobody.

Host: Renée, thanks for walking through it this early.

Renée Okafor: Happy to. Come back once we've actually picked something — that'll be a very different conversation, hopefully a shorter one, since by then most of the interesting questions should already be answered.