Transforming the pain of Spreadsheets into a Commercial SaaS Market Solution

The journey towards the HELM SaaS platform saw the following major steps:

Building the SaaS Platform

The launch of the HELM SaaS platform followed our proven process:

a.    Orientation

Orientation started early between the University of Montana pilot and the development of the UI mockup.  The periodic meetings that took place during that time allowed us to understand Helm’s needs, determine how we can help and establish the scope of work.

b.    Discovery

Once Helm completed the UI mockup, we collaboratively worked towards the following:

• Document desired processes:  The interactive mockup provided most of these and gave us the platform to seek clarity as needed.
• List & prioritize milestones, user stories & requirements (backlog):  We use a Requirements Traceability Matrix (RTM) to clearly identify requirements and user stories at the intersection of:
  • User Roles, i.e. System Administrator, School administrator, School User, Read Only User.
  • Sections, i.e. System (includes configuration, database, security, etc.), School Administration, School UI, Reporting.
  • Features, i.e. Expense, Revenue, Tickets, Travel, Recruiting, Payroll, Reporting, System, Other.
• From the RTM above, we start breaking down the project into segments that are achievable within weeks, laying down the roadmap toward an iterative process with clear milestones:
• 
• Initial planning, budgeting & risk assessment:  With the above analysis done, we were in a position to recommend a technology stack (.NET Core 6.0, Azure SQL Database, jQuery, Bootstrap hosted on Azure) and provide an initial 3-point estimate and duration towards the MVP, along with possible risks that could affect the project and drive priorities towards a rapid mitigation.

c.    Project Kick-Off

• Determine team & allocation:  A team consisting of the following roles:
  • Project Management to manage processes that drive adherence to time, cost and scope.
  • System Analyst to ensure that requirements are identified and documented, see RTM below.
  • Development to write the code and build the application.
  • Azure Cloud Specialist to setup and configure the Azure Cloud environment to host the application.
• Establish Plan & Budget:  Finalized the scope, RTM and milestones for this phase of the project, migrating its content to our project management tool.  A project plan and Gantt chart were drafted based on the assigned team and allocation:
• 
• Establish Communication plan:  A communication plan was established to ensure effective and regular communication / review during the life of the project.  Supporting online tools were enacted to make it easy to share information with all involved.

d.    Agile Iterative Releases

• Sprint Planning

1. 1. • Review top priorities:  In this step, we made sure that the top of our backlog included the most important and also the most risky user stories and requirements to tackle next.
      • Breakdown tasks for next 1-4 weeks:  The team took the above priority stories and requirements and broke them down into individual tasks until enough work was identified for the upcoming 1 to 4 week sprint.
      • Update Project Plan:  If the above planning or subsequent deliverable resulted in a time or scope change, the project plan was updated accordingly.

• Sprint

1. 1. • Execute Sprint tasks:  The tasks identified during sprint planning were executed, tested and documented so as to provide guidance for further review or questions.
      • Daily scrum meetings:  The team met briefly daily to review what was done, what will be worked on and any blockers or impediments to hitting the Sprint goals.  Breakout sessions would occur as needed to discuss ways to address blockers or impediments.
      • Weekly client meeting & reporting:  A weekly meeting gave us a chance to report on progress, blockers or impediments.  It also provided an opportunity to review outstanding questions or feedback that we were not able to address via email.  A weekly status report was also sent to ensure we had written documentation.

• Demo

1. • Demo / Deploy Sprint Deliverables:  At the outset of a Sprint, we deployed our changes to the Azure cloud hosting environment to provide a hands-on approach to reviewing the changes made, aka User Acceptance Testing (UAT).
   • Client sign-off:  We captured UAT feedback and prioritized resulting changes in subsequent sprints.
   • Retrospective:  Internal retrospective meetings took place to review, document and encourage what we did well and what we can do better (look for some of these in the “Summing Up section”), setting the stage for more efficient subsequent sprints.

e.    Project Closeout

• Final handoff of deliverables, source, documentation, etc.:  Once all stories and requirements were signed off on, we planned and executed a go-live of the SaaS web application.  Source and documentation had been available to the client all along through the project management tool and the source code repository.
• Start Support & Maintenance:  We worked with Helm to determine and enact the most appropriate support and maintenance plan to suit their needs, addressing security, turnaround time and frequency of subsequent changes.  See next section.
• Discuss next steps / project:  Jointly reviewed the remaining user stories and requirements from the product backlog and discussed if and when to tackle them.  The backlog was then updated and future touch points were established accordingly.

Delivering trusted assurance through the AXIOM Wellness Check plan

Immediately after going live with the new SaaS platform, the AXIOM team created a duplicate staging environment.  This type of environment becomes essential to the support and maintenance of the SaaS solution, allowing review, testing and troubleshooting without interfering with the production environment.

Based on an initial low anticipated usage of the platform, a monthly maintenance plan and schedule was enacted to regularly assess:

During the first weeks, a performance issue was uncovered:  The desired calculations summarizing all expenses and revenues required queries that reached up to 75% of the tables in the database. Special optimizations and refactoring had to be done to ensure acceptable page load times.  We were able to scale up the Azure Cloud Hosting environment while we optimized the underlying database query.

After resolving this issue, the platform performed well and maintenance costs have been under the industry average of 15-20% of the initial development cost.

The Finished Product: Complete Budget Management Solution for University Athletics 

Benefits

Sample Screens

Add New Trip

Budget Summary

Travel Budget Summary

Architecture

The architecture follows a Model-View-Controller (MVC) implementation leveraging .NET Core hosted on the Azure Cloud Infrastructure, allowing Helm to securely serve its customers through growth and peak times.

Helm SaaS MVC architecture hosted on Azure.
Original image from Xinfe, initial work by Deltacen, licensed via CC BY-SA 3.0

The Future is Bright for HELM

Helm now provides a robust and reliable platform for university athletic departments across the nation.  The project was on budget and on-time, fitting within industry average for a medium-sized SaaS development project (4-6 months, $70,000-$100,000 ).

Some differences between the mockup and actual requirements were uncovered during testing, which is expected in software development projects as it is nearly impossible to envision all cases up-front.  

Our Agile-based proven process, coupled with strong change management, is well suited to handle such changes, but most importantly, the work invested up-front by Helm in developing the vision for the product using a mockup was paramount.  It reduced the number of unanticipated changes and therefore eliminated friction around cost and timeline.

Furthermore, Helm’s involvement during the development process was reliable, with strong communication, which had a direct positive impact on the quality of the resulting system.

With the platform now up, Helm can focus on marketing it while retaining our expertise for support or enhancements as needed, therefore controlling their costs.

Want to SaaS-ify your spreadsheets?

Almost one in four companies prefer to choose software development outsourcing services for their projects. 

The primary reason is to reduce cost, flexibility, faster market time, and a vast pool of talent.  On the other hand, satisfaction levels for outsourced development remain relatively low, with only 17.8% of companies reporting absolute satisfaction with the work delivered.  So if your organization is looking to outsource, make sure you pick the right partner for your organization.

The Helm project exemplifies custom web applications developed and maintained by our group, and the synergy between client and vendor needed for a successful delivery.  We embrace and emphasize certain distinguishing factors designed to ensure a quality outcome for each and every client and project:

•     We are disciplined and organized about work and communication
•     We treat clients as partners
•     We offer solutions, not just programming

We believe it is important for our respective organizations to recognize and value the above tenants in order to develop a successful product and have fun along the way.  So we have found out that we are not a good fit for organizations that are:

•     Not willing to engage in regular meetings with us.
•     Not willing to invest the time to clarify and validate requirements.
•     Not willing to recognize scope changes.
•     Looking for the cheapest programming services available.