Webinar Recap: Project Planning a Build App

This is a brief recap of our Webinar that was hosted with Annie Lovendahl from Vanderbilt University on 7/31/2023

Identifying the process you want to replace in Build

How do you identify which processes will work in Build?

Criteria

Form complexity

Impacts user experience – What kind of demands are you placing on the submitter? Weigh this against your audience.

Impacts production support – If something went wrong, how easy would it be for you to identify breakage points and troubleshoot? How about for a teammate to troubleshoot in your absence?

Workflow complexity

Has a significant impact on development and testing time, is often heavily influenced by form complexity – weigh these two together carefully

Also impacts production support – If you built it, you understand it, but the person who comes after you to take on support for this App needs to be able to follow it and identify breakage points.

Stakeholders in the process

How many people or parties need to be involved in reviewing and approving the development of this App? Beware of too many cooks in the kitchen.

Maintenance needs

Is the form or workflow going to contain information that needs to be updated periodically? How much and how often?

End users/Audience

Who will “own” the App when you’re done? What access rights do they need to the App and/or its documents? Do they want to export document data out of Build?

Many of our customers are looking for robust data reporting on submissions that we’re currently unable to provide, and they may not be able to effectively use the Documents spreadsheet export for their external processes. Be upfront about what exporting from Build looks like.

Who are your submitters?

How do you need to restrict access to submitting in this App?

Example: Office of Undergraduate Admissions needs student workers on their team to be able to submit an Admissions Data Access Request, but opening the form to all students means any student not an employee of OUA can submit.

Integration needs

Security and sensitivity of data in and data out

Who owns the data you want to integrate? What conditions might they have for allowing you to access this data?

Can you trust your end users and App owners to use this data responsibly?

PII or protected information: Kuali’s security protocols are robust, but always check with data owners and stakeholders—comply with institutional policies! 

Planning the Project

Demo project request form

Questions I ask myself when deciding if an app will make sense in Build

The Car Question: Does the customer want a functional vehicle to get from point A to point B? Do they want a Tesla with some bells and whistles? Or do they want a magical flying car?

Be a realist. I often encounter customers who have heard great things about Build, but haven’t seen it themselves, and they have extremely high expectations for the product.

Build can do many things, but you and your resources may not be able to make it all happen the way the customer envisions it. 

There may be parts of the process that are a good fit for Build, and some parts that may have to take place outside of Build. Is your customer willing to accept that, or will they accept nothing less than magic?

Using other tools to map out your process

Miro whiteboarding, flowchart diagramming

Project Management with Monday.com

Demo Kuali Build project board on Monday – Item Type Automation

Planning

Identified database objects needed

Milestone planning

Execution

Integrations

Form building

Workflow building

Other data structuring needs outside of Build

Launch

Reviewing App with major stakeholders for approval

Building Integrations

How do you figure out which integrations you need?

Risk of user error – Would errors in user-submitted data create problems for your workflow or business process? Is it safer to have that information retrieved from a trusted data source?

Quality of life: Is a requested integration necessary to maintain or improve on QOL for the business process and its users? Or is it a “nice to have” request?

Organize requested integrations or integration ideas into a matrix of difficulty x impact – identify the low-hanging fruit, high cost/low reward, and “Goldilocks” options

Building the App

Mapping Out Integrations

Understand your user experience first

What is the user going to do with this integration? Identify primary business case.

How will submitters encounter this integration on a form?

Identify and analyze data sources

Legibility of data

e.g., codes and abbreviations that may be legible to some audiences but not all

Identify your ID and label keys early

Does your ID key effectively distinguish one set of results from another?

Does your label key provide useful information to the user? How will they know they got the right results? For List integrations, does the label key provide enough information for users to distinguish between options?

Look for additional opportunities

In what ways could you manipulate the setup of the same integration to satisfy different business needs?

Example: Course Catalog Search integration manipulated to produce Independent Study-Eligible Course Search; Student Enrollments integration intended for Course Withdrawal manipulated for Computer Science grader application eligible classes

Hooking integrations together: Do you have integrations with related datasets? Can you use the output of an existing integration as the input for a new one?

Collaborating with developers

Summarize the business case for the integration

Refer to available documentation – Kuali endpoints & GraphQL

Provide visual examples, e.g. sample JSON, Excel table

Testing

Got a 200 response? Great! Now test in context—are you getting the response the user actually needs?

Build an App in STG—doesn’t have to be the whole product—but try to establish the context in which the end user will encounter this integration

Are you hooking up the outputs of one integration into another? Build them both into your test app!

Planning Groups in Form and Workflow

How can you categorize your different types of users (form submitters, workflow reviewers and approvers, document reviewers, admins, etc.)?

Find the “natural” divisions – e.g., school, academic department, business unit; faculty, staff, student, etc.

Workflow reviewer/approval groups and roles

Job title vs. process role

Creating a group role that corresponds to a job title makes it clear what business areas are stakeholders in a process, and can help clarify which roles need to be updated in the event of employee turnover

Creating a group role that corresponds to a role or responsibility for a specific business process makes it easy to find the role needs to be assigned to a particular workflow step, and it may clarify the function of different points in a business process

Originally published on Aug 3, 2023