DECISION FRAMEWORK

Be stubborn about the objective. Be flexible about the method.

I don't believe the first answer is always the right answer.

When a problem lands in front of me, my first instinct is not to accept the choices exactly as they were handed to me. I want to understand what is actually happening: What are we trying to accomplish? What is stopping us? Which parts are facts, and which parts are assumptions? What can change, and what truly cannot?

Sometimes the limitation belongs to the current solution, not to the result we're trying to achieve.

DIAGNOSE BEFORE YOU SOLVE

A number can tell me something is wrong. It cannot necessarily tell me why.

If labor hours are over estimate, I don't immediately assume the crew is inefficient. Was the estimate right? Have we done this work before? What did comparable projects require? Are we losing time to travel or access? Are people waiting on material? Is there rework? Is the sequence wrong? Is the crew properly matched to the work? Did actual conditions match what we assumed when the job was estimated?

I go back to the baseline and find where reality departed from what we expected. Until I understand that, I'm guessing. And I don't want to spend money fixing the wrong problem.

CHALLENGE THE ASSUMPTIONS

One of the easiest mistakes in problem solving is accepting the problem exactly as somebody presents it.

If somebody tells me a solution costs $8,000, I want to know why. Did we get competitive pricing? What are the alternatives? Do we already own something that will do the job?

If somebody tells me moving material will shut a six-person crew down for a day, I want to know why those six people have to move it. Is somebody else available? Can another crew help? Is somebody on stand-down? Can it happen at another time? Can we reduce what needs to be moved?

The first workable answer is not automatically the best answer.

DON'T GET MARRIED TO YOUR OWN IDEA

Sometimes my first idea is wrong. That's fine.

If I think adding another employee might reduce overtime, I'll look at the numbers. If the numbers don't support it, I drop the idea. I'm not trying to prove that my first answer was right. I'm trying to get the project right.

New information should be allowed to change the decision. If the facts change the problem, the solution should change with them.

LOOK BEYOND THE IMMEDIATE PROBLEM

A project does not operate in isolation. Sometimes the resource I need isn't assigned to my project. Maybe another crew is waiting on material. Maybe equipment is sitting unused at the yard. Maybe another superintendent has enough capacity to help. Maybe the company already owns something we're preparing to rent.

At an operational level, I have to look beyond one project and ask where the organization's available resources can create the most value right now.

That's different from managing one crew. It's managing the operation.

PROTECT PRODUCTIVE WORK

When I have to make a change, I want the disruption to land on the smallest part of the operation possible.

If six people are producing, I don't want to stop all six if one person can handle the correction. Fix the problem without creating another unnecessary problem in the process.

PRIORITY CAN CHANGE

The biggest problem this morning may not be the biggest problem this afternoon.

If a project is behind schedule, it gets my attention. But if the superintendent has a credible recovery plan, the resources to execute it, and a history that gives me confidence in his judgment, I don't need to stand over him. I can move that project from active intervention to controlled monitoring.

I'll still check the trend. Are we gaining ground? Are the assumptions in the recovery plan holding? If the answer changes, my priority changes with it.

Leadership isn't deciding what matters once. It's continually deciding where your attention creates the most value.

ACCOUNTABILITY FOLLOWS VISIBILITY

You don't necessarily have to create a problem to become responsible for addressing it.

Maybe estimating missed something. That's an estimating issue. But if a superintendent has been living with a major productivity loss for weeks and never questions why, that becomes a superintendent issue too.

Once you can see a problem and have enough authority to do something about it, you have some responsibility for what happens next.

DISTINGUISH A BAD EVENT FROM A BAD PATTERN

People decisions require the same diagnosis as operational decisions.

If a superintendent is struggling, I don't immediately conclude that he's a bad superintendent. Is he new? Is this his first major project? Has he performed well before? Is every project like this, or is this the exception? What support has he received? What is actually happening on the project?

If somebody with a strong history suddenly struggles, I would rather understand why before making a decision that could damage his career. I may send another experienced superintendent in to assist, mentor, and evaluate. That protects the project while giving me better information.

The higher the consequence of being wrong, the more important it becomes to reduce uncertainty before making a decision that is difficult to reverse.

BE STUBBORN ABOUT THE OBJECTIVE

BE FLEXIBLE ABOUT THE METHOD.

If the first method doesn't work, change the method. Change the sequence. Change the resource. Change the timing. Change the logistics. Challenge the cost. Challenge the assumption. Look for another option.

A failed solution does not automatically mean the result is out of reach.

But stubbornness has a limit. Sometimes there really is no viable path. The constraint may be technical, contractual, financial, safety-driven, customer-controlled, or simply outside your authority.

When the facts establish a true dead end, accept the facts. Continuing to consume time, money, manpower, and credibility after that point isn't determination. It's waste.

THE DECISION STANDARD

When something isn't working, I want to understand what we're trying to accomplish, establish the facts, go back to the baseline, and find where reality departed from the assumption. Then I identify the actual constraint, challenge the assumptions around it, look beyond the immediate project for resources and alternatives, and generate more than one path when possible.

I compare cost, risk, schedule, people, customer impact, and long-term consequences. I protect productive work. Then I make the decision, give capable people room to execute it, and monitor whether it is producing the expected result.

If new information proves the decision wrong, I change it. If every reasonable path has been exhausted and the remaining constraint is real, I accept it and move forward.

THE GOAL ISN'T TO PROVE I WAS RIGHT.  THE GOAL IS TO PRODUCE THE BEST OUTCOME THE CIRCUMSTANCES WILL ALLOW.

Be stubborn about the objective.

Be flexible about the method.