PMG (Internal Tools)

PMG has delivered more than 75 projects across municipal, education, transportation, aviation, and healthcare work. That history is what wins new work. Every proposal, statement of qualifications, and interview needs it: past performance in a market, project values, client relationships, delivery dates, and the people who did the work.

That history did not exist in any form the team could query. It was spread across old proposal files, SharePoint folders, and a single marketing spreadsheet that was built to publish web pages, not to answer questions. When someone needed the firm's municipal projects over 20 million dollars, they opened files and read through them. That took hours, produced a different answer each time, and got redone from scratch by the next person who needed it.

The request came from the marketing team. Building proposals and project sheets kept stalling on the same step: they could not reliably find consistent, structured data about past projects and clients. The pain was worst for a new marketing hire who had to locate history they had never touched.

Instead of taking the complaint at face value, I went to the source data to find the cause. I profiled the marketing spreadsheet, the closest thing PMG had to a project database, and the profiling showed exactly why the team struggled.

Contract values were stored as free text, not numbers, so nothing could be sorted or totaled. No real dates existed anywhere, so a question like what did we deliver in 2024 could not be answered. Project status was buried inside a free-text duration field. One client appeared under six different spellings, so a search for everything from that client returned only a fraction of the truth, and one of the firm's largest markets was undercounted by about 40 percent from simple case differences. Rows were not even projects: a single cell held eleven separate projects, so 55 rows were actually more than 75 projects.

The conclusion was that the spreadsheet was not badly maintained. It was built to generate web pages and was never going to work as a system of record. That reframing is the whole project. The team's symptom was I cannot find the data. The real cause was there is no structured source of truth.

The build is an internal web application backed by a real database, where every project is a structured record that can be searched, filtered, sorted, and edited. Employees sign in with their existing Microsoft work account, so there is no separate password to manage.

The scope decisions matter as much as the build. It is not a project management tool. It does not track schedules, budgets, RFIs, or submittals, because Procore and similar tools already own live-project data. This is the firm's record of completed work, built for retrieval and reuse.

Two rules keep the data clean for good. Market and client are fixed-list selections rather than free text, which is the single constraint that prevents the one client, six spellings problem from happening again. And every change is attributed and logged, with records archived rather than deleted, so the firm's history can never be quietly overwritten again.

The first version of the plan specified one stack: Microsoft SQL Server, cloud hosting, and a third-party sign-in service. When I brought it to PMG IT, they proposed a different plan: PostgreSQL, hosted on the firm's own infrastructure and containerized, with sign-in handled directly through the firm's existing Microsoft identity instead of an outside service.

I reversed all three decisions in a second version of the PRD, in IT's favor. The reasons were concrete. PostgreSQL removed a licensing cost and a storage limit and had a cleaner container setup. Hosting on the firm's own network kept the data in-house and removed the largest security risk in the first design. Using the firm's Microsoft identity directly took an outside vendor out of the security picture. Because the data layer was built on an ORM, switching databases was a configuration change, not a rewrite.

The point is simple. Being right mattered less than shipping the right thing. Coordinating with IT produced a safer and cheaper architecture than my original plan, and recognizing that was the correct call.

The working tool does the job the team actually needs. A sortable, searchable table of every project carries filters for market, client, service line, contract value range, and date range that can be combined, so a coordinator can pull municipal, over 20 million dollars, last five years in seconds instead of hours.

A filtered list can be exported, so the marketing team takes exactly the projects they need into a proposal or project sheet. Setting the tool up meant migrating the old spreadsheet: splitting the multi-project rows into individual records, turning free-text values into real numbers, and reconciling the client spellings into one deduplicated list.

Each project has its own detail page with all fields, formatted values, real dates, service lines, and a shareable link. It is the view a coordinator opens to confirm the details behind a past project before citing it in a proposal, and it is the structured source that a polished project sheet is built from.

New records go in through the structured form shown at the top of this page rather than a blank cell. Client and market are chosen from fixed lists, dates are real dates, and contract value is a number. The form is where the data-quality problem gets solved at the source, so the database stays clean as it grows.

The tool shipped and the marketing team uses it every day to pull project data for proposals and project sheets. PMG has no built-in analytics or feedback system, so that adoption is observed rather than measured, and I am not going to attach a number to it that I cannot support.

I also built a second internal tool for the firm, an opportunity scraper that watches public procurement portals for solicitations that match PMG's project profile, so the firm can find and pursue more of the work it is positioned to win.

The honest gap is measurement. The tool has no feedback loop, so its value is currently assumed rather than proven. The next build would add usage tracking, so the impact can be measured instead of described.