An analysis of collaborative problem-solving mechanisms in sponsored projects: Applying the 5-day sprint model.

Author:Raubenolt, Amy
Position:Report - Abstract
 
FREE EXCERPT

Abstract: In May 2016, the office of Finance and Sponsored Projects at The Research Institute at Nationwide Children's Hospital conducted a 5-day design sprint session to re-evaluate and redesign a flawed final reporting process within the department. The department sprint was modeled after the design sprint sessions that occur routinely in software development and manufacturing processes fields. The Research Performance Progress Report (RPPR) process was not consistent among all Sponsored Project Officers (SPOs), and the department needed to develop and implement quality control measures to safeguard compliance and assure quality in the reporting process. This study in adapting a software design process for use in sponsored projects assesses how this problem-solving mechanism can be utilized with success to replace the formal workgroup model and improve the research administration enterprise. Findings illustrate that several factors influence the success of the sprint application to research administration, including increased time spent dedicated to the problem and a gained shared understanding of the problem and possible solutions. Finally, findings indicate a strong preference for the individual problem-solving technique inherent in the sprint model in combination with the intense and deadline-driven collaboration mechanism.

Keywords: sprint, agile methods, efficiency, work group, teams, organizational science, sponsored projects management, RPPR report, collaboration, problem-solving

Introduction

Sprint design sessions are routinely employed by Google Ventures and at numerous other software companies both nationally and internationally (Knapp, Zeratsky, & Kowitz, 2016). The sprint model puts key members of the team in a room with a Decider and a Facilitator for six hours a day for five days to solve a problem, design a product, or develop a solution. Sprint team participants are forbidden from using cell phones or other technology while participating in the sprint session. By putting all stakeholders in a room, the sprint experience forces team members to commit to making progress, helps teams move abstract ideas and hunches into concrete action, keeps teams focused on what's important, and encourages prompt decision-making and follow-up (Knapp, Sprint, 2016). The sprint also often makes use of a "scrum master," whose job is to remind the team, via use of a bell or other sound device, when the team veers off-topic or begins developing solutions or ideas that may be valuable but are not applicable to the specific sprint goal. The sprint team must understand, map, develop, and test a working prototype in one week. A one-week deadline motivates sprint teams to produce quickly and efficiently.

Sprints are common in the development of websites, apps, and other software. Google Venture has also introduced the sprint model to manufacturing processes and seen successes emerge from its application in that field as well. The challenge in applying the sprint to sponsored projects is that research administration rarely develops a product or a single-user experience. Processes are multi-layered, over the span of a year or more, involve many players contributing to grant management, and must often be nimble and adaptable to changes in regulation or law. To meet the needs of research administration, the sprint concept would need to be modified to generate an improved process.

Current Problem-solving Mechanisms

Effective teamwork is key in research administration, and in all organizations. The Harvard Business Review published a study in 2016 that found that "the time spent by managers and employees in collaborative activities has ballooned by 50 percent or more" (Cross, 2016). The challenge is to make the most of these collaborative experiences. Sponsored Project offices typically employ long-term workgroups or committees. In these collaborative environments, team members meet for an hour each month or twice a month to analyze a process, project, or department need and to make recommendations for improvement and implementation. The workgroups use brain-storming, mapping, group discussion, and critical questioning to move towards recommendations and create deliverable materials that illustrate process changes or provide training. A variety of individuals with diverse roles appear as contributors on department committees. Workgroup duration commonly varies between several months to several years, with participation fluctuating with staff turnover and committee burn-out. The workgroup model of problem-solving has flaws. Progress towards solutions is slow, individuals miss meetings and lose motivation to contribute, staff turnover challenges process towards achieving goals, outspoken individuals in brainstorming sessions tend to drive progress in a single direction, schedules grow increasingly clogged by meetings, and department morale flags. Teams spend a long time on critical tasks, leading the project to fall behind, and can struggle to complete tasks and achieve their goals (Kisielnicki, 2016).

Additionally, work groups strive to produce a final product or recommendation and do not experience critical iterative design sequences. These final products occur at the end of a work group's convened effort. Redesign of those end products is slow and cumbersome since the time it takes to convene the work group, gather feedback on needed revisions, and collaborate on a new design stretches over weeks or months, sometimes years. Finally, the larger the work group size, the more prone its team members are to decreased individual effort towards accomplishment of the group's goal (Latane, 1979). Devine suggests "a great deal of time, effort, and perhaps money is spent in creating teams, but little is done for them once they are in place."

However, factors impacting team effectiveness are contingent on the team's context (Devine, 1999). Devine finds that organizations boast a variety of team types: management teams, autonomous work groups, semiautonomous work groups, and project teams. The sponsored projects department tends to rely on semiautonomous work groups, defined as a group of diverse co-workers tasked with a goal or problem to solve and that reports their recommendations to management. This problem-solving model assumes that problems are well defined, processes can be optimized, and results can be predicted (Devi, 2013). The sprint model is an ad hoc project team, as defined by Devine, responsible for developing a specific project in a specified duration, tasked with being adaptive, collaborative, and in employing design iterations.

Outside of the workgroup model, staff members choose to solve problems on their own and present possible solutions to managers, collaborate with each other on solutions via email communication, or discuss problems and possible solutions during department meetings. The workgroup model is the standard problem-solving mechanism endorsed by the sponsored projects department at The Research Institute at Nationwide Children's Hospital.

Rapid-response

Google Venture's 5-day sprint accelerates a team's understanding of the problem at hand and engenders in team members shared understanding of complexity and possible solutions. The sprint model offers an additional advantage in that it is a rapid-response solution team, capable of gathering feedback on a prototype and redesigning in real-time to meet the deadline. Sprints are commonly one piece of the Agile methodology in which projects are managed progressively, with iterations over time. These rapid-response iterations quickly incorporate feedback and redesign a product to eliminate unsuccessful product elements (Kisielnicki, 2016). The Sponsored Projects sprint encouraged iterative design in both the sketching and prototyping days. Iterative design elements are new and offer a potentially valuable alternative to the traditionally linear problem-solving methods evidenced in workgroups.

Rethinking RPPR Submission

In 2014, the National Institute of Health began requiring institutions to submit a Research Performance Progress Report (RPPR) for all annual, type 5 noncompeting NIH awards (National Institute of Health [NIH], 2014). In the RPPR, "recipients describe scientific progress, identify significant changes, report on personnel, and describe plans for the subsequent budget period or year." It is essential to be accurate and timely in working with principal investigators to complete and submit RPPRs.

From 2015-2016, the Sponsored Project Officer team replaced two of its four members and increased the team by an additional two new positions, growing the dedicated SPO team from four to six, including the transition of one SPO to SPO Manager. Consequenrly, two-thirds of the team was new to submitting RPPRs. The significant staffing changes, in combination with the implementation of the RPPR requirement, resulted in inconsistent submission and a lack of understanding among the SPO team members as to what was truly required on the report, whose role it was to collect and enter different pieces of the report, and how best to organize and communicate regarding the RPPR submission and due date. The director reported significant variation in the information he reviewed in the RPPRs submitted by the SPO team. These inconsistencies and errors required the institution's signing official to return to the SPO at submission to gain complete information on publications, inventions...

To continue reading

FREE SIGN UP