A Project Exists Before You Call It One

A project without a name

Our training team was doing accessibility audits and producing results. The results were good. The problem was what happened next: those results were not turning into targeted training. People were getting general sessions when they needed specific guidance based on what their actual audit had found.

Nobody assigned this problem to me. Nobody scheduled a kickoff. There was no project charter, no project team, no formal timeline. It was just a gap I had noticed and a decision I made that the cost of leaving it alone was too high.

So I built a tool. It takes accessibility audit results and converts them into customized training content. I defined the scope myself. I set the constraints. I wrote out the definition of done and the minimal viable product before I wrote a single line of code. I set milestones and tracked against them. When the first version shipped, I iterated. I eventually moved the whole thing from Python to HTML, JavaScript, and CSS so other people on the team could access and run it without needing a development environment.

There was never a formal project. There was just the work, the discipline I brought to it, and an outcome that mattered.

That is what initiation looks like when it happens honestly. A project exists the moment you recognize a gap between the current state and a better one. The paperwork comes later. Sometimes it never comes at all.

The five-stage lifecycle

Every meaningful effort follows the same five stages. My training tool went through all of them, even though it never had a name on a project board.

Initiation is the why. I noticed that audit results were not becoming useful training. I decided that gap was worth closing. That decision was the project beginning, whether I called it that or not.

Planning is the how. I defined scope, set constraints, wrote out the definition of done, identified the minimal viable product, and mapped milestones before I built anything. Not because someone asked me to. Because that is how good work gets done.

Execution is the work. I built the first version in Python. It worked. That was the MVP. Execution is the stage most people think of as the whole project. It is only the middle.

Controlling is the balance. Monitoring progress, catching problems early, making sure the work stays connected to the outcome I defined at the start. When I realized Python was a barrier to other people using the tool, that was a control signal. The outcome required more people to have access.

Closing is the value. Moving to HTML, JavaScript, and CSS was not a new project. It was closing the loop on the original outcome: training that people can actually access and use.

When people skip Initiation, the rest of the lifecycle becomes reactive. Planning feels rushed because nobody agreed on the outcome. Execution feels chaotic because scope was never defined. Closure never quite arrives because nobody knew what done looked like in the first place.

Beginning with the end in mind

Before I wrote any code for the training tool, I wrote out what done looked like. Not in a formal document. Just in plain language that I could test the work against. A trainer can take an audit report, run it through the tool, and get customized training content that maps to the actual findings. That was the outcome. Everything else was a constraint or a milestone on the way to it.

That is what Initiation requires. Not a charter. Not a budget code. A clear description of the outcome that proves the work succeeded.

The minimal viable product discipline comes from the same place. I did not need the tool to do everything on day one. I needed it to do the one thing that made the gap smaller. Once I had that, I could iterate. But I could only define MVP because I had already defined done. MVP is just done minus everything that can wait.

Without that clarity up front, teams optimize for activity instead of outcomes. They ship outputs and call it delivery. They never know whether they fixed the actual problem because they never agreed on what the problem was.

The cost of doing nothing

Before I built the tool, someone was doing this work manually. Taking audit results and figuring out what training to recommend based on what they found. That takes time. It introduces inconsistency. And it means the quality of the training depends on how much bandwidth the person doing it has that week.

That is the cost of doing nothing. Not a dramatic number. Just friction, repeated. Time that could go toward better work. Inconsistency that erodes the value of the training program. A dependency on one person's availability that nobody had named as a risk.

Leaders often focus on the cost of the project. That is the wrong number to start with. The right number during Initiation is the cost of not doing it. When you can see that clearly, the investment required to fix the problem stops looking like overhead and starts looking like the obvious choice.

Making that cost visible is part of what Initiation is for.

Finding the real why

To find the real problem, I give myself permission to ask why until the jargon falls away. I have done this in rooms with executives and I have done it sitting by myself before starting a project. The process is the same either way.

With the training tool, it started with an observation: the audit results are not becoming useful training. Why?

Because mapping audit findings to the right training content takes time and expertise, and the people doing it do not always have both available. What does that cost?

It costs consistency. Some people get targeted guidance. Others get whatever was available. The quality of the training depends on bandwidth, not on the findings.

There it is. That is the leak. And once you can see it clearly, you can measure the value of fixing it.

Initiation is not about documents. It is about being willing to ask the question one more time than feels comfortable, until the real problem comes into focus.

The initiation checklist

Before you start a project, ask these four questions: