eCapris integration | Review user research on funding analysis and circle back with Systems Development

[amenity]

• [x] Review @zappfyllc's Fund Tracking and Analysis research
• [x] Circle back with Cole, Liane, (and Chris McC?) to validate our intended eCapris integration approach

[amenity]

@johnclary @mateoclarke - Thinking I should set up a meeting with SD the week of 1/11. This will give us time to sync up with @zappfyllc and review his research next week.

[johnclary]

super helpful @zappfyllc!

I had completely forgotten about rolling needs assessments, which is fundamental to Moped's value proposition.

For v1.0, i think we should continue to target a very limited eCapris integration that allows us to tie capital projects to their e-Capris project/sub-project. Functionally, that would mean storing eCapris subproject and project IDs in Moped, and allowing users to pick those when creating a project. It would be ideal if we also populated the project name and description automatically when a user selects an eCapris subproject ID.

Longer term I'm not sure what to do about eCapris. The purpose of eCapris is to enable financial planning and management of capital projects, and yet we have an entire universe of non-capital projects which don't live in eCapris, but have the same financial planning needs.

If one of our goals with Moped is to be able to produce a birds-eye view of budgets and unmet needs of our entire portfolio of projects (capital-funded or not), then we're going to have build some functionality that already exists in eCapris. (I assume this is essentially what Nathan's doing with cost estimating in the IMPD). Alternatively, we could try to convince the eCapris developers to accommodate non-capital projects in that system, which would maybe allow us to leave the cost estimating entirely out of Moped.

Does that sound right to y'all?

[amenity]

Alternatively, we could try to convince the eCapris developers to accommodate non-capital projects in that system, which would maybe allow us to leave the cost estimating entirely out of Moped.

This is what I've been 🤞ing for. It sounds like it's already being used off-label for other things like the Airport's tenant management... 🤷‍♀️

[johnclary]

Looking forward to asking Peggy and Systems Development what they think about the gap in eCapris support for non-capital projects. Also, a question for them and for Brian L.—why can't you track non-capital projects in eCapris?

[zappfyllc]

Just wanted to pop in and offer some insight here with some thoughts on eCapris, but I think we're all on the same page with v1.0 having a limited tie-in that links between the two systems based on user input into the subproject ID field (subproject ID is the best match for Moped project ID for sure; I just shortened the column to "eCapris ID", but as I've confirmed with @amenity, it really should be "eCapris subproject ID").

• The cost estimating in IMPD, to the best of my knowledge, is fairly detailed and tied to project components. While this could certainly meet the requirements for Systems Development and financial users, I think those requirements might be met through a combination of some high-level "guesses" (perhaps in some cases informed by an analysis like IMPD provides, but in other cases utilized with other tools/spreadsheets used by a project's respective workgroups) and relevant data points like Project Group, Project Tags, Funding Sources, etc., which are probably worth discussing sooner than later (but will likely encounter the same issues of standardization as we've run into with Project Roles and Phases/Milestones).

• IMPD does pull in FDUs from eCapris reports into Moped but Nathan has said before that if a link exists between eCapris and Moped, that should suffice because users could pull up the list of FDUs tied to a subproject in eCapris.

• I'm hesitant to offer any financial fields outside of a link to eCapris for v1.0, but I did build into the data model an entity for collecting float values related to budget, expense, etc. We don't have to use those at all, but offering the fields to start might satisfy some people. We would just have to be clear that the numbers are unofficial and that Moped is not the reliable source of that kind of data (until we have more clarity or the functionality is good enough to ensure consistency/reliability).

• I imagine that non-CIP funded projects are not quite as cut-and-dry and leaving them out of eCapris helps maintain the continuity for eCapris to be a system of record for that kind of data without muddying the waters, but I think it's a fair question and eCapris' documentation certainly does refer to project tracking more generally than just CIP-funded projects. Anecdotally from talking to stakeholders, I was under the impression that once a project is in eCapris, its financials are managed there, but that many projects don't meet that standard and need to have more fluid and negotiable financials (which currently amounts to untracked project funding).

[amenity]

My notes: 2020 bond partners - want Amica, Ana, Laura, Nathan...

• Standards for categorizing projects across the department
• SD23 categories
• Need to develop a refined list of categories, "e.g." Pedestrian Safety"

Conversation w/ JD was a long time ago

• Were primarily using eCapris b/c it was whbat was available;

• Has not been useful for projects that are in planning, not funded

  • If we want to change, rename, reactivate — need to duplicate data

• eCapris wasn't able to track the progression of a project from potential to funding

• Integration with eCapris should be limited — we want Moped to complement

• Everything changes name - "Traffic calming" ---> "local improvements" ---> "pedestrian safety" - makes it difficult to track over time if you're changing what it is called

• eCapris is bad at tracking deeper levels beyond project and sub-project

  • Moped would associate these with the smaller sub-projects, enable a more granular level of

• Unfunded needs - never going to be met in eCapris

• eCapris:

  • Good as source of information, e.g. who should I contact about this project
  • Reporting on bonds program, e.g. "What rolls up in this proposition?"
  • Integration with financial system is key — being able to track where we're at with the financials
  • What non-Capital-projects planning would make sense in eCapris
  • Multi-year projects might benefit from being in
  • Have added on contract-management piece to eCapris
  • Milestones or deliverables that are tracked in eCapris
  • Maybe what

• Peggy has asked for ability to apply operating budget to projects

• Moped <---> eCapris

  • Planning in Moped
  • Be able to see eCapris data

• Current scope

  • Subproject ID tie-in

  • In Moped

    • Schedule - pull from eCapris
    • GH Issue: Map eCapris milestones to Moped milestones
    • Final report - pull from eCapris

  • In eCapris

    • Expected spend
    • Encumberances
    • Paid encumbrances

  • How would we nest projects? E.g. one project in eCapris

  • Talk to Tina V. W. and Bruce N. — works in budget, owns eCapris data structure; need to connect re: data access

  • Reliabley know that Moped projects without Subproject IDs are not in eCapris

AIMS - Oracle database, everything with City financial transactions

• ETL to eCapris, but not reliable

Microstrategy

• Dan V. uses it for reporting for — AMANDA, but know that it's not completely standardized

• AIMS, eCombs, eCapris - all plug in and there are often discrepancies

Liane also sent the link to http://austintexas.gov/department/welcome-civic

[amenity]

@zappfyllc - seems like we may want to map Moped phases to those in eCapris, as project "schedule" was a place where eCapris and Moped data should match up.

[zappfyllc]

@amenity @johnclary Definitely a possibility. I don't have a problem with aligning with eCAPRIS, but by and large whenever eCAPRIS came up from most stakeholders during the sessions, along with various documents I perused from the city during my research (i.e. 2017 audit of Capital Projects, the feedback was not overly positive. And yes, those meetings were a while ago (as was this report), but I think the takeaway is fairly clearly on what eCAPRIS' limitations are in its current state. Here are some salient pieces I identified from that report:

Testing also indicated that Public Works did not monitor cost estimate data entered into eCAPRIS (the project management system of record).

We could not determine whether the City routinely delivers projects on time because the quality of the eCAPRIS project schedule data was often poor. Out of 48 projects tested, we could not find sufficient data in 15 (31%) to compare the initial estimated delivery date to the final delivery date.

Project managers must update information such as encumbered project funds, project schedules, budget estimates, and status updates. However, only 17 of 48 projects (35%) we tested included monthly updates in the past six months of project activity. In addition, a survey of sponsor departments revealed 7 out of 11 departments (64%) are dissatisfied with the quality and frequency of eCAPRIS updates. Some departments also expressed dissatisfaction with the frequency of budget updates (27%) and spending plan updates (36%).

Public Works employees and sponsor departments alike cited eCAPRIS as a major hindrance for project management and coordination. Both parties see eCAPRIS as an accounting tool, rather than one suited to project management. Due to frustration with eCAPRIS, multiple project managers reported that they develop and use separate systems for day to day project management (in the form of Excel spreadsheets). They copy information to eCAPRIS when required, leading to duplicate work and possible delays in relaying information to sponsor departments. One sponsor department cited a particular concern with the lack of budget and spending plan updates, noting that the delays caused the department’s own capital planning process to be inaccurate. There is also a risk that information is copied to eCAPRIS incorrectly.

Key question: has this changed since 2017?

I am all for integrating in a more meaningful way between the two systems because it's very clear Moped could complement, as you mentioned, but I think it's going to be very important for any stakeholders who rely day-to-day on eCAPRIS to listen very closely to what project managers and various employees who are actually entering the data say is helpful or not. Moped gives them the opportunity to address exactly that (at least users of Moped i.e. ATD, PWD) and present users an alternative, which can still map to eCAPRIS when it's all said and done but maybe using a facade pattern.

Thanks for the update! Sorry I couldn't make the meeting.

[amenity]

Thanks, @zappfyllc. Yes, it sounds like there is wide agreement that eCAPRIS is not good at project management. And if phases are not reliably tracked in eCAPRIS it would be worthless to align with them in Moped. This was a suggestion from Liane

My main question is whether the accounting data —expected spend, encumberances, paid encumbrances — is (or could be made to be) reliable enough that we could avoid duplicating it in Moped. And, to take that a step further, whether those data points could be tracked there for even non-capital funded projects.

[amenity]

@johnclary @mateoclarke - wanna make sure you two have a chance to peep at those👆 excerpts @zappfyllc pulled from the 2017 audit before I close this.

[johnclary]

Wow—thanks @zappfyllc for the insight. My takeaway from recent conversations with SSD and Finance is that eCapris' core, required-for-every-department functionality is budget forecasting. Once a project is budgeted, it's up to staff to use the project mgmt features, which are effectively optional?

@amenity good questions. I've been learning a lot recently about financial data and am really ready to take eCapris for a test drive.

[johnclary]

During today's sprint review Nathan W brought up the need to tie Moped projects to an eCapris sub-project ID, and/or an FDU. Renee seconded.

This makes sense and is consistent with our tie-ins to FDUs in the Data Tracker. I have started drafting a long read about how these elements all tie together, but will hold off on posting for now. I asked Nathan and Renee to provide example FDUs. Once they provide those I'd like to dig deeper into the links between such FDUs and project budgets.