Project Management Tool for Georgia Department of Transportation

Designed the first version of a project management and analysis tool to support a new process change at Georgia Department of Transportation (GDOT).

Overview

Bigger Business Problem and Background

There were several research projects being carried out at GDOT but implementation for these projects was not systematically tracked. Nor was there any process in place to measure specific outcomes of this implementation. The Civil Engineering researchers I worked with on this project designed a new process that GDOT can adopt to track implementation, measure outcomes, and analyze outcome data to make informed decisions within the organization. The tool I designed was meant to support this new process change.

My Role

  • Ran collaborative brainstorming sessions to outline features and flows
  • Prototyped and evolved those ideas as wireframes
  • Learned MS Access and created this tool in MS Access
  • Helped the team think about this new process change from a user-centered perspective

Other members on the team

  • Product Manager (Civil Engineering Professor)
  • Civil Engineering Researcher
  • Manager from GDOT (Primary user)

Outcome

Delivered a ready-to-use project management tool that could be used to pilot the new process in the organization and serve as a minimum viable prototype for a bigger stand-alone custom tool in the future.

Process

Literature review

Understood the proposed research implementation process

The new implementation definition and tracking process, that was defined by the Civil Engineering researchers, served as the starting point for my part of the project. I read the report detailing their recommendations, and also read the documentation around the current work process at GDOT.


Content and feature ideas

Sketched ideas based on discussion in early meetings


User Flows

Collaboratively defined user roles and application flows and features

I had ideas of what units of information would go into the tool but did not understand how they would fit in the user's task flow. So I conducted a brainstorming workshop with other team members, who were subject matter experts, to define the user roles, tasks, and corresponding application flows. Going through this process also helped them look at the process from a user-centered perspective and identify details they hadn't thought of before.


Wireframing

Documented and developed the design ideas in Axure

From the task flows and feature requirements, that we identified during the brainstorm, I created an Axure prototype. Some important features included visual division of the form into digestible chunks, ability to save the form without filling it entirely, ability to check project deliverables completed, and ability to track project completion over time.


Change of plan: Develop the tool in MS Access

Due to an unexpected change midway in the project, the technical constraints significantly increased. A custom tool could not be developed anymore. So we decided to create a minimum viable version of the tool in MS Access. MS Access was chosen as the software of choice against other options because it was already being used in the organization, it had features to create database tables paired with form UI and multiple data represenations with filters, and it allowed for multi-user capabilities over a shared network.


Interactive Prototyping

Prioritised features and developed the tool in Access

Since the back-end data for this application was not yet available, the most important task was to add the data. So the first thing I create in Access were the forms. The long form was divided into meaningful groups represented as tabs. The form input field length was set according to the corresponding data length entered. Also, I set the appropriate tab order and data validation checks.

I created two other pages: one to track project progress, and the other to show the list of all projects. No other features could be developed because of time constraints and because I did not have enough skills in Access and Visual Basic.


Think aloud Testing

Tested the Access prototype with 2 users

Twice during the development process, I tested this prototype using the think-aloud method. The participants were the primary user (also the client) and one of the Civil Engineering researchers, who served as a proxy for the secondary user. Based on that feedback, I made some tweaks along the way. Those are included in the design shown above.