ICT for Civic Data — Turin University 2025-26
# Project Definition
and Proposal Outline
Crash Course — Day 1
civicliteraci.es
--- # Welcome --- ## The week at a glance Each day maps to one stage of the data pipeline: | Day | Focus | End-of-day outcome | |---|---|---| | **Day 1** | Define | Research questions, horizon table, proposal outline | | **Day 2** | Find, Get | Collected datasets, documented retrieval process | | **Day 3** | Verify, Clean | Verified, clean, consolidated dataset | | **Day 4** | Analyse | Data-informed arguments and visualisations | | **Day 5** | Present, Plan | Final proposal with data evidence | Your guiding thread: respond to a **Request for Proposals** with a proposal backed by data, not just words. Note: Set the frame for the week. The RFP is the red thread. Each day produces a concrete deliverable. Emphasise: by Friday you will have a complete proposal with actual data behind it. --- ## What you need this week - A **computer** with a modern browser (Chrome or Firefox) - A **GitHub account** and familiarity with Codespaces - An **agentic CLI tool** of your choice: Gemini CLI (free), Claude Code, or OpenAI Codex - A reliable **internet connection** Today's afternoon includes setup time for anyone who needs it. Note: Quick logistics. Most students have GitHub and Codespaces from the lectures. The setup slot in the afternoon is a safety net, not a tutorial. --- # Analysing the RFP Note: Transition: "The RFP is from a fictional organisation, but it is written the way a real funder writes. Your job is to read it the way a professional reads it: not just what it says, but what it means." --- ## What is an RFP? A **Request for Proposals** is a document issued by an organisation that wants to fund a project but does not want to design it themselves. - The funder describes **the problem** and **what they value** - Respondents propose **an approach** and **a team** to solve it - The funder evaluates proposals against **stated criteria** RFPs are work of interpretation: some method, some artistry. Note: Some students may never have seen an RFP. The funder has money and a problem, you have expertise and a plan, the RFP is the interface between the two. RFPs have very little formalisation beyond a deadline and some context. Everything else varies. --- ## Two types of RFP
Technical RFP
The funder knows exactly what they want. Specific technology, specific framing, little room for variance. Your job: deliver expertise within their box.
Strategic RFP
The funder knows they have a problem. They think data and AI are important, but **they don't know what that means concretely**. Your job: help them think through what they actually need.
Our practice RFP is the second type. Most RFPs in the data and AI space are. Note: This distinction is critical. Most RFPs students will encounter in the civic space are strategic, not technical. The funder is exploring. That means: do not take their framing at face value. Think from scratch about their actual need. --- ## Read the RFP Take **5 minutes** to read the full RFP carefully. [civicliteraci.es/rfp/disaster-preparedness/](https://civicliteraci.es/rfp/disaster-preparedness/) As you read, note: - What stands out to you - What surprises you - What you don't fully understand We will work through it together using the **analysis questions**. Note: Hand out or project the RFP. Give 5 minutes of silent reading. Then transition to the guided analysis. --- ## How to read an RFP (1/2) 1. What is the funder's **core problem**? 2. What does the funder **already know**? 3. What capacity is the funder **missing**? 4. What does the funder **explicitly ask for**? 5. What do they **signal but not prescribe**? 6. What is **NOT** in the RFP? Note: Show the full list before diving in. These are the questions we will work through together. First six focus on understanding the funder. --- ## How to read an RFP (2/2)
How will proposals be
evaluated
?
What would a
weak response
look like?
What would a
strong response
look like?
How can
data
strengthen this response?
What is
your angle
?
What are the
risks
?
Questions 1-6 are about **understanding the funder**. Questions 7-12 are about **designing your response**. Note: The split is deliberate: first you understand what the funder wants, then you figure out how to respond. We will work through all twelve together on the whiteboard. --- ## What is the funder's core problem?
"Climate-related disasters disproportionately affect communities with limited access to health facilities, emergency shelters, and transport infrastructure."
In your own words: what problem is CLI trying to solve? **Not** "they want a disaster preparedness methodology." That is what they are asking for. The problem is why they are asking. Note: RFP Analysis Guide Q1. Push students past restating the RFP. The problem is: vulnerable communities bear the worst impact and the funder cannot systematically identify where those communities are. Write student responses on the whiteboard. --- ## What does the funder already know?
"CLI's field staff possess deep expertise in the regions where they operate."
The funder is **not** starting from zero. Their field staff already know the regions, the communities, and the risks. What they lack is the **technical capacity** to systematically complement that expertise with data. Note: RFP Analysis Guide Q2. This is critical framing. A weak proposal tells the funder what they already know. A strong proposal adds what they cannot do themselves. Write on whiteboard: what the funder knows vs. what they need. --- ## What capacity are they missing? They say they need: - A preparedness assessment using data - A methodology - AI integration - Adaptability to other regions But remember: **the way the funder expresses their need is not necessarily the correct framing.** They may need a **strategy** for integrating data into their work before they need any tools or methodology. If there is no strategy, jumping to tools is a mistake. Note: RFP Analysis Guide Q3-4. This is the "challenge the assumptions" moment. The funder asked for a methodology and AI. But do they actually need that, or do they first need help thinking through how data fits into their existing processes? A real example: Civicus asked for a chatbot to process their reports. The real need was a content accessibility strategy, not a chatbot. The same logic applies here: read what they ask for, then think about what they actually need. --- ## What do they signal but not prescribe? Some phrases are **signals**, not requirements: - *"data-driven approaches"* — they want data, but they don't say which data or how - *"AI tools could inform the work"* — they are open to AI, but they don't know what that means concretely - *"improve efficiency and scalability"* — they want something reusable, not a one-off study - *"confirm and enrich existing local knowledge"* — they are not asking you to replace their field staff Your proposal should translate these signals into something concrete that **aligns with what they already do**. Note: RFP Analysis Guide Q5. The signals tell you what the funder values but cannot articulate. Your job is to translate their language into a plan that matches their existing processes. Don't deliver a product they can't use; deliver something that compensates for gaps and fits their reality. --- ## What is NOT in the RFP? - No specific **data sources** named - No **tools or software** prescribed - No **geographic region** specified - No **budget ceiling** mentioned Every absence is a decision the funder left to you. These are your degrees of freedom. Note: RFP Analysis Guide Q6. The absences are as important as what is written. Students should note: the RFP never says "use healthsites.io" or "use Python" or "focus on Kenya." Those are all your decisions. --- ## How will proposals be evaluated? Five criteria, in the RFP's order: 1. **Relevance and innovation** — does the approach fit the problem? 2. **Data-driven approach** — how effectively does the proposal use data? 3. **Use of technology** — how clear and realistic is the AI integration? 4. **Feasibility and impact** — can this actually be done? 5. **Scalability and adaptability** — can it be applied elsewhere? Which criterion do you think carries the most weight? Why? Note: RFP Analysis Guide Q7. Let students debate. There is no official weighting, but "data-driven approach" and "use of technology" together signal that the funder really cares about how data and AI are used, not just that they are mentioned. Feasibility matters because funders have been burned by ambitious proposals that cannot be delivered. --- ## What would a weak response look like? A proposal that: - Restates the problem without adding anything the funder doesn't already know - Takes the RFP's framing at face value without questioning whether it's the right approach - Treats AI as a magic solution: "we will use AI to analyse the data" - Proposes advanced tools when a strategy and simple tools would be more appropriate - Describes a methodology but provides no evidence it would work **A weak response tells. It does not show.** Note: RFP Analysis Guide Q8. Have students contribute. Write their ideas on the whiteboard. Emphasise: the funder doesn't know what they want when it comes to data and AI. A proposal that just gives them what they asked for, without thinking about what they actually need, is a weak proposal. The chatbot example: Civicus asked for a chatbot. What they needed was a content strategy. --- ## What would a strong response look like? A proposal that: - **Challenges the framing** where needed: maybe they need a strategy before they need tools - Chooses a **specific region and hazard** and explains why - Proposes something that **fits their existing processes**, not something they can't use - Explains how **AI is used at specific steps** with safeguards, not as a blanket solution - Acknowledges **risks and limitations** honestly And the strongest responses do one more thing. Note: RFP Analysis Guide Q9. Build the list with students. The first point is the key difference: a strong response thinks from scratch about what the funder actually needs, rather than just answering what they asked. Pause before revealing "one more thing" on the next slide. --- ## How can data strengthen this response? There are two ways to respond to this RFP:
Describe your approach
"We will use geospatial data to identify vulnerable communities and map infrastructure gaps." The funder reads a plan. They hope it works.
Demonstrate your approach
"We analysed flood events and health facility coverage in Region X. Here is what we found, and here is what it means for preparedness planning." The funder sees evidence. They trust the team.
Note: RFP Analysis Guide Q10. This is the key insight of Day 1. Pause and let it land. The RFP does not ask for a demonstration. But a proposal that shows actual preliminary analysis is far more convincing than one that only describes a plan. This is what we are building toward this week. --- ## The "show don't tell" advantage The RFP asks you to **describe** how you would use data and AI. It does **not** ask you to demonstrate it. But a proposal that backs up its arguments with actual data analysis does two things at once: 1. It answers the RFP's question about methodology 2. It **proves your team can do the work** This is what we will build across the five days. Note: Reinforce the insight from the previous slide. This framing should carry through the entire week. Every deliverable students produce is both a piece of the proposal and evidence of their capacity. --- ## An RFP response is a story Everyone in the process knows that a proposal is a **narrative**. The delivery is often very different from the story told. Funders know this too. What makes a story compelling is not promises. It is **knowledge and clarity of thought**. - Past work, recommendations, and credentials are signals of trust - Data analysis is a signal of **competence and rigour** - The story is how you connect the data to the funder's problem and show it serves a clear goal This week is not just about learning data and AI skills. It is about learning to **tell the story** of how those skills make sense within a project. Note: This is the bridge between the data argument and the week's broader purpose. The proposal is a narrative. Data makes that narrative credible, but the skill is in connecting the data to the funder's context in a way that shows clarity of thought. Students should think of every artifact they produce this week as part of that story. --- ## What we covered this morning - What an RFP is and how to read one strategically - The difference between what a funder asks for and what they actually need - Why data makes a proposal credible, and why storytelling makes it compelling **This afternoon:** choose your angle, form teams, set up your tools, and start exploring what data exists. Note: Quick recap before lunch. The morning was the strategic framing. The afternoon is where the work begins: angles, teams, tools, and AI-assisted data discovery.