When the Federal Highway Administration released this grant opportunity, they limited the scope of work in the proposal to less than one page. With such a big undertaking, we knew that our first order of business after getting the contracting in place would be to update the workplan with enough detail so that everybody was on the same page, but enough freedom to allow for innovation along the way.

While you can read the whole workplan, I thought it would be interesting to highlight a few interesting (from our perspective) components.

Tasks led by agency staff

Agency staff are task-leaders and managers. Not only are those who are closest to the problem most likely closest to the solution, but agency staff are more likely to develop solutions that work best in the public agency environment and workflow. We are lucky to have a strong cadre of innovative and motivated staff working on this project, but just in case they need help being pointed in the right direction, they can ask for the help of the technical lead or others on the team.

Defined group decision-making process

Since we are a large group coming from different backgrounds and implementation environments, we thought it was important at the outset to define how we would make decisions as a team. The process we agreed on was as follows:

• Identify important decisions at the get-go and tag them (i.e. transit network data standard)
• Task-leader is responsible for educating and consulting with the technical team on relevant background research, the pros and cons of potential options, and a proposed direction.
• Once any concerns from the technical team are ironed out, send a revised proposal to the management team for approval

This process will help us:

• make a decision, move on, and live with it
• educate all the staff on background research and what is going on with different tasks
• make sure the solution works with each agency

Create tasks that can proceed in parallel with very defined points of coordination

The majority of the tasks were developed so that they could proceed pretty much in parallel with each other for the first year of the project in order to allow semi-independant work. This is important so that tasks do not hold each other up and allows for some schedule flexibility within the task.

However, there are points where the tasks intermix. For example, a data standard for transit networks (Task 2) is needed in order to write the code that reads it in (Task 6). We have tried to identify all key interaction points as major milestones that each task leader needs to meet, but gave them flexibility with respect to intra-milestone-dates.

Overall Project Schedule with Major Milestones

Source: MTC, PSRC, & SFCTA

Schedule that is loose overall and specific in near term

The overall schedule is defined by the set of major milestones discussed above. It was also key that task-leaders endorsed this timeline and we spent a fair amount of time juggling the dates and staff resources so that they could be achievable…which means that we can hold staff accountable for not meeting them.

We chose not to overthink the details of the schedule that are occurring many months away since we anticipate so much changing and evolving as we learned what we had on our hands. However, for day-to-day scheduling and coordination of things on-deck, we chose to use the online tool Asana ( which may be the topic of a future post )

Asana Online Management Tool

Source: MTC, PSRC, & SFCTA

Don’t over-engineer the solution when you aren’t sure it is the solution…yet

We recognized that there are a lot of unknowns with this project and we didn’t pretend that we had the silver bullet at the outset. Therefore, we had to be careful to factor in time and resources throughout the process to assess what the best option was for proceeding.

Coordinate with academic educators

We chose to work with the University of Texas at Austin’s Network Modeling Center because they both develop and use the Fast-Trips software, and have several staff committed to developing tools to educate university students about travel modeling. By bringing them along in the process, we have engaged the vast majority of “other users” of Fast-Trips, can benefit from their experience in developing and using these tools, can help them learn about a diversity of “on the ground” needs, and can support them in developing academic teaching materials on this topic.

This is what we are staring with, but we are sure it is not perfect and are eager to continue learning. What have others found useful when dealing with large collaborative projects with ambiguous paths to get to a solution?