The short version
One run per project, answered by its team. Each person picks their role and reviews the practices that apply to it, one yes-or-no question per screen: is the code reviewed, are backups scheduled, are requirements clear before work starts.
Each practice has an importance (Critical, Important or Minor), and each area gets a score out of 10 from the weight of the practices in place. The report lists what is unmet, most important first, and what nobody could confirm. Answers are self-reported: the survey finds where to look, it doesn't audit.
Fourteen areas
The 248 practices sit in 14 areas. Eight areas are for the technical role, three for management, one for design, and two, AI Amplifiers and Team Happiness, for everyone. By default 178 practices are Critical, 46 Important and 24 Minor.
Every practice is a plain question: it starts with the verb, stays under about ten words, and keeps its examples on a second line. Where the original rule was phrased so that No was good, it was turned around, so Yes is always the good answer.
Roles and routing
The first question routes everything after it. Someone can pick more than one role, and sees the areas for each of them plus the ones for everyone.
Each practice question offers the same three answers: Yes, No, Not sure. "Not sure" is there on purpose: a practice someone can't see from where they sit isn't a No. The report collects those for the team to clarify.
From answers to a score
- Each practice carries a weight from its importance: Critical 10, Important 5, Minor 2. The defaults come with the survey; the run's configuration can change which practices apply to the project and how important each one is.
- An area's score is the weight of its Yes answers over the weight of everything answered Yes or No, scaled to 10. With several people answering, a practice gets credit for its share of Yes among its Yes and No answers.
- Not sure and unanswered are not No. Not sure counts as answered but adds nothing either way; a practice nobody answered is left out of the score and lowers coverage.
- The overall score is the plain average of the area scores, each area weighing the same. It shows only once every applicable question has an answer of any kind, which usually takes people from each role.
Try it on four practices of one area, as one person would answer them:
Reading a score
The report colors scores in four bands. In its own words, they are review guides, not validated thresholds: there is no benchmark behind them.
Findings, not grades
A score says how much of an area is in place; the findings say what to do. Each area gets a status from its practices, and the areas are ordered so the top rows are where to act: most Critical unmet practices first, then the most unmet weight.
- Fully unmet: every applicable practice in the area was answered No, and none got a Yes.
- Partly unmet: at least one practice is unmet. A practice is unmet as soon as anyone answers No; with a Yes from someone else it shows as partly unmet, with the counts, so disagreement shows instead of averaging away.
- Incomplete: nothing is unmet, but a practice is unanswered or only Not sure.
- Fully met: everything applicable has a Yes and no No.
Where the team isn't sure lists every practice with a Not sure, most unsure first: a high share means the practice isn't visible to the people asked, and needs clarifying before it counts as met or unmet.
What the report shows
- Top summary: the overall score out of 10 on a gauge, answer coverage, practices to improve (applicable practices someone answered No) and the Not sure count.
- Quality profile: one spoke per area on a radar, scored 0 to 10, so the dents toward the middle are the weak areas.
- Section scores: every area with its score and "answered · not sure" counts; open one to see each practice's answers, like "Yes (2) / No (1)".
- Findings by area and Where the team isn't sure, as above.
- Trends: the overall score, practices met, critical practices met and coverage, run by run, for up to the 12 most recent earlier runs of the survey.
- Export: a PDF with the summary, the profile, the scores, the findings and an appendix of every answer with its weight.
The run's Configuration tab chooses which practices apply to the project and how much each counts, and it re-scores answers already given, so a project can drop a practice that doesn't apply instead of answering No to it.
Where the practices come from
The practices are Ralabs' own software quality management checklist, used in its delivery reviews: 241 rules in 12 categories, with the weights Critical 10, Important 5 and Minor 2, plus 7 new questions on team happiness. For the survey the rules became questions, the project management category was split into Product & Requirements and Project & Team Management, and the scoring was changed in two ways: an unfavourable answer scores a true zero, and areas average equally.
Who sees what
- It can run anonymously. The one-click launch uses a shared password without names. Advanced setup can ask for a name or an email, or use Google sign-in, and then the Responses tab names people.
- Whoever can open the report sees every answer, grouped by section, and can export the PDF. A public link, if one is made, shows the Insights only, as aggregates.
- Team happiness answers are one person's experience. The area counts like any other, so in a small team the report can point to one person.
Limits
- Self-reported. Several people answering the same question can expose a disagreement, but not settle who is right. Treat a finding as something to check.
- No benchmark. There are no company averages, and the bands aren't validated thresholds.
- Trends compare runs of the survey in your organization, not of one project, and scores are only comparable while the areas and the configuration stay the same.
- Coverage matters. The overall score waits for every applicable question, and a run with a single role answering scores that role's areas only.