Part 4: If You Can't State the Goal in One SMART Sentence, You Don't Have a Goal Yet
The Goal Statement & Primary Deliverable field of the project charter
Three weeks before go-live, the clinic's project team sits down for what's supposed to be a routine status check, and it turns into something else. The vendor, Tom Reyes, says the project is basically done, the system is configured and tested, that's what he was hired to deliver. Maria Chen, the Project Lead, says it's not done until all three locations are actually using it day to day, not just technically live. Dr. Bennett, the Executive Sponsor, says it's not done until check-in times actually come down, because that was the whole point. Three reasonable people, three different definitions of finished, and nobody is wrong according to their own version of what the charter promised.
That meeting happens because the charter never nailed down two things that sound obvious but almost never get written with real precision: what outcome this project is actually delivering, and what single, tangible thing marks the moment it's done. That's the job of Field 4, the Goal Statement and Primary Deliverable. It's arguably the most important sentence on the entire charter, because Fields 1 through 3, the problem, the boundaries, the people, exist to set up this one decision, and Fields 5 through 8 all get measured against it.
What this field is actually doing
This field has two parts that work together but do different jobs. The Goal Statement is the intended outcome, written so specifically that it can be tested rather than just agreed with in a meeting. The Primary Deliverable is the single tangible output, system, document, trained population, process, whatever it is, that signals the project is actually complete.
The Goal Statement answers what changes in the world because this project happened. The Primary Deliverable answers what you can point to and say, that's it, that's the thing, we're done. Projects that skip a real Goal Statement end up measuring the wrong thing at closure, usually activity instead of impact. Projects that skip a clear Primary Deliverable end up in the exact meeting the clinic team just had, three people with three honest, incompatible definitions of finished.
The mistake almost everyone makes: writing an activity instead of an outcome
Here's the pattern. Someone writes, "Implement a digital intake system across all three clinic locations." That sentence is true, specific even, and it is not a goal. It's an activity. Activities can be completed in full and still fail to produce the result anyone actually wanted. You can implement a system flawlessly and have front desk staff quietly keep using paper forms alongside it, because nobody defined success as adoption, only as implementation.
The distinction is simple to state and easy to miss in practice: an activity describes what the team will do. An outcome describes what will be true afterward that isn't true now. "Implement a digital intake system" is an activity. "Reduce average check-in time from eleven minutes to under five, with one hundred percent of patient intake handled digitally across all three locations" is an outcome. The second version can fail even if every task on the project plan gets checked off, and that's exactly the point. It forces the team to keep its eye on the actual problem from Part 1, not just the work plan built to address it.
The five-part test every goal statement has to pass
A goal statement earns the right to anchor the rest of the charter by passing five separate checks, not by sounding impressive. Each one catches a different way goals go soft.
Specific: What exact condition will exist that doesn't exist today? Not "better check-in," but the precise thing that changes.
Measurable: What number, percentage, or verifiable fact proves it happened? If the sentence needs the word "better" or "improved" without a number attached, it isn't measurable yet.
Achievable: Is this realistic for the actual team, timeline, and budget available, not the idealized version of all three? A goal the delivery team hasn't validated is a sponsor's wish, not a plan.
Relevant: Does it connect to a real, named business priority, the one stated back in the Business / Opportunity Description in Part 1? A goal floating free of that connection is a goal in search of a reason to exist.
Time-bound: By what specific date? Not a quarter, not "soon," an actual date that different stakeholders can't interpret differently.
Run a draft goal statement through all five before it goes on the charter. A statement that fails even one of them, usually Measurable or Time-bound in practice, isn't ready, no matter how clear it sounds out loud in a meeting.
Why Achievable is the check most people skip
Specific, Measurable, Relevant, and Time-bound all get checked against the document, the business case, the calendar. Achievable is different, because it can only be checked against the people actually doing the work, and that conversation is easy to avoid when a sponsor is eager to get started. A goal statement that a sponsor finds exciting and a delivery team has never been asked to validate is not a plan, it's a hope with a deadline attached.
For the clinic project, that means Maria’s team, not just Dr. Bennett, confirms that cutting check-in time from eleven minutes to under five is realistic given the actual staffing, the vendor’s committed configuration timeline, and the training schedule for three locations, not a compressed version of all three that only works if nothing goes wrong. Skipping this check doesn’t make the goal statement look any different on the page. It just means the first time anyone finds out the goal wasn’t achievable is during execution, when it’s far more expensive to discover.
In practice, a goal statement is often written and agreed on before staffing, timeline, and training are fully vetted. When that’s the case, review the Goal Statement against all five SMART criteria, but put the Achievable check on the Parking Lot. Then address it at the end of project planning, once those three have been worked out to an almost-final state.
The second common mistake: naming several things as equally primary
The Primary Deliverable question is simpler to ask than the Goal Statement but gets crowded just as often, in a different way. A first attempt at this field for the clinic project might list three things as the primary deliverable: the configured intake system, the staff training program, and the executive dashboard. Each one is real, and each one matters. None of them should be listed as primary alongside the others.
Projects accumulate important outputs constantly, a training deck, a dashboard, a rollout playbook, and listing several of them as equally primary feels thorough. It isn't. It just moves the ambiguity from being-vague-about-the-goal to being-vague-about-closure. When a charter names three primary deliverables and two are done but the third slips two weeks, is the project finished or not? Nobody can answer that from the charter, because the charter never actually decided which one counts.
Pick one. For the clinic, that's the live, in-use intake system, the thing the entire Business / Opportunity Description in Part 1 was written to fix. Training and the dashboard are real outputs, important ones, but they're milestones in service of the primary deliverable, not separate, competing definitions of what "done" means. If a stakeholder insists multiple things are equally critical, that's useful information, but it belongs in the Key Milestones section of the Schedule field in Part 5, not as multiple entries competing for the one Primary Deliverable line.
What this looks like in practice
Back to the clinic. Part 1 named the problem: duplicate patient records and check-in delays from paper-based intake. Part 2 bounded the work to digital intake configuration and training at all three sites. Part 3 named Dr. Bennett as Sponsor, Maria Chen as Project Lead, and the supporting team, including Sarah Coleman from billing and Tom Reyes from the EHR vendor.
A first-draft goal might read: "Roll out the new intake system successfully." That sentence is exactly how the three-way disagreement at the top of this post happens, because "successfully" means something different to each of the three people in that room.
Run it through the five checks instead. Specific: one hundred percent of patient intake handled digitally, with duplicate record creation eliminated. Measurable: check-in time, currently eleven minutes on average, with a target. Achievable: validated with Maria's team as realistic within the existing staffing and the vendor's committed timeline. Relevant: directly tied to the clinic's stated priority of reducing patient wait times and closing the insurance verification gap from Part 1. Time-bound: a specific go-live date, not a season.
Put together: "Deploy a digital patient intake system across all three clinic locations by March 1, reducing average check-in time from eleven minutes to under five and eliminating duplicate record creation, supporting the clinic's priority of reducing patient wait times." Primary Deliverable: "A fully configured, live digital intake system in daily use at all three locations, with front desk and billing staff trained and active, and the executive check-in time dashboard delivered to Dr. Bennett."
Notice that the three-way disagreement from the opening doesn't happen under this version. Tom's technical configuration is a milestone toward the deliverable, not the deliverable itself. Maria's adoption concern is baked directly into "in daily use," not left for someone to assume. Dr. Bennett's wait-time concern is the measurable core of the goal statement, not a separate, unwritten expectation. Everyone is arguing from the same sentence instead of three different ones.
Why this field is what leadership actually reads first
The Goal Statement and Primary Deliverable are often among the first elements senior stakeholders review when assessing a project's purpose, expected outcomes, and relevance. Both should be clear, concise, and compelling enough to support an informed assessment. They need to stand on their own, without requiring the reader to flip back to Field 1 for context. If a goal statement needs a paragraph of explanation to make sense, it isn't a goal statement yet, it's a draft.
These two lines are also the project's defense against goal-post movement. When a stakeholder shows up in week nine with a revised idea of what success looks like, as happens on nearly every project of any length, the documented SMART goal is the anchor the PM points back to. It doesn't prevent the conversation about changing direction, but it makes clear that a different outcome is a scope change requiring the same approval any other scope change would, not an informal adjustment absorbed quietly into the existing plan.
There's a second payoff that shows up later rather than immediately: this is also the field the Metrics section in Part 7 will build directly on. A goal statement with a real number and a real date gives that later field something concrete to set a baseline and a target against. A vague goal statement leaves Part 7 with nothing to measure, which means the gap created here doesn't stay contained to this one field, it resurfaces at closure, when it's far more visible and far more awkward to fix.
A habit worth watching for
The subtler version of the activity-instead-of-outcome mistake is setting a goal the team genuinely cannot measure, even when it sounds outcome-oriented on the surface. "Improve the patient experience" sounds like an outcome. It isn't reportable in a weekly status update with an actual number, which means it isn't a KPI, it's a sentiment. If a goal can't be checked with real data at the 30, 60, and 90-day marks after go-live, it needs a number attached before it goes on the charter, not after someone asks for one in a leadership review.
Practical takeaway
Before this field goes final, say the goal statement out loud to someone outside the project, Sponsor, Lead, and one Key Team member, separately, and ask each of them what "done" means. If you get three different answers, the sentence isn't specific enough yet, no matter how finished it sounds on the page. Fix it until all three answers match, because that's the actual test this field has to pass, not whether it reads well, but whether it means the same thing to everyone who has to act on it.
What comes next
With a single, measurable goal and one named deliverable in place, the next question is when. That's Field 5, Schedule, and it's where ungrounded optimism about timelines meets the gates and milestones that actually hold a project accountable to the date on this charter. That's Part 5 of this series.
Download the Goal Statement & Primary Deliverable Quick-Reference
Ready to put this into practice? Use the Goal Statement Quick-Reference as a simple one-page guide to the five-part test, the activity-versus-outcome check, and a fill-in-the-blank template for writing your goal statement and primary deliverable on your next charter.
