Hey Michael, I have a great idea for a new tool. It's going to save me sooo much time."

I hear this at least once a month, usually from smart, well-intentioned people who've identified a genuine pain point in their workflow. They're excited, energized, and ready to get their hands on their new tool.

This particular conversation was with a Revit technician at my previous company. He wanted a tool that would automatically show sloped columns in graphical column schedules—something Revit's native column schedules don't handle. Every time he had a concrete structure project with sloped columns, he had to work around Revit's limitations manually. He'd been dealing with this frustration for years and was convinced this automation would be a game-changer.

"How much time do you think this saves?" I asked.

"Oh man, tons. I spend forever working around this."

So I pulled out my project charter template and we started filling it out together. Fifteen minutes later, we both stared at the numbers on the screen.

The tool would take roughly 6-8 weeks to build correctly. It would apply only to concrete-structure projects with sloped columns. This represented about 15% of our total project volume. And even on those projects, the manual workaround just took a couple of hours. The ROI? Somewhere north of 18 months. Possibly never, if project types shifted.

We didn't build the tool.

The Problem with "Great Ideas"

Here's the thing: that engineer wasn't wrong. The tool would save time. It would reduce errors. It would make that specific task easier.

But "saves time" isn't the same as "worth building." And this is where most automation projects go sideways—not because the execution fails, but because nobody asked the hard questions before writing the first line of code.

Project charters get a bad rap. They sound corporate, bureaucratic, like the kind of thing that slows down the scrappy innovators. But a good charter isn't red tape—it's a forcing function that makes you confront reality before you've invested dozens (or hundreds) of hours into something that shouldn't exist.

And the best part? When paired with an LLM, creating one takes about 30 minutes.

The Charter That Saves You From Yourself

I've refined my project charter template down to nine essential sections. Nothing fluffy, nothing that exists to fill pages. Every section answers a question that determines whether your project is actually viable.

Let me walk you through it:

1. Executive Summary

Start with the headline version: What's the tool? What problem does it solve? This forces you to articulate the core value proposition in 2-3 sentences. If you can't do that clearly, you're not ready to build anything.

2. Project Goals & Metrics

This is where "saves tons of time" dies. You need SMART goals—Specific, Measurable, Attainable, Relevant, Time-bound. Not "improves efficiency" but "reduces annotation time from 30 minutes to 5 minutes per concrete structure project with sloped columns."

Define exactly what metrics you'll use to measure success. If you can't measure it, you can't know if it worked.

3. Business Case / Background

Describe the current workflow in excruciating detail. How many people does this affect? How often does the problem occur? What are the actual consequences of not solving it? What's the risk if we do nothing?

This section is where my engineer friend realized "I do this twice a month" wasn't the compelling case he thought it was.

4. Gains, Costs, and Budget

Here's where the math happens. List the expected gains—time savings, error reduction, risk mitigation. Then estimate development costs using t-shirt sizing:

• S = 2 weeks of development
• M = 1 month
• L = 6 months
• XL = 12+ months

Now calculate ROI. If you're saving 25 minutes twice a month (50 minutes/month) and the tool takes 160 hours to build, you need 192 months to break even. That's 16 years!

There's a classic XKCD comic that illustrates this perfectly: Is It Worth the Time? It shows exactly how long you can spend automating something before you're wasting time. Spoiler: if you're only doing something twice a month, you don't get to spend much time automating it.

Suddenly, "tons of time" looks different on paper.

5. Scope and Exclusions

What's in? What's explicitly out? This prevents scope creep and helps you resist the temptation to solve every related problem at once.

6. Deliverables

What exactly are you building? UI mockups? A Revit add-in? A Dynamo script? API integration? Be specific.

7. Project Team

Who's actually doing the work? Who needs to approve decisions? Who's responsible when things go sideways?

8. Change Management Plan

How will people actually start using this? What's your adoption strategy? Training plan? Rollout phases? A tool that nobody uses has infinite ROI (a divide-by-zero error).

9. Mock Ups

Show, don't tell. Even rough sketches force you to think through the actual user experience before you're committed to an architecture.

What the Charter Revealed

When we filled out the charter for the sloped column annotation tool, sections 2, 3, and 5 told the whole story:

Goals & Metrics: Reduce annotation time from 90 minutes to ~5 minutes per applicable project.

Business Case: Affects approximately 2 projects per month. The current workflow is tedious but functional. Risk of not solving: minimal—annotations still get done, just slowly.

Gains vs. Costs:

• Time saved: ~50 minutes/month
• Development cost: M (estimated 160 hours)
• ROI: 192 months

The charter didn't kill the project. The math did. The charter just forced us to look at it.

The Three Lessons

If you're new to coding or Dynamo, resist the temptation to start building right away (I know, it's hard). Don't touch the keyboard until you've done the math. Enthusiasm is not a business case. A charter gives you a structured way to think through whether your idea is worth pursuing before you're emotionally invested in the code.

For the more experienced developers, you know how to build things. You might be less practiced at deciding what to build. A charter is your defense against wasting your considerable skills on low-impact projects. It's also your best tool for pushing back on bad ideas from leadership—bring data, not opinions.

And for all you managers and decision-makers, I highly recommend requiring charters, not as busywork, but as a filter. The projects that can't survive charter scrutiny won't survive development either. Better to find out in 30 minutes than 30 weeks.

The Real Win

The sloped column tool was a "no" this time. But that technician came back six months later with a different idea—a tool for automating concrete foundations. Once again, we sat down and worked on a charter. This time, it worked out in favor of the math. We built the tool and put it into production. By the time I left the company, it had already paid for itself twice over.

The charter didn't just save us from a bad project. It gave us a framework to recognize good ones.

And that's worth way more than "tons of time."