Capital committee agrees method to convert member rankings into weighted RORI scores; members to submit rankings for developer implementation

At its July 31 meeting, the Capital Committee agreed on a practical path to convert members' priority rankings into weighted inputs for the committee's RORI (ranking) system and asked staff to collect those rankings for the developer to implement. Committee members and finance staff spent the meeting discussing how to translate subjective category rankings into the software's required numeric weights.

The decision matters because the RORI scores are used to prioritize capital requests the town will consider before Article 10 and other borrowing or spending decisions. A software constraint highlighted by staff requires that criteria grouped together be normalized so that the group's weights sum to 100 percent rather than assigning 100 percent to every criterion individually.

Brian, a staff member who led the technical explanation, told the committee: "you have created 3 groups called prioritization, quantitative justification for project, and cost," and explained that "the group as a whole has to equal 100% in the criterion when you're doing this calculation." He said the way members had proposed assigning a 100 to every single criterion would not work in the system and would force a change in how the developer must receive the inputs.

Committee members debated several practical ways to generate those inputs. Caroline Foster, a committee member, said the tool "was a very expensive and time consuming effort" but suggested checking with Steven Welch or the consultant to confirm whether members were using the system correctly. Multiple members agreed the committee should provide relative rankings for the master categories and then rank criteria within each category.

The group settled on a method that asks each member to: (1) rank the master groups relative to one another, and (2) rank criteria within each group (for example, 1 through 6). Staff will aggregate those ranks, convert them to weighted percentages (normalize them so group totals equal 100 percent), and send the normalized weights to the developer for programming and testing. Brian told members the normalization math can be done in Excel and then submitted to the vendor for implementation.

Committee members also discussed alternatives raised during the meeting: giving equal weight across groups, individually assigning each criterion a 100 percent (which staff said would require creating many more groups), or reverting to a manual Excel process. Brian warned that assigning a 100 percent to every criterion would either require the committee to create many single-criterion groups or would produce incorrect results.

Members recorded one implementation detail during discussion: the portion of software development that will accept the normalized weights had been the most expensive piece of the project, described during the meeting as "the absolute most expensive piece of the roughly $45,000 that I've spent." Staff said they could prioritize a rush implementation if the committee requested it and were prepared to pay a premium for expedited work.

Discussion-only items included the history behind the scoring method (Brian said it "was created by a mathematician in Singapore" and brought to the committee to reduce individual bias) and whether some criteria should be combined or reworded so entries are more discrete. Committee members repeatedly emphasized the need to preserve a method that is straightforward for future committee members to use.

Direction and immediate next steps: members agreed to submit their individual rankings in the Excel template that staff will circulate. The committee asked that members send their completed rankings to Deputy Finance Director Sue Carmel (and staff) promptly; staff requested submissions within roughly 24 hours of the meeting so the normalization and vendor implementation can proceed. Staff will normalize the aggregated ranks, provide the normalized percentages back to the committee for review, and then send them to the vendor (referred to in the meeting as Plumb/Plum) for programming and testing.

No formal vote was taken on the scoring formulas themselves during the meeting; members agreed on the approach by consensus and recorded the assignment of work to staff and members. The committee also discussed scheduling for full project reviews later in the fall, noting that most ranking of specific capital requests will take place after the framework is implemented and departments have submitted their project materials.