Don’t Let the Objective Statement Stop Your Project

If you’ve ever taught Lean Six Sigma or coached a new Green Belt, you’ve probably watched someone stare at the Project Charter for several minutes before asking the inevitable question.

“So…how am I supposed to know what my objective is before I’ve even started the project?”

It’s a fair question.

In fact, it’s probably the hardest part of writing a charter.

The objective statement asks us to describe where we want the process to end up. But at the beginning of a project, we know the least we’ll ever know. We’ve identified a problem. We’ve gathered some background information. Maybe we’ve looked at a few reports. But we certainly haven’t analyzed root causes or tested solutions.

And yet we’re expected to predict the future.

No wonder new practitioners feel uncomfortable.

I’ve even seen people become almost paralyzed by it. They’re afraid that if they write, “Reduce defects by 50%,” someone will hold them accountable if they only achieve 35%. Others swing the opposite direction and write objectives so vague that they’re almost meaningless.

Neither approach is helpful.

The reality is that the objective statement is an educated estimate, not a guarantee.

Meet Sarah

Let’s imagine Sarah, a newly certified Green Belt.

Her company manufactures industrial valves, and she’s been assigned a project to reduce leaks found during final testing. The current defect rate is 8%, and everyone agrees it’s a problem.

Her Champion hands her the charter and says, “Go ahead and fill in the objective.”

Sarah freezes.

How much should the defects be reduced?

• To 6%?
• To 4%?
• To 1%?

She has absolutely no idea.

She’s never managed this process. She hasn’t collected data. She hasn’t mapped the process. She certainly hasn’t performed any statistical analysis.

So how could she possibly know?

The answer is…

She can’t.

And that’s perfectly okay.

Let History Be Your Guide

One of the first places I encourage practitioners to look is historical performance.

Ask questions like:

• Has this process ever performed better?
• Was it capable at one time?
• Did something change?
• Is there evidence that the process used to meet customer requirements?

Suppose Sarah pulls two years of historical data and discovers something interesting. For nearly eighteen months, the leak rate averaged around 2%.

Then a new supplier was introduced, several experienced technicians retired, and production increased significantly. Over the next few months, the defect rate climbed steadily until it reached today’s 8%.

Now Sarah has something to work with. She doesn’t need to guess.

A reasonable objective might simply be to restore the process to its previous level of performance.

Her objective could read something like:

“Reduce valve leak defects from the current average of 8% to approximately 2%, restoring the process to its historical level of performance.”

Notice the wording.

She’s not promising perfection.

She’s using evidence.

What If the Process Has Never Been Good?

Sometimes history doesn’t help.

Maybe the process has always struggled.

Maybe the company has accepted poor performance for years because “that’s just the way it is.”

This is where capability analysis becomes incredibly valuable.

If the process has never been capable of consistently meeting customer requirements, expecting perfection probably isn’t realistic.

Instead, estimate a logical improvement based on what the data suggests is achievable.

• Perhaps moving from a process capability index of 0.65 to 1.00 is realistic during this project.
• Maybe defects can reasonably be reduced from 12% to 7%.
• Perhaps cycle time can be reduced by 20%.

The important part isn’t predicting the exact final number. It’s selecting a target that is thoughtful, evidence-based, and reasonable, given what you know today.

Remember What Phase You’re In

One mistake I see is treating the charter like a legal contract.

It isn’t.

When the project begins, you’re operating in the Define phase.

At this point, your understanding of the problem is still fairly shallow.

By the time you’ve completed Measure and Analyze, everything changes.

• You now understand the process.
• You’ve identified the root causes.
• You’ve separated opinions from facts.
• You know which variables actually matter.

And when you reach Improve, you’re no longer guessing about what can be achieved. You’re making decisions based on evidence. At that point, it’s entirely appropriate to revisit the Project Charter with your Champion.

• Maybe your original objective was too conservative.
• Maybe it’s no longer realistic because you’ve uncovered constraints nobody knew existed.
• Maybe you’ve identified an opportunity far larger than anyone imagined.

That’s not failure.

That’s learning.

In fact, I’d argue that refusing to revisit the objective after learning so much is the real mistake.

Back to Sarah

As Sarah worked through Measure and Analyze, she discovered that nearly three-quarters of the leaks were caused by inconsistent torque settings during assembly.

The fix wasn’t particularly expensive.

It involved updating the torque procedure, recalibrating tools, and providing refresher training.

Before implementing the improvements, Sarah realized something.

Getting back to 2% wasn’t just possible.

The data suggested they could consistently operate below 1%!

She met with her Champion, walked through the analysis, and together they updated the objective statement to reflect what the project had actually uncovered.

The charter evolved because the team’s understanding evolved.

That’s exactly what should happen.

The Objective Isn’t the Destination, It’s the Starting Point

A Project Charter is intended to provide direction, not predict the future with perfect accuracy. At the beginning of a project, you’re making the best decision possible with limited information. Use historical performance whenever it’s available. If the process once performed well, restoring it is often a logical objective.

If the process has never been capable, use capability analysis and the available data to establish a reasonable estimate. Then, as the project progresses and your understanding deepens, don’t be afraid to revisit the objective with your Champion.

That’s not moving the goalposts. That’s what good problem solvers do. After all, continuous improvement isn’t just about improving processes. It’s also about improving our understanding of the problem itself.

---