Part 1: Why Your Project Charter Should Start With a Problem, Not a Plan
The Business / Opportunity Description field of the project charter
A sponsor catches you in the hallway and asks something simple: "Remind me why we're doing this project again?" You know the answer, technically. But it comes out as four sentences, two restarts, and a reference to a slide deck from six weeks ago. The sponsor nods and walks off, and you're left with the uncomfortable feeling that what you just gave them was a summary of activity, not a reason.
That moment happens to almost every new project manager, and it usually happens because the project skipped its first real decision: writing down, in plain language, why it exists. That is the job of the Business / Opportunity Description, the first field on the project charter 8-pack. It sounds like the easiest field on the page. In practice, it is the one most people get wrong, and getting it wrong is expensive later, because every other field on the charter leans on it.
This is Part 1 of an eight-part series walking through each field of the project charter 8-pack, one at a time. Each post takes a single field, explains what it is actually protecting you from, shows a common mistake, and gives you a way to write it that holds up under questioning. We're starting here because everything else on the charter- scope, team, schedule, budget- is a decision made in service of this one paragraph. If the paragraph is wrong, the decisions built on it are wrong too, even when they look perfectly reasonable on their own.
What this field is actually doing
The Business / Opportunity Description answers three questions a sponsor, a new team member, or a skeptical stakeholder should be able to get answered without a meeting: what problem or opportunity is driving this, what role does the organization play in addressing it, and what does it connect to that the organization already cares about.
It is tempting to treat this as an introduction, a bit of throat-clearing before the charter gets to the parts that matter, like scope and schedule. That's backwards. This field is the test the rest of the charter has to pass. It is sometimes called 'The Burning Platform' - what is the issue at hand. When a scope debate comes up in week six, this is what you point back to. When someone asks why a milestone slipped in favor of another priority, this is the paragraph that settles it. A charter with a weak opening paragraph and a strong schedule is a house with a good roof and no foundation.
The mistake almost everyone makes: writing the solution instead of the problem
Here's the pattern. Someone writes, "This project will roll out a new scheduling platform for the clinic." That sentence reads like a business justification. It isn't one. It's a solution wearing the costume of a problem statement.
A solution tells you what will be built. A problem tells you why anything needs to change at all. The distinction matters because a solution can't be argued with, only executed, while a problem can be tested, questioned, and reconsidered if a better answer shows up later. If your charter opens with the solution, you've already foreclosed on the conversation about whether it's the right one.
A useful check: read your draft and ask whether it would still make sense if the solution changed. "We're implementing a new scheduling platform" collapses the moment someone proposes a different platform. "Front desk staff spend two hours a day resolving double-booked appointments because paper scheduling doesn't sync across three intake locations" survives that conversation, because the problem is still true no matter what solution eventually gets picked.
Four questions that get you there without staring at a blank page
Most people freeze on this field because they try to write a polished paragraph on the first attempt. Don't. Answer these four questions first, in whatever rough shape they come out, then assemble the paragraph from the answers.
A stage-close checkpoint should answer:
What specific pain, inefficiency, or missed opportunity is driving this? Not "improve patient experience," but the actual, nameable friction: lost appointments, duplicated data entry, a compliance gap, a competitor moving faster.
What is the organization's role here? Are you fixing something broken, replacing something outdated, building something new, or enabling an expansion that's already been decided elsewhere?
What one or two existing priorities does this connect to? Not eight. If you have to stretch to find the connection, it probably doesn't belong in the charter.
Who is actually affected? Name the roles or departments, not "the organization." Vague impact statements are why people get blindsided by a project they didn't know touched them.
Once you have honest answers to those four, the paragraph mostly writes itself. The discipline isn't in the prose. It's in refusing to move on until the answers are specific enough to survive a follow-up question.
What this looks like in practice
Take a small regional health clinic replacing its paper-based patient intake process. A first-draft, solution-first version might read: "This project will implement a digital patient intake and scheduling system across all clinic locations." It's not wrong, exactly, but it tells you nothing about why anyone should care.
Run it through the four questions instead. The pain: front desk staff at three locations manually enter patient information from paper forms into separate systems, which creates duplicate records, delays check-in by an average of eleven minutes per patient, and has led to two missed insurance authorizations this quarter. The organization's role: replacing a manual, paper-based process with a shared digital system. The connection: this supports the clinic's stated goal of reducing average patient wait time and closing a documented compliance gap around insurance verification. The people affected: front desk staff at all three locations, billing, and returning patients who currently fill out the same form every visit.
Put together, that becomes something like: "Front desk staff at the clinic's three locations currently re-enter patient information from paper forms for every visit, which creates duplicate records, adds roughly eleven minutes to average check-in time, and contributed to two missed insurance authorizations this quarter. This project will give the clinic a shared digital intake system to close that gap. It supports this year's priority of reducing patient wait times and correcting the insurance verification issue flagged in the last compliance review. It will directly affect front desk staff, the billing team, and returning patients."
Notice what changed. The second version can be questioned, measured, and revisited. If a better solution than a digital intake system comes along, the problem statement still holds, and the project can pivot without needing a new charter. That's the difference a few honest sentences make.
Two habits that quietly undermine this field
Beyond writing the solution instead of the problem, two smaller habits tend to weaken this section even when the intent is right.
The first is jargon written for people already inside the project. A phrase like "reduce EHR fragmentation across intake workflows" might be perfectly clear to the clinical operations team and mean almost nothing to a finance sponsor or a new hire reading the charter for the first time. Write this field for the informed outsider, not the person who already lives in the problem every day. If a stakeholder from outside the immediate team can't follow it on the first read, it needs simplifying, not because they're less capable, but because clarity is the point of the exercise.
The second is over-connecting the project to strategy. It's tempting to tie a project to every organizational priority it could plausibly touch, on the theory that more connections make it look more important. The opposite tends to happen. A project that claims to advance six strategic goals at once reads as unfocused, and a skeptical sponsor will usually pick the weakest connection and ask why it's there. One or two direct, defensible connections carry more credibility than a longer list of loose ones.
Practical takeaway
Before you move on to scope, team, or schedule, run your draft through one test: can you say the business problem in two sentences or fewer, without naming the solution? If you can't, the problem isn't clear enough yet, and no amount of detail in the later fields will fix that. Go back to the four questions and keep clarifying until it fits.
What comes next
Once the problem is stated clearly, the next question is just as easy to get wrong: what exactly is this project going to do, and just as importantly, what is it not going to do. That's Field 2, Scope, and it's where most projects quietly start expanding beyond what anyone actually approved. That's Part 2 of this series.
Download the Business Case Quick-Reference
Ready to put this into practice? Use the Business / Opportunity Description Quick-Reference as a simple one-page guide to the four questions, the solution-vs-problem check, and a fill-in-the-blank template for writing this field on your next charter.
