WeWorld & the BEAM Experience - End-to-End Process Management with ActivityInfo and Microsoft 365

00:00:01 Introduction to WeWorld and the PRISMA ecosystem

Alberto introduces WeWorld, an international NGO based in Italy that operates in both humanitarian and development cooperation. They work across more than twenty countries in various sectors, primarily supporting children, women, and young people. Because they operate in diverse cultural, economic, and political environments with different types of donors, they currently manage over one hundred ongoing projects alongside 177 national and international partners. These diverse characteristics create varying reporting requirements and needs, which prompted the organization to build an integrated information management system a year ago. This homemade system is called PRISMA, which stands for Project Information, Sharing, and Management. PRISMA is not just a single platform, but rather an integrated ecosystem where different platforms host various modules capable of exchanging data and information. The philosophy behind PRISMA is to leverage existing platforms that can be adapted to cover specific functionalities.

00:02:46 The BEAM module and project design flow

When creating this system, which centers around a project database, the team needed to ensure data quality and standardized characterization for every project. They wanted to analyze similar projects uniformly and understand how each project contributes to their global strategy. To achieve this, they looked for a common entry point for all projects and identified the project design procedure as the ideal moment to start collecting data. This led to the development of the BEAM module, which stands for Blueprint for Entry and Acquisition Management. BEAM serves as this entry point and the first step for data collection.

The BEAM module follows the typical flow of the project design phase. It begins with the development of a proposal idea, usually triggered by a call for proposals or donor interest. The team analyzes what they can offer and assesses the risks associated with the proposal, including financial, contextual, and implementation risks. Information is gathered from the field, analyzed by a dedicated team, and evaluated for mitigation measures to decide whether to proceed. If approved, the proposal drafting phase begins. During this phase, information is collected to determine which internal support services at the headquarters, regional, or country level are needed to improve the proposal's quality. For instance, thematic experts or the legal department might be notified to assist.

Once a final draft is reached, consolidated data is entered into a specific final data module for quality control. The financial and programmatic departments check the proposal for quality and coherence with the global strategy. After passing these checks, the proposal is submitted to the donor. If the donor approves it, the project officially enters the project database and begins its second life within PRISMA, where it is managed by other modules. BEAM acts as the light beam that feeds PRISMA, while PRISMA acts as the lens that organizes and systematizes the information to feed output tools, preset management and monitoring tools, and exchange data with other systems like the financial system.

00:09:35 Choosing ActivityInfo and Microsoft 365 integration

The organization chose ActivityInfo because they were already using it for data collection and management. They wanted to take advantage of its low-code approach, which makes it easy to set up interconnected forms and utilize the built-in database. This flexibility is crucial right now, as the cooperation sector is facing a complex crisis with changing donor rules and dynamic environments. Unlike tools managed by external software houses that have contractual and timing constraints, ActivityInfo allows internal teams to make modifications whenever necessary. Alberto also highlighted the high quality of support from the ActivityInfo staff, who have been responsive and interested in expanding features to meet WeWorld's needs.

A major challenge was pushing ActivityInfo beyond simple data collection to manage a continuous workflow performed by various roles over extended periods, such as a two-month proposal process. To achieve this and reduce excessive email exchanges and complex spreadsheets, the IT and MIS department integrated ActivityInfo with their Microsoft 365 environment. This integration enabled a notification system that dynamically modifies access permissions based on the process stage and user role. It orchestrates workflows and automates SharePoint, Teams, and Outlook. For example, when a project reaches approval status in BEAM, it triggers the creation of an archiving system.

00:15:20 Technical setup and system demonstration

Matteo explains that mapping the workflow phases into ActivityInfo required a different approach than their usual forms. Initially, they considered using a single form with different sections, but they realized a more structured approach was necessary to allow different roles to edit information at various stages. They switched to a structure utilizing several subforms and layers. For example, the proposal idea is a primary subform with a secondary level for risk analysis and a tertiary level for evaluation. This structure cross-references user roles, ensuring that different people are involved in evaluations and approvals based on the project's economic value or identified risks.

The proposal drafting stage includes several subforms to collect information about required support. The final data stage captures budget allocation and direct support costs. The sign-off stage involves virtual approval signatures from different roles depending on the country and strategic coherence. Finally, the submission stage records the donor's decision. If a project is in the concept note phase, a loop might require users to return to the beginning to expand the information for a full proposal, which reopens editing capabilities and triggers new notifications.

Within ActivityInfo, each subform contains calculated fields dedicated to the notification system. These fields determine the trigger, the subject, the message, and the recipients based on role, country, or specific individual involvement, such as thematic experts. A choice field indicates whether the notification has been sent. Having separate subforms allows the system to use the same fields but apply different calculations. For instance, an email notification means the user is expected to log in and take action, while a Teams notification simply keeps them informed without requiring action.

Behind the scenes, standard ActivityInfo triggers send information to Power Automate. A solution containing numerous flows manages these triggers. When a user edits a form, a flow collects the data and calls a standard notification flow. This complex flow evaluates the fields, decides if a Teams or email notification is needed, sends it, and updates the flag in ActivityInfo to confirm delivery. When a focal point logs in to create or edit a record, they only see records related to their specific countries. While roles can read all subforms, they can only interact with the ones assigned to them under specific conditions. Users simply go through their natural steps of editing, and the system automatically handles the notifications without requiring heavy coding.

00:25:20 Lessons learned during development

The development process involved significant collaboration with the ActivityInfo support team. The primary benefits achieved were improved efficiency and collaboration. The system allows the team to collect information once, officially validate it, and reuse it across different scenarios without needing to export and import data between systems.

One major lesson was that a single form with multiple sections did not work well for segregating duties. They had to use subforms to manage different notifications for separate stages. Additionally, because ActivityInfo only allows one record of a subform for each parent form, they had to implement a technical workaround to stress the calculation and prevent duplicate information for the main form.

Setting up required fields under certain conditions was also tricky. Forms like the risk analysis have long lists of sections. Marking all fields as required would prevent users from saving their progress as a draft. Instead, they created calculated fields that functionally display missing required information without strictly marking them as required in the system. While newer versions of ActivityInfo offer required rules for conditional mandatory fields, this was not available during their initial setup. Finally, Matteo noted that adding conditional formatting to the forms would greatly improve readability and user-friendliness, as it would visually highlight missing or non-compliant information better than the current text-based calculated fields.

00:31:20 Q&A session

During the Q&A, Alberto addressed whether they plan to integrate more modules or migrate parts of PRISMA into ActivityInfo. He confirmed they are developing several modules, though their goal is not to use ActivityInfo for absolutely everything, but rather to evaluate the best tool for each specific need. The core project database is already in PRISMA, and they use a 'Projects' module twice a year to collect data for strategy and accountability. They are also developing a MEAL plan module. Once a project is approved, BEAM collects the logical framework indicators, which are then aligned with WeWorld's standard global strategy indicators. This presets the MEAL plan so that tools are ready on day zero of implementation, requiring only minor adjustments. They prefer using small, simple, integrated tools, utilizing ActivityInfo when appropriate and other options for qualitative text-heavy data.

Regarding the beneficiaries database, Alberto clarified that beneficiary data is not collected directly during the BEAM phase. Instead, it is collected at the very end when a project is approved. They gather a breakdown of beneficiaries disaggregated by gender, age, and immigration status. This information is managed by the 'Project' module and updated twice a year. Currently, individual projects do not use ActivityInfo to track daily beneficiaries because each project has a different tracking method, often relying on Excel. However, they are working to create standardized ActivityInfo tools for more complex projects. Alberto demonstrated the simple form used by country offices to submit participant breakdowns, noting that while ActivityInfo's interactive tables could allow direct editing, they prefer country offices to use the submission form while headquarters uses the interactive features for data cleaning.

When asked if field teams use ActivityInfo for surveys and project management, Matteo and Alberto explained that they are trying to standardize certain project types, like education, to provide teams with a customizable base rather than starting from scratch. However, standardizing monitoring and data collection across all project types remains difficult, which is why they rely on the biannual standard tool to collect project states and beneficiary data.

Finally, addressing a question about automatically exporting data to Word, Alberto stated they do not currently do this. Instead of Word reports, they prefer to produce reports and dashboards using Power BI. They publish these dashboards so that local authorities and partners can navigate and analyze the collected data themselves. Any necessary Word reporting is still done manually, occasionally integrating information produced by ActivityInfo.