This guidance is in addition to the Configuration, Forms Mapping and UAT Video and describes how we configure the system, conduct forms mapping and UAT.
What does configuration mean in Primero?
Configuration in Primero means modifying the baseline forms, roles and permissions to reflect your programme.
Customization refers to the process of building features and functionalities that do not yet exist in Primero.
Both of the above have time and cost implications for rolling out Primero.
What information is handled by configuration?
- Forms,
- Lookups,
- Searchable and mandatory fields,
- Alerts,
- Roles,
- Matching criteria,
- Workflows, (ie. approvals)
- Reports,
- Locations,
- Agencies,
- User groups,
- Custom exports,
- Programs and modules,
- Contact information,
- Notifications, and
- System settings.
Information listed above require situational analysis and planning.
Why is configuration so hard?
No two programmes are the same. Depending on the country, or module, Primero needs to be able to accommodate various language, workflows, roles and forms. The platform is required to adapt to the nature of the programme. But it’s not as easy as it seems. In the example below, we have one form. That one form may have 5 fields where some may be mandatory, and others could have multiple choice options. Each one of those 5 fields may interact with different types of functionality (for example, approvals workflows, dashboard, reports, imports and exports of transfer functionality). And each of those functionalities may only be accessible by certain user roles. Even with this simple example, this configuration could require up to 2,500 code configurations.
What are the configuration process steps?
There are 5 steps in the configuration process.
Step 1: Analyze (50% effort/time)
Step 2: Plan (20% effort/time)
Step 3: Configure (10% effort/time)
Step 4: Verify (15% effort/time)
Step 5: Rollout (5% effort/time)
We will explain these steps in further detail below.
Analyze : Gather insights and requirements from front-line users. In this case, the insight we gathered helps us configure forms and groups of users (organizations and geographic locations).
Plan: Map your insights. Primero has a specific form mapping process which involves comparing Primero’s “out-of-the-box” baseline forms to the new forms you want to create. As much as possible it is advisable to use or modify (i.e. re-label, re-order) existing fields or forms.
Configure: All configurations are made on a locally-installed test system (Virtual Machine). In this test system or “sandbox”, you can make configuration changes and test those changes. Primero has been designed and tested to allow many users to interact with a common data set, allowing us to set granular permissions to allow app to facilitate your programme while protecting data confidentiality.
Configuration can be tricky when modifying such a highly integrated data model. Making changes to the configuration may have unintended consequences, so it is important that this process is handled carefully. For example, it is not advisable to change an existing field’s data type (for example, do not change a radio button to a tick box). We advise that you do not delete a field, and then create a field with the same db name and a different type. We recommend that you do replace fields whose type you want to change by deleting or hiding them, then creating a new one. We also recommend that you give a new field a different db name and a different type. See the Configuration Guide for more tips.
Verify: Following any change to configuration, you must verify that the application functions correctly in the Virtual Machine sandbox. To do this, open a case and fill in every field and save. Create a report and view that report. Log in as a user with any role you have modified and test that everything works.
All configurations should pass through a QA process to test that they are performing correctly before any real data is added to the system. QA is conducted by a team of testers tasked with ensuring that the system is not breaking, there aren’t any bugs preventing the functionalities and workflows of the system, and that the system is functioning as per the business requirements. You can learn more about the Primero development cycle here.
Conduct User Acceptance Testing (UAT). UAT is the phase of the process where front-line users test the configuration changes and make sure it is functioning as expected and according to their requirements that were originally collected in the Analyze step. UAT can be coordinated by your team and can also be coordinated by the software vendor team. They will work with the participating agencies to designate a representative in the group of end-users (case/social workers, managers, coordinators and service providers). All feedback should be tracked and resolved. See our sample alpha feedback spreadsheet to help you in coordinating UAT. This UAT group is established before the ‘release’ of the alpha system with the desired configuration. A clear timeline is to be set for this that allows enough time to review, make changes and review those changes before the system is planned to go live.
Once the system is live and real cases are entered in the system, all end-users should be providing feedback through regularly held feedback sessions. Especially in the first months of the go-live.
But isn’t User Acceptance Testing (UAT) the same as Quality Assurance (QA)?
No, UAT and QA are both different phases of the development cycle. QA is conducted by a team of testers tasked with ensuring that the system is not breaking, there aren’t any bugs preventing the functionalities and workflows of the system, and that the system is functioning as per the business requirements. UAT on the other hand are front-line users who are those that are interacting with the system on a regular basis to check and ensure the system accurately reflects their work processes and addresses the problems it was meant to address.
Rollout: Perform rollout once verification has been completed on all changes. Send the new configuration bundle to all synced instances. Make sure that you also send the password for decryption (according to ISP). Coordinate time for all instances to load the new configuration.