Project Name:
Development of a Prototype for the Standard Application Process Portal
Contractor: Scientific Research Corp.
Lessons Learned
Regular communications have been a key to fully understand requirements, stakeholder priorities, and potential issues as early as possible.
- A suggestion for Government user access to provide input for the system has been completed and resulted in specific suggestions to be implemented and provide overall improvements to the user experience. The positive experience is worth continuing and will be leveraged more formally for reviewer feedback testing later.
Comments on Lessons Learned
During the development process, the SRC and NSF teams have conducted weekly collaboration meetings to review status, demonstrate features, discuss changes, and obtain detailed information to support the development effort. The Lessons Learned listed in this document are based on SRC’s development and comments made during the weekly collaboration meetings. Additional lessons learned may be provided by the Government stakeholders based on their perspective.
1.1 Collaboration Meetings: Weekly collaboration meetings have been a key to fully understand requirements, stakeholder priorities, and potential issues as early as possible. Regular meetings should be continued during the development
process.
1.2 Feature Demonstrations: Screen share using MS Teams has been used for meetings and to demonstrate features and items under development. The use of a screen share combined with discussions allows current status to be demonstrated efficiently and allows stakeholders to be involved in development decisions as early as possible.
1.3 User Feedback: After initial development was performed and some fields for user entry were created, Government users were allowed to access the system and provide feedback. This feedback was used to enhance the UI/UX and suggested changes were implemented. Using Government users to test the system should be continued to obtain feedback from outside the development and stakeholder team.
1.4 Development Process: The Salesforce tool used as a basis for the Standard Application Process lends itself to rapid configuration and prototyping. This allows weekly updates to be demonstrated that are functional without relying on a traditional software release development cycle. Rapid prototyping and continuous demonstrations should be continued.
1.5 Financial Reporting: Financial reports are provided on the 1st of each month. Due to the delay in processing timekeeping systems, actual information is not available until the 7th of each month. This causes financial reports for the 2nd half of each month to be estimates based on individual employees providing hours charged to the project. Because final information is not available until the 7th. The due date for financial reports, and possibly status reports should be scheduled for the 10th of each month following end of the reporting period.
- Weekly collaboration meetings have been a key to fully understand requirements, stakeholder priorities, and potential issues as early as possible. Regular meetings should be continued during the development process.
- The use of a screen share combined with discussions allows current status to be demonstrated efficiently and allows stakeholders to be involved in development decisions as early as possible.
- Using Government users to test the system should be continued to obtain feedback from outside the development and stakeholder team.
- The Salesforce tool used as a basis for the Standard Application Process lends itself to rapid configuration and prototyping. This allows weekly updates to be demonstrated that are functional without relying on a traditional software release development cycle. Rapid prototyping and continuous demonstrations should be continued.
- It is valuable to have a risk management or contingency line item to plan for changes or updates during the development effort.
- SRC chose the Salesforce database as the underlying tool for the Standard Application Process portal. A significant feature of Salesforce is the no-code/low-code capability to implement features. It is not uncommon for projects requiring software development to be over budget and delayed on schedule. A frequent cause is due to an insufficient understanding of requirements and underestimating the effort required to create custom software to meet requirements as they are being fully understood. The no-code/low-code capability allowed the SRC team to focus on configuration of the tool to meet specific requirements rather than requiring custom software development. This has led to the ability to rapidly adjust processes based on user feedback and with the expectation that a detailed understanding of requirements would lead to specific implementations. Overall, this has led to a flexible tool that has been adjusted for specific user requirements without requiring additional funding.
Disclaimer: America’s DataHub Consortium (ADC), a public-private partnership, implements research opportunities that support the strategic objectives of the National Center for Science and Engineering Statistics (NCSES) within the U.S. National Science Foundation (NSF). These results document research funded through ADC and is being shared to inform interested parties of ongoing activities and to encourage further discussion. Any opinions, findings, conclusions, or recommendations expressed above do not necessarily reflect the views of NCSES or NSF. Please send questions to ncsesweb@nsf.gov.
