Project Delivery Workflow

Products are the solutions we build for our customers, including Knack apps, AMANDA apps, custom software, and data systems. We improve and extend our products over time so that they deliver continuous value to Austin Transportation as business needs evolve.

Projects are time-boxed endeavors. They accomplish a singular goal and have a defined completion date. Examples include:

• Recommending an off-the-shelf externally-supported solution

• Delivering the first iteration (MVP) of a new DTS product

• Building a major feature for an existing DTS project

• Refactoring a dataset

• Delivering a complex map

Project Initiation

Oftentimes, our customers initiate a project by submitting a DTS service request that is notably large and/or important.

A DTS team member may also create a project when there is significant work to be done on an internal product—such as updating Austinmobility.io, a technical refactor of the Vision Zero Database, or migrating our CCTV image service from a local server to the cloud.

In either case, we begin by verifying that all our DTS project prerequisites are met:

• Dedicated product owner to support requirements gathering, user research, and user onboarding

• Division Manager sponsor to champion the project at the executive level

• A commitment from the customer to collaborate in DTS's iterative, user-centered development process

Then either create a new project index issue or convert the existing issue to match the project index template. Either way, make sure that the 'Project Index' label is on the issue so that an evaluation record for the project is added to the DTS Portal and it appears on the website.

Don't worry about building out a robust project index before scoping the request. Just make sure the name and description (the first 1-2 sentences) are good and that it has all the right labels. You can comment out the rest of the template to fill out when you have more information.

Move the issue to the "Needs Scoping" Zenhub pipeline.

Scoping

• PM schedules an intake meeting. Ideally, this will include actual users as well as the workgroup manager.

• Prepare Intake Meeting Agenda.

• Meet and take notes; photos/recording may also be helpful.

• Add notes/photos/recording to Github issue.

• If necessary, update issue description to ensure it clearly summarizes request.

Builder Huddle

• PM sets up meeting with potential builders, e.g. Dev for a Vision Zero Viewer project, Apps for a ROW Portal project. If we aren't sure which route we'll go or the solution will require both, add to the Dev/Product Sync agenda to discuss.

• Prepare a summary of request. Here's an example done as a presentation deck (template).

• At the meeting, discuss the recommended approach and fill out the "Effort" section of the project evaluation in the DTS Portal.

Sometimes we realize that the request isn't actually project-sized during the intake meeting or the builder huddle. No worries, we had a good opportunity to learn more about our customers' work. Might make sense to organize this work as an epic, once the time comes.

Product Sync

After assessing effort with the builders, it's time to assess value with the product team.

• Add to DTS Product Sync agenda for a "Refinement-week", i.e. the second Wednesday in a sprint. If feedback is needed sooner, or the project was initiated internally (like work on our technical infrastructure), bring it to Dev + Product Sync instead.

• As a group, fill out the "Value" section of the project evaluation in the DTS Portal.

After the evaluation is complete, the Austinmobility.io script will pick them up and you will be able to see the project in relation to other projects in our backlog using the prioritization matrix.

Move the index issue into the "Backlog" pipeline.

Prioritization

Project Prioritization Process as of 5/24

Google presentation used for Product Ops onboarding and TPW Executive communications.

Working docs

• Project Prioritization workflow

• DTS + OPM workflow

Activation

Once the time comes to work on the project:

• Move the issue to the "In Progress" pipeline.

• If you don't already have regular Sprint Reviews with the project's stakeholders, set up recurring meetings for the duration of the project so that you can demo work and get feedback.

• Create a folder in the Projects/Products DTS Drive.

• Create a Project: label in Github. Fill out the "Description" field and use the hex code #3D3D3D for "Color." Use this label for all issues moving forward so that they render on the projects' website page and are easy to surface on Zenhub/Github.

• Fill out the rest of the project index including background, outcomes, timeline, etc. Add these headings to the issue:

## Scope & Deliverables

What are we delivering? What’s in scope, and what isn’t? Describe constraints you’re working with, e.g. “Can’t impact **\_**‘s workflow,” known roadblocks.

## Desired Outcomes

Impact this project can have, success metrics

## Timebox

How long should this take to build; optional section w/ caveats for more complex projects.

## References
- Google Drive link 

• Convert the project index issue into an epic and assign future issues to the epic moving forward. Zenhub allows you to nest epics or assign issues to multiple epics, so feel free to use that functionality if you find it helpful.

• Ensure that everyone who has stake in the project, from potentially impacted staff to interested executives, is aware the project is moving forward. Invite stakeholders to come to sprint reviews and/or participate in user research. Ask them who else should be included.

• Optionally, hold a kick-off meeting with your stakeholders.

Delivery

• Perform requirements gathering with users. We often begin with user interviews and store requirements either as user stories for in-house applications or in a software comparison matrix for off-the-shelf solutions.

• Document bugs, feature requests, and enhancements as Github issues. You may want to encourage your users to contribute using the DTS Service Request.

When you click the "New Issue" button in the upper righthand corner of most pages in Github, you'll find issue templates for bug reports, features, and enhancements. You have to scroll to the bottom of the page and click to the "Open a blank issue" link to get a plain issue. To skip all that, bookmark the direct link to the blank issue form and add it to your browser bar.

• Work with the team lead—via Github comments or in a planning/refinement/sync meeting—to assign an estimate to each issue. Zenhub's Planning Poker is also a fun way to estimate asynchronously.

• Bring complex issues to Backlog Refinement (Apps | Dev) to discuss with builders. Break them up into smaller issues as necessary, document the agreed-upon approach, and align on an estimate.

• Prioritize work with stakeholders during Sprint Reviews.

• If practical, release versions of an application on a regular basis.

• Perform usability testing to surface improvements to the user experience. Since we don't have dedicated user researchers at DTS, we love think-aloud usability testing for its simplicity and depth of insight. Here are some think-aloud test plans we've done. It's handy to record sessions on Teams so that you can expand on your notes, embed screenshots/clips in issues, etc.

Completion

A project is considered complete when the minimum viable product—captured in the "Scope and Deliverables" section of the issue's project index—is delivered to users.

For complex projects, you might consider making an "Onboarding and Stabilization" epic in the project to capture any critical bugs documentation needs that surface during roll out and keeping the project open until those issues are addressed.

• Often, there are still issues in the backlog that are not actually must-haves. Remove the project label, remove them from the epic, and review them the next time you meet with stakeholders so they can prioritize those against any of their other ongoing requests.

• Retire the project label by adding "[Archive]" to the "Description" field and update the hex code to #B8B8B7.

• Write a final update as a comment on the index issue and close the issue.

• By default, completed projects show on "Complete" tab on the “Projects" page of the website, but you can apply the Archived Project label to prevent that. We like to curate this page to showcase our most compelling, impactful, and well-documented work.