A spreadsheet, but better, for your program budgets

This tweet reminded me that we had a similar thought when we were planning the original version of what has become GriffinPlan. Our existing tools did not do what we wanted. We were tying together various solutions with twine and duct tape to meet our needs for how projects actually unfold out over time.

Most project management software is designed for how we *wish* projects ran: predictable work, accurate estimates, known outputs, zero entropy.

This is why we all end up in spreadsheets; spreadsheets don't even assume a project is actually happening.

— Des Traynor (@destraynor) March 28, 2018

What we had assembled was a set of spreadsheets with embedded undocumented formulas. We passed them around by email and they lacked consistency and traceability. Our process for managing projects, resources, and budgets worked. But our tools for doing so were getting in the way of our process. To solve that we ended up crafting a custom web-based solution quickly over a weekend. This was in a sense a set of interconnected spreadsheets with business logic, some reporting, and was collaborative. It worked for awhile.

Why is this? Why can’t experienced project managers working with skilled engineers solve this problem for the long-term in a scalable way? Or could we?

Other IT departments have built many similar solutions using Trello, JIRA, Airtable, Notion, or Excel. But we have all made different versions with similar functionalities all trying to solve the same basic problem. In our situation, we faced having a great engineering group that wanted to keep logging their hours worked into JIRA and not learn another new tool. And we had a management and finance team that did not need the details of each story and ticket in JIRA. Also, we needed cost estimates and budget codes and long-term resource forecasts available which JIRA does not support. We needed to deliver this information, updated and accurate, all while we were pulled in too many directions. Our PMO wants to be managing portfolios and business objectives. They do not want to be updating them for the thirteenth time because somebody saved over the last revision or the numbers need to be seen in a different format.

On a more practical and less dramatic level, a PMO wants to track, analyze, and forecast their budgets and resources to best unlock the capabilities and capacity of their department. What we knew during budget planning season a year ago is very different from what has transpired over the ensuing twelve months.Work that could not be predicted appears and disappears during the year. Actuals end up being different than estimates for any number of valid but unforeseen reasons. The deliverables of a project change as requirements emerge and time passes. None of this is bad, but it all needs to be captured, remembered, and organized. This allows for the explanation of the movement of projects, resources, and their corresponding budgets over time. This is difficult, but very key to successful executive engagement and ongoing support of initiatives.

So what do we need?

We kept iterating on our tool for it to useful and valuable to IT departments, project management offices, their management, and their companies. We thought about what we have used spreadsheets to solve for us, what new problems spreadsheets cause on their own, and what we do not need help with because we use other tools already.

Like in public health, most project management pain is self inflicted by compressing distributions into just a dumb number at planning, and then spend the rest of the project glossing over how the real world works and making arm wave explanations when dates go by.

— Eduardo Jezierski (@edjez) March 30, 2018

Key requirements for a solution: A key concept for us in designing this solution was being able to maintain versions of our plans. We would have several versions during budget development, the final approved yearly budget, monthly review snapshots, an approved projected year-end view, and the actual year-end numbers. When capturing estimates for the year of what projects are intended to be tackled, we wanted to be able to also have the expansion of detail behind the estimates. We wanted to be able to know what made up that large number, what were its components and our thinking by each person, project, team, portfolio, and by month. And we wanted to be able to see the changes over time in forecasts and to be able to overlay actual costs and effort against the original estimates for a project to see their impact on forecasts going forward.

We also needed a tool that was comfortable and understandable for a wide variety of audiences: engineering, PMO, finance, and product owners. For each of these audiences, they needed a view of the data tailored to them highlighting the conclusions specific to them. A PMO Director would need to be able to see a global list of projects by each program with their intended timeframes. An engineering lead could view their assigned projects and assign resources. A project manager would the have the ability to manage the capacity of the team, view actual time worked, compared to the original baseline, and reforecast the project as needed. A senior executive if they desired could see a visual summary of the costs by team and program and see them aligned to the department budgets. And our accountants would be able to see the revised forecasts and be able to export this data for their own reporting needs.

As stated before our finance and business operations team did not want to be in the details of JIRA. They do not think of tickets or issues or story points. We needed another way to bring it up a level, summarizing and presenting in terms they better understand and the way that they think in making decisions. This meant being able to convert back and forth to dates, dollars, people, and business outcome deliverables.

Problems with spreadsheets: Even in moving these processes and building something custom in a spreadsheet there are some inherent problems in the way that Excel, Google Sheets or other tools work. To be better, we would need to solve some of these.

Spreadsheets have their own problems. Low / no maintainability, data validation, permissions, interop with email and calendar, usability on mobile, high level reporting, integration with CRM and systems of record, etc. IMHO better as scratchpads than to house org processes.

— Alex Patriquin (@apatriq) March 28, 2018

By having a web-based application for our organizational process, we have been able to support collaborative editing of information while at the same maintaining version control and data validation. Additionally, we are able to support permissions for each type of user, and are able to connect our tool with other internal systems as needed and make it available on mobile devices.

Provided by other tools: Other solutions we have considered for the above do not seem to provide a happy medium. They are either too lightweight and lacking the specific functionality we need. Or they are too heavy imposing a specific set of processes, need to be customized, and come along with a hefty price tag.

Besides, we have great tools for managing the actual tasks in the projects and providing status updates. We did not want to duplicate that. This effort was more about managing the people and cost pools underlying the programs and portfolios. Our finance team has tools for managing the invoices and payables, but not their ties to the projects and programs. Our legal department has tools for managing our contracts and their terms, but not the resources and expenses provided by them. We needed a tool that brought all this together and co-existed with them.

GriffinPlan. In summary, we needed a tool that provided smart IT resource management and budgeting. A tool that would let all involved in managing the IT department consider the past (what work is being done, what is it costing), the present (reconcile invoices to timesheets, update prioritized plans), and the future (forecast our costs, track our budgets) in a single comprehensive tool.

Are you interested?

While what is described exists to various degrees in an earlier version of GriffinPlan, it is being extracted out, made more durable and more generic. We would consider GriffinPlan currently to be an alpha version. If interested in what we are developing, want to see a demo, or give us feedback, contact us at hello@griffinplan.co.