SD2C Project Workflow
Workflow document describing how to get started on a SD2C project, how the software development cycle works, and how PIs/clients/partners can provide feedback.
- Initial Consultation
- Quote Creation
- Quote Modification
- Quote Approval
- Work Authorization
- Project Work Initialization
- Project Work Modification
- Project Work Completed
- Post Project Survey
Initial Consultation
Initial Contact
To begin a project, clients/partners/PIs should:
1. First, email the SD2C at sd2c@cores.utah.edu
2. Next, fill out the SD2C Project Request Form via Google Forms.
Note: Make sure to be as detailed as possible when filling out the SD2C Project Google Form. This gives SD2C the necessary information (scope, budget, timeline) for a proper quote.
3. The SD2C Director will contact you to discuss possible options and schedule a meeting.
Initial Meeting
An initial meeting will be scheduled between the SD2C and clients/partners/PIs.
This meeting will include discussions about:
1. Project Objective - overall goal of the project
2. Project Scope - breadth of features to be implemented for this project
3. Possible Project Techstack - technologies used in design, development, deployment of project
4. Project Budget - both secured and unsecured funds for the project
5. Project Timeline - amount to time dedicated to working on the project
6. Project Staffing - which employees will be assigned to this project
7. Project Strategy - amount of task granulation needed
Note: Depending on the scope of the project and interest, 1-2 complimentary meetings may be scheduled over the course of the initial consultation. Past the initial meetings, unless requested by the SD2C Director, consultation fees will be charged for additional meetings if the project is accepted by the SD2C.
Quote Creation
Rough Quote Drafting
Following the initial meetings with the stakeholders, the SD2C Director will meet with the assigned staff to draft a quote.
The SD2C Director and assigned staff member will set a time to draft an initial quote for the project. Here, they will discuss the design cycle, development strategy, and deployment time for the technologies.
Note: This Project quote will be drafted based on line item costs as shown on the SD2C Services Site. This is typically quoted to match timeline, budget, and scope of project. Since the SD2C only charges for hours worked, the final amount may vary from this quote.
Rough Quote Meeting
Next, a meeting will take place between stakeholders to discuss the quote.
The quote is either
1. Accepted as-is
If the quote is accepted as-is, then it is ready to be drafted by the SD2C Director through the HSC Cores Resource Managment System.
2. Rejected
If the quote is rejected and not accepted with no refinement option, then the SD2C Director will place the project in Backlog and will not discuss it further with the client/partner/PI unless reapproached.
3. Questioned and Refined
If the quote is questioned and subject to refinement, the SD2C Director and clients/partners/PIs will discuss the line items in more detail or change the scope and timeline to better fit the budget. The SD2C Director will take these into account and schedule another meeting to perform a follow-up meeting to present the finalized quote.
Quote Refinement
The initial quote will undergo a complimentary refinement following the rough draft presentation to clients/partners/PIs. Any feedback is taken down as notes and relayed in a subsequent refinement quote.
Official Quote Drafting
Once a quote is accepted during the quote refinement meeting, it is then drafted on the HSC Cores Quote Management System.
Quote Modification
Quote Modification Parameters
If the quote needs to be modified following the drafting and acceptance of the quote, the clients/partners/PIs and SD2C Director will discuss modifications to the quote for an extra consulting session fee. See current rate sheet for consulting fees.
Modification of a drafted quote could occur if:
1. Official quote does not reflect the refined quote using the Excel Template that the SD2C provides.
2. Non-commital or more negotiation needed post-refinement and following quote drafting.
3. Misleading committal of funds towards prosposed projects.
4. Miscommunication on the SD2C's behalf, which would not count against the clients/partners/PIs as an extra consulting session fee.
Quote Approval
Quote Finalization and Approval
Once quote is finalized and all parties are satisfied, quote acceptance will occur through parties sent the official quote through the HSC Cores Systems.
Clients/Partners/PIs will be automatically be sent a link to sign from HSC Cores Scheduler and approve of a quote drafted by the SD2C.
Note: If you do not receive a quote, please contact the SD2C director for resending of a quote.
Note: If there is a problem with the quote, please email the director at sd2c@cores.utah.edu.
After all parties have signed, the approved quote will be placed in the SD2C Director's purview under the HSC Cores Quote Management tab of the Resource Management system.
The quote will be approved by the SD2C Director, barring any feedback from clients/partners/PIs.
Note: Please approve quote as soon as possible. Failure to approve a quote will cause a delay in starting work or may result in miscommunication of alloted funds.
Work Authorization
Work Authorization Submission
The HSC Cores Work Authorization System is the billing/invoice/quote management system that is unique to HSC Cores. It allows for those internal and external to the University of Utah to be invoiced for Core services. To learn more about how to use the Work Authorization System, see here.
In order to begin any work, the SD2C must have a work authorization form submitted and approved through the work authorization system. Failure to perform this step in a timely manner will delay development timeline for a project quoted through the SD2C.
If you have questions on completing the work authorization form, please contact one of the HSC Core Admininistration Staff and CC the SD2C Director.
Project Work Initialization
Work Initialization
Work Initialization
Work will be discussed within the SD2C.
It begins with a
- Design Box Session
- Work Assignment
- Lift Brainstorming
- Lift Creation
- Lift Assignment
Note: This is typical for a new project, but if the SD2C is inheriting a project from a former group, some of these steps may be skipped or rearranged.
Design Box
Design Box
Design box sessions are a used in game design for digital health games and apps. It is an interative, pedagogical approach to idea pitching which allows for participation by stakeholders of all types. It consists of 4 walls: the audience, the technology, the aesthetic, and question prior to pitching designs. It has been published across multiple journals and is a hallmark approach to software development in the game and app space.
What
The Design Box is an inductive design tool built around the notion that good design solves a problem. It focuses on ideation and iteration. It can be used to develop a pitch or to design features.
How
The Design Box asks teams to brainstorm the four walls of the box audience, technology, aesthetic, and question before pitching designs. It also uses the terms as general categories. It is useful to think of the categories as families of related requirements.
Design Box Walls
Audience
The audience is defined as the end user, the client, the vendor, the retailer, marketing; anyone who is a stakeholder and should be considered in the design.
Technology/Techstack
The technology or "techstack" is defined as the delivery platform, peripherals, available development hardware, software, and team skills, accessibility requirements considered in the design.
Aesthetic
The aesthetic is defined as what should the user feel as a result of the content? Art, sound, writing style, anything that affects the tone, mood, etc.
Question
The play or theoretical question is defined as the game mechanic, theory, or core question the end product, must answer.
Process
Using any brainstorming technique, the group should fill out all four walls, bulleted lists recommended. Some walls will be more ‘solid’ than others. When a team stalls it should move on to the next wall. As teams fill out walls they may realize there are design constraints they forgot to put on a previous wall. Teams are encouraged to go back to any wall. Once theoretical saturation occurs, that is the team has no more ideas to put on the wall it should move on to pitching designs.
Using the brainstorming technique the team prefers, members should pitch designs inside of the box. That is that each pitch should address all four walls before it is written inside the box. If a pitch doesn’t fit inside of the box then it should be talked about before including.
After filling the Design Box with pitches, stop. Before evaluating any of the pitches, see if any of them provide more clarity or indicate problems with the four walls. Refine the walls based on the pitches. Finally, erase the pitches and start the process all over again.
Eventually, the walls will become more “solid” and the box will become “smaller.” The pitches that work within the revised walls will be the ones that best solve the problem. This process can be repeated as many times as necessary to arrive at a clear pitch that the team supports. It may be useful to revisit the Design Box as a tool later to clarify a feature of the product or to review if the pitch still makes sense.
Note: Not all software will need to employ a design box session, but it will drastically help with scoping a project and allowing budget and timeline to follow as well.
Figure 1. Design box walls for initial game/app design
References
1. Altizer, Roger & Zagal, Jose & Johnson, Erin & Wong, Bob & Anderson, Rebecca & Botkin, Jeffrey & Rothwell, Erin. (2017). Design Box Case Study: Facilitating Interdisciplinary Collaboration and Participatory Design in Game Developm. 405-412. 10.1145/3130859.3131333.
2. Desselle, Mathilde, Holland, Lucy, McKittrick, Andrea, Altizer Jr, Roger, Gray, Paul, & Brown, Jason (2020) Augmenting the design box: Virtual reality pain relief for Australian burns survivors case study. In SeGAH 2020 : IEEE 8th International Conference on Serious Games and Applications for Health, 2020-08-12 - 2020-08-14, Fully Online Conference
Lift Creation and Assignment
Following a design box session, SD2C will create large, medium, and small lifts with as much granulation as possible included. These lifts are assigned to stakeholders which will be dictated by the lead developer on the project.
Lifts
Lifts are tasks that will require differing amounts of effort to get them accomplished. They can be segregated into large, medium, and small lifts.
Large Lifts
Large Lifts are defined as tasks that require multiple well-coordinated personnel and an extended timeline to accomplish, typically longer than a week. These are also usually a large part of the budget due to hours involved.
Medium Lifts
Medium Lifts are defined as tasks that require one to two personnel and 3 days to a week timeline to accomplish. These are also usually a medium part of the budget due to hours involved.
Small Lifts
Small Lifts are defined as tasks that require one personnel and <3 days to accomplish. These are also usually a small part of the budget due to hours involved.
Assignment
Following a design box session, SD2C personnel will be assigned tasks for accomplishing. If multiple engineers are on the project, the lead developer for the project will assign tasks based on their best understanding of the SD2C staff's skillset.
SD2C Kanboard Invite
For project management, the SD2C uses Kanboard.
Each team member assigned to the project works on tasks given by the Project Manager of the Kanboard. Collaborators can be added as a project member or project manager. We recommend referring to the docs for Kanboard techstack and operation.
If you need access to the project Kanboard, please email the director at sd2c@cores.utah.edu and specify the project(s) you are on.
Project Work Modification
Project Development Feedback
Feedback is welcomed and encouraged from stakeholders throughout development. This helps shape the final product to be intended for what is expected from PIs/partners/clients.
Project development feedback will take place in partner-defined, stakeholder meetings. Partners are asked to give honest, thorough, and well-defined feedback that fits to the scope, timeline, and budget of the project.
PI/Client/Partner Feedback Meetings
Typically partner meetings are bi-weekly to give feedback throughout the semester. However this can be defined as the partner/client/PI sees fit.
Note: Meetings will be charged as a "Consultation" fee, therefore we recommend that PIs/Clients/Partners be aware of these charges before scheduling constant meetings without objectives outlined.
Meeting Structure
PI/Client Feedback Meetings are structured as:
- Deliverables from previous meeting Goals/Objectives stated from prior meeting.
- Lifts accomplished - Typically medium to large lifts that have been marked as completed since last meeting date.
- Fires - Problems encountered during the development process.
- Upcoming Objectives - Future goals that are to be worked on and set forward as assigned lifts.
Feedback
Feedback is encouraged throughout the presentation and should be brought up by stakeholders when appropriate. For example, if there's an easier way to accomplish a lift it is the responsibility of parties knowledgable to let it be known to stakeholders so it can be accomplished in a friendlier fashion.
If any PI/Client/Partner has feedback on the development cycle, please reach out to the SD2C director at sd2c@cores.utah.edu
Team Meetings
Meeting Types
Developer Meetings, consist of Monday, Wendesday, and Friday Standups and Wrapups.
Management meetings are weekly on Wednesday between the director and lead developers.
Directorate meetings are done biweekly, between Cores Director, GApp Lab Director, and SD2C Director.
Developer Standups
Daily developer standups are held with SD2C lead developers and GApp Lab interns each MWF morning. During these meetings developers and interns discuss focused, daily tasks for the project they are assigned to and their approach.
Developer Wrapups
Daily developer wrapups are held with SD2C lead developers and GApp Lab interns each MWF afternooin. During these meetings developers and interns discuss their approach, progress, and issues found during their work on the assigned tasks at the Standup meetings.
Weekly Management Meetings
Weekly managerment meetings consist of the director and lead developers discussing project issues, solutions, budget, and timeline.
Directorate Meetings
Directorate meetings are held between the SD2C Director, HSC Cores Director, and The GApp Lab Director. These meetings aim to discuss more immediate needs of the core; such as project and budget needs. Additional strategic meetings are performed quarterly with the SD2C Steering Committee, which consists of University of Utah faculty with and without projects active in SD2C and the SD2C Director.
Project Work Completed
Wrap-up and Handoff Meetings
When the project is close to completion or needs to be transferred out of the SD2C, the director will schedule a Wrap-up and Handoff meeting with PIs/clients/partners and the developers assigned to the project.
Meeting Structure
Wrap-up and Handoff Meetings follow a strucutred format of:
- Deliverables addressed
- Demo reel of end-product
- Codebase source and destination for code to be moved to
- Code documentation
- Pending final charges for project to PI/client/partner's account
Feedback should still be provided by PIs/clients/partners after final wrap-up and handoff meetings. Please provide feedback to the SD2C Core Director at sd2c@cores.utah.edu.
Wrap-up and Handoff Meetings will still happen on projects with GApp Lab student interns present across semesters.
Post Project Survey
Post Project Survey
A survey will be sent out by the SD2C and HSC Cores asking PIs/Clients/Partners how the SD2C performed in their duties as a core facility. It is highly recommended that interested parties fill out these as it helps gather feedback for furthering the direction of the SD2C.