CASE STUDY · NONPROFIT & ASSOCIATIONS · APP DEVELOPMENT
A Committee Collaboration Platform Serves 5,000+ Users at an Industry Standards Organization
Discussions, comments, and standards voting now run on .NET and SharePoint in the Azure cloud.
The Enterprise Challenge
An outdated application no longer matched how committees needed to collaborate, comment, and vote on industry standards.
The client is a non-profit standards development organization. It shapes industry standards in close collaboration with a federal regulatory partner, and it does that work through committees: groups whose members come from many different organizations and who meet, comment, and vote to decide what an industry standard says. Everything those committees do day to day, voting, collaboration, and event scheduling, ran inside a single application.
That application had become outdated and unsupported, and it no longer aligned with the organization’s evolving requirements. What the organization needed instead was a modern, custom system where users from different organizations and committees could work together in one place. Each committee or topic group required a separate workspace for discussions, document comments, and voting on industry standards. Administrative functions were equally essential: maintaining the system, managing who belonged to which roster, and generating reports on meeting attendance. i3solutions was approached to create this system and to provide ongoing support for it.
The Solution
At a Glance
An industry standards organization’s committees were voting on and discussing technical standards through an application that no longer matched how its 5,000+ members needed to collaborate. i3solutions rebuilt the platform on .NET and SharePoint in Azure to carry that workload at scale.
Since implementation, the platform has supported approximately 5,000 users conducting committee discussions and standards voting, and its infrastructure was built to expand as demand grows rather than require a costly upgrade or replacement.
Strategic Trigger
The Application Running Committee Business Was No Longer Supported
An unsupported application is not an inconvenience for an organization whose output is a standard. Committee members vote inside it, comment on documents inside it, and schedule the meetings where decisions get made inside it. When the application behind that work stops being supported, every one of those steps carries a risk that nobody in the organization is positioned to fix, and the organization’s own requirements keep moving away from what the software can do.
The requirements had in fact moved. The organization needed workspaces separated by committee or topic group, access that differed by person, and administrative reporting on meeting attendance, none of which the existing application was aligned to. The decision was to rebuild rather than to keep working around the gap, and to rebuild with support arranged from the start so the same position would not recur.
Conditions That Triggered the Engagement
- An existing application carrying daily committee operations, voting, collaboration, and event scheduling, that had become outdated and unsupported
- A requirement that each committee or topic group work in its own separate workspace for discussions, document comments, and voting on industry standards
- Administrative functions that had to exist for system maintenance, roster management, and generating reports on meeting attendance
An Industry Standard Shouldn't Run on Unsupported Software
This organization’s entire standards process depended on software nobody supported anymore. If a similar single point of failure exists in your own mission-critical process, that’s worth surfacing before it becomes an emergency.
Stakes
Standards Work Depends on the System Its Committees Vote In
The organization’s role is to shape industry standards in close collaboration with a federal regulatory partner. That role runs on committee business, and committee business had one dependency: an application that had become outdated and unsupported. Left alone, the risk sat directly on the process the organization exists to run.
There was a second cost, quieter and continuous. Members come from different organizations, so collaboration is not internal by nature; it has to be given somewhere to happen. Without separate workspaces, an access level per person, and administrators able to manage rosters and attendance, coordination falls back onto whoever is willing to track it by hand, and sensitive industry standards discussions run without a permission structure holding them.
Constraints and Complexity
Many Organizations, One Platform, Access Defined Per Person
The users of this platform do not share an employer. They are members of committees and topic groups drawn from different organizations, which makes access the defining constraint rather than a configuration detail. The permission structure had to set each individual’s access level so that people see and do what their role allows, because that is what makes the platform usable for sensitive industry standards discussions at all. Alongside it, administrators needed real functions: maintaining the platform, adding users to workspace rosters, and running reports on meeting attendance.
The second constraint was structural. Every committee or topic group needed its own workspace, focused and organized, for its own discussions, document comments, event scheduling, and votes, rather than one shared space with everything in it. And because the system was replacing something that had gone unsupported, the engagement could not end at delivery: ongoing support had to be part of what was built, not a separate conversation afterward.
Selection Rationale
Senior Microsoft Specialists with Proven Delivery Depth
The requirements defined the vendor profile. This was a custom application to be built, not a product to be configured: workspaces, voting, event scheduling, document commenting, a per-person permission structure, and administrative functions for rosters and attendance reporting, with SharePoint as the document repository underneath and Azure as the host. The organization also needed the team that built it to stay with it, since the whole reason for the project was an application nobody was supporting anymore.
The organization engaged i3solutions, a Microsoft Partner with 30 years of delivery experience and 1,500+ Microsoft engagements, delivered by an all-senior, all US-based delivery team. That profile matched the work: senior engineers who have built custom applications on .NET with SharePoint and Azure repeatedly, and who could carry the platform past launch into bug tracking and release management rather than handing it over at go-live.
The Engagement Approach
i3solutions built a custom committee collaboration platform through custom application development: a custom .NET application with SharePoint as the document repository, hosted in the Azure cloud, plus the ongoing support arrangement that keeps it current.
PHASE 01
Committee Operations and Access Definition
The scope came from how committee business actually runs. Which groups need a workspace of their own, what happens inside one (discussions, document comments, event scheduling, voting on industry standards), which administrative functions the organization has to have, and what access level each individual should hold. That definition produced both the platform’s feature set and its permission structure.
PHASE 02
Platform Architecture on .NET, SharePoint, and Azure
The system was architected as a custom .NET application, with Microsoft SharePoint serving as the document repository for industry standards discussions and Microsoft Azure hosting the whole solution. The cloud environment was chosen so the system can adapt to the organization’s changing needs and stay reachable for users working from different locations.
PHASE 03
Workspace, Permission, and Administrative Development
Each committee or topic group got a separate workspace for discussions, document comments, event scheduling, and voting. The permission structure was built so that individuals hold the appropriate access level. Administrative functions were built for maintaining the platform, adding users to workspace rosters, and running reports on meeting attendance.
PHASE 04
Launch and Ongoing Support
The platform went live and has since accommodated approximately 5,000 users. i3solutions integrated JIRA into the solution for bug tracking and release management, established a one-day response time for tickets labeled as bugs, and used JIRA automation to drive the release schedule.
Technical Transformation
The platform is a custom .NET application with two Microsoft services doing specific jobs behind it. Microsoft SharePoint is the document repository: it holds the documents committees work from, giving secure storage, easy access, and one place to comment on and discuss the documents that industry regulation turns on, with the latest version readily available rather than circulating as attachments between organizations. Microsoft Azure hosts the solution, which supplies a scalable and flexible cloud environment that adapts as the organization’s needs change and makes the platform available to users from different locations. Microsoft .NET carries the application itself: the workspaces, the voting, the event scheduling, and the administrative functions, built to the organization’s specific needs rather than configured from an existing product. Running across all of it is the permission structure, which sets each individual’s access level and is what makes the platform usable for sensitive industry standards discussions. JIRA sits alongside the system rather than inside it, tracking bugs, managing tasks, and planning the schedule for future releases.
Measurable Outcomes
One Workspace Per Committee
A custom .NET application on Azure gives each committee or topic group its own space for discussion, document comments, and voting.
| Outcome | Before | After |
|---|---|---|
| Committee operations platform | An outdated application no longer aligned with the organization’s evolving requirements | A custom .NET application with SharePoint as the document repository, hosted in the Azure cloud |
| Committee and topic group collaboration | Daily voting, collaboration, and event scheduling inside one application | A separate workspace per group for discussions, document comments, event scheduling, and voting on industry standards |
| Access control | Users from different organizations and committees needing appropriate access | A permission structure that sets each individual’s access level |
| Platform administration | Administrative functions essential but unmet by the existing application | Functions for maintaining the platform, adding users to workspace rosters, and running reports on meeting attendance |
| Ongoing support | An unsupported application | JIRA bug tracking and release management, with a one-day response time on tickets labeled as bugs and an automated release schedule |
Since implementation, the system has accommodated approximately 5,000 users, streamlining committee activities and discussions related to industry standards. That is the scale figure, and it is the one number this engagement carries: what changed underneath it is qualitative and specific. The infrastructure is designed to adapt and expand as demand grows, so a new initiative does not arrive as a costly upgrade or replacement. The permission structure gives each person the appropriate access level, which is the condition for holding sensitive industry standards discussions in a system whose members work for different employers. And users from different organizations and committees now work in one place, so the communication, voting, and event management a decision depends on happen where that committee’s documents and roster already sit.
The support arrangement is the other half of the result, because an unsupported application is what triggered the engagement in the first place. i3solutions integrated JIRA for bug tracking and release management. Tickets labeled as bugs carry a one-day response time from creation, and each one is tracked to resolution through JIRA automation, which keeps disruptions short. The same automation drives the release schedule, so the organization has full awareness of upcoming drops and the tickets included in each one. That transparency is what lets an organization whose calendar is set by committee meetings plan around a release instead of around a surprise.
PENDING-CLIENT-QUOTE
Who This Engagement Serves
This engagement is relevant for
- A standards development organization whose committees vote, comment on documents, and schedule events inside an application that has become outdated and unsupported
- A membership or committee body whose participants come from different organizations and therefore need an access level set per individual rather than one shared level
- An organization that needs the team who builds its platform to stay with it afterward for bug tracking and release management, not hand it over at go-live
Less relevant for
- Your committee work fits an off-the-shelf collaboration product and does not need per-group workspaces, voting, roster administration, or attendance reporting
- You need a document repository only, without the custom application layer that holds the workspaces and the voting around it
What This Engagement Established
Committee Voting, Collaboration, and Scheduling on One Supported Platform
The engagement established that a non-profit whose output is an industry standard does not have to run that process on software nobody supports. A custom .NET application, with Microsoft SharePoint as the document repository and Microsoft Azure as the host, replaced the outdated application with a platform where each committee or topic group works in its own workspace for discussions, document comments, event scheduling, and voting.
A permission structure sets each individual’s access level, and administrators maintain the platform, manage workspace rosters, and run reports on meeting attendance. Approximately 5,000 users have worked in the system since it went live. The support arrangement is part of the deliverable rather than an afterthought: JIRA carries bug tracking and release management, tickets labeled as bugs get a one-day response time, and JIRA automation gives the organization advance sight of every release.
Frequently Asked Questions
A custom committee collaboration platform is a purpose-built system where the working groups of a membership organization do their business in one place: discussions, comments on documents, event scheduling, and voting. For this non-profit standards development organization, i3solutions built it as a custom .NET application with Microsoft SharePoint as the document repository, hosted in the Azure cloud. Two design choices define the category. First, separation by group: each committee or topic group gets its own workspace, which keeps discussion and decision-making focused and organized rather than pooled. Second, access by individual: a permission structure sets each person’s access level, which is what makes the platform usable for sensitive industry standards discussions when the participants come from different organizations. Administrative functions sit alongside both, covering platform maintenance, workspace rosters, and meeting-attendance reporting.
Yes. The platform sets access individually rather than by a single shared role, which matters because this industry standards organization’s committees draw participants from different member organizations, not one employer with a standard permission tier. Each committee or topic group gets its own workspace for discussion, document comments, and voting, with access assigned to the individual rather than inherited from an organizational affiliation.
The starting point is what the current application still carries, because in an organization like this one it carries the actual business: voting, collaboration, and event scheduling, every day. On this engagement, i3solutions worked from the requirements the old application had stopped meeting rather than from a feature-for-feature copy of it. That produced a custom .NET application with SharePoint as the document repository and Azure as the host, separate workspaces per committee or topic group, a permission structure setting access by individual, and the administrative functions for rosters and attendance the organization had to have. Support was designed in rather than bolted on, since being left unsupported is the condition the project existed to end: JIRA for bug tracking and release management, with a one-day response time on tickets labeled as bugs.
Yes. The permission structure gives each individual the appropriate access level, which is what makes the platform usable for sensitive industry standards discussions. Each committee or topic group also has its own workspace, and administrators control who is on each workspace roster. That combination is what lets people from many different organizations work in one system: separation is enforced by the platform rather than by convention, so a member sees the groups they belong to and the material their access level allows. Administrators keep the model current through the platform’s administrative functions, adding users to workspace rosters as committee membership changes, and they can run reports on meeting attendance for the groups they administer.
Approximately 5,000 users have worked in the system since it went live, spread across the different organizations and committees whose members develop industry standards. That figure is a measure of reach rather than of a single group’s size: the platform’s users are not one organization’s employees but participants drawn from many, which is precisely why the permission structure and the per-group workspaces matter at that scale. Hosting in Azure follows from the same fact: the users are not in one building or on one network, so the platform has to be reachable from wherever they work, and it has to have room to take on more of them without a costly upgrade or replacement.
i3solutions integrated JIRA for bug tracking and release management. Tickets labeled as bugs carry a one-day response time from creation, and each one is tracked to resolution through JIRA automation. The same automation drives the release schedule, so the organization knows what is in each upcoming drop and which tickets it includes. Practically, that gives the organization two things the previous arrangement did not: a stated commitment on how quickly a reported defect gets a response, and advance visibility of what is about to change in the platform. For a body whose calendar is set by committee meetings and votes, knowing when a release lands and what it contains is what makes planning around it possible.
i3solutions is a Microsoft Partner with 30 years of delivery experience and 1,500+ Microsoft engagements, with every engagement staffed by an all-senior, all US-based delivery team. That profile fits this class of work, where the platform has to be built rather than configured and then has to keep running: a custom .NET application, SharePoint as the document repository, Azure as the host, a permission structure covering members from different organizations, and administrative functions for rosters and attendance. This engagement is representative of the pattern, including the part that comes after launch: JIRA bug tracking and release management with a one-day response time on tickets labeled as bugs. For organizations weighing similar work, a short scoping conversation establishes what the equivalent build would take in your environment.
More From i3solutions
Related Engagements
5,000 Users, a One-Day Bug Response Time
The support arrangement, JIRA-tracked, one-day response, was built into the deliverable rather than treated as an afterthought. We’re glad to discuss what a comparable support model would look like for your platform.
