Delay Management And Scaling Programs

This is not a scheduler role. It’s a build-the-function role.

I’m not sure if it’s for you, but we’re supporting a major data center developer in Phoenix who is scaling fast and wants their scheduling function built from the ground up.

This role is for a senior scheduler or scheduling manager who wants ownership.

You won’t just manage a master schedule.
You’ll define the standards, set the process, and operate at the owner level while overseeing the GC.

Just imagine being the person who establishes how these projects get planned and delivered moving forward.

A few constraints upfront:

Phoenix area based
U.S. citizen or Green Card holder

If this sparks curiosity, reach out at [email protected] or DM me on LinkedIn and tell me why this type of role matters to you. And if someone else comes to mind, please forward this along.

❝

If there’s one quality I believe defines wisdom in the workplace more than any other, it is the capacity for holistic or systems thinking that allows one to get the “gist” of something by synthesizing a wide variety of information quickly. Part of this is aided by the skill of pattern recognition that helps you come to hunches faster that account for the bigger picture. And this is where age gives us the indisputable upper hand: the longer you’ve been on this planet, the more patterns you’ve seen and can recognize.

Wisdom at Work by Chip Conley

Build Scheduling as a System, Not a Set of Schedules

Most construction schedules fail for one simple reason:
they’re treated as individual timelines instead of parts of a larger system.

Bars, dates, and logic links are not the schedule.
They’re just the visible output of something much bigger.

The real value of scheduling comes from the system behind it—the people, processes, tools, standards, and feedback loops that determine whether schedules are reliable, comparable, and useful under pressure.

This applies at every level:

A project trying to hit a milestone
A program delivering similar work repeatedly
A portfolio allocating limited resources across priorities
A company trying to scale predictability, not heroics

The mindset shift

Average organizations try to build better schedules.
Mature organizations build better scheduling systems.

A schedule itself is a statement of intent. It defines what outcome you want: a finish date, a sequence, a set of milestones. In that sense, a schedule behaves like a goal.

The scheduling system is everything that determines whether that goal is achievable—again and again.

❝

“Goals are about the results you want to achieve. Systems are about the processes that lead to those results.”

James Clear

At an organizational level, the scheduling system includes things like:

How schedulers are hired, trained, and mentored
What standards exist for logic, updates, and reporting
Which tools and platforms are used—and how consistently
How QA/QC is performed before schedules are trusted
How schedule data feeds decisions at the project, program, and portfolio level

A schedule can be technically correct and still fail.
A weak scheduling system guarantees that it eventually will.

What less-mature scheduling organizations tend to do

Organizations early in maturity tend to focus narrowly on the artifact:

“Is this schedule logic correct?”
“Did the update get submitted?”
“Why is this one project late?”

Responsibility often sits with individuals, not the system. Success depends on who built the schedule, not on how the organization operates.

This produces isolated wins but inconsistent outcomes.

What mature scheduling organizations do differently

More mature organizations ask a different question:

“What is our scheduling system consistently producing?”

They look for organizational feedback loops, not just project-level ones, such as:

Late owner decisions → rushed updates → loss of trust in schedule data → executives stop using schedules
Inconsistent standards → noisy portfolio data → leadership decisions based on anecdotes instead of trends
Undertrained schedulers → overconstrained schedules → false confidence → surprise delays

These patterns show up across projects because they originate upstream, in how scheduling is staffed, governed, and supported.

This is systems thinking applied to scheduling operations.

❝

“A system is an interconnected set of elements… people, processes, and structures… that is coherently organized to achieve a purpose.”

Donella Meadows

When you step back, a scheduling operation clearly has:

Elements: people, tools, data, standards, reviews
Interconnections: handoffs between PMs and schedulers, update cycles, reporting pipelines, decision forums
Purpose: enabling predictable, decision-grade outcomes

When one of these breaks down, projects feel the impact, even if the schedule file itself looks fine.

The crucial scheduling tactic (at scale)

Build scheduling systems, not just individual schedules.

That means spending as much time on how scheduling works as you do on what a schedule says.

In practice, this looks like:

Designing standard data structures so schedules can roll up cleanly
Investing in QA/QC so leadership trusts what they see
Creating feedback loops where lessons from one project inform the next
Using historical data to shape future schedules, not just explain past ones

This is true at every level:

Projects benefit from clearer expectations and fewer surprises
Programs benefit from repeatability and learning
Portfolios benefit from comparable, decision-ready data
Companies benefit from reduced reliance on hero schedulers

❝

“A common rule we should always try to heed is to detect and fix any problem in a production process at the lowest-value stage possible.”

Andrew Grove

Scheduling is one of the earliest, lowest-cost places to see problems forming—if the system is designed to surface them.

A better litmus test

Instead of asking whether a schedule is “good,” ask this:

❝

If your best scheduler left tomorrow, would your organization still produce reliable schedules six months from now?

If the answer is no, the issue isn’t the schedule.
It’s the system behind it.

Because in the end, schedules don’t create predictability.
Scheduling systems do.

And the organizations that understand that stop chasing dates—and start shaping outcomes.

How to Use Projects in ChatGPT, Claude and Gemini

Stop Repeating Yourself to AI

Every time you paste your background into ChatGPT, you're wasting time.

There's a better way.

AI "Projects" let you store your context once and use it forever. No more explaining who you are, what you do, or how you want things formatted.

I've been using Projects across ChatGPT, Claude, and Gemini for months. Here's how to make them actually work.

What Projects Actually Do

Projects keep your files, instructions, and conversations organized in one place. The AI remembers your preferences across every chat in that project.

Think of it like this. Instead of handing a new intern the same project briefing every morning, you give them a desk with everything they need. They show up ready to work.

That's what Projects do for AI.

ChatGPT Projects: Make Your Context Real

ChatGPT Projects group your chats and files so the model stays on topic.

Here's how to set one up that actually works:

Write a one page README. Include your goal, your audience, what you don't want, and what "done" looks like. This stops the AI from guessing.
Pin your format rules. Tell it exactly how you want outputs. Something like "Give me 5 bullets first, then a short recommendation. Cite sources when you use my docs." This stops the model from reinventing structure every time.
Add 2 or 3 golden examples. Find outputs you love and drop them in. AI imitates patterns extremely well when examples are always present.
Keep your prompts short. Instead of pasting background repeatedly, just say "Using the project brief and style guide, draft section 2 with three options."

Your prompts get shorter. Your answers get more consistent. The project carries the heavy lifting.

Claude Projects: Treat the Knowledge Base as Gospel

Claude Projects give you a workspace with your own chats and uploaded documents.

Here's the key detail. Context doesn't automatically share across separate chats unless it's in the project knowledge base.

So the best habit is maintaining two short documents:

Project Rules. Your role, tone, structure, and constraints. Keep it tight.

Decision Log and Glossary. Terms you use, choices you've made, current assumptions, and links to your source docs.

Claude also lets you set project instructions that apply to every chat. If you collaborate with others, you can share projects with controlled permissions. Everyone uses the same context and standards.

Gemini: Build Projects with Gems and NotebookLM

Gemini doesn't have a full "Projects" feature yet. But you can build the same behavior.

Gems are custom experts where you save detailed instructions for repeatable work. Think of them as your AI's personality and rules.

NotebookLM is your knowledge base. You provide the documents, and the AI works from them. It stays grounded in your sources.

A practical Gemini project stack looks like this:

Gem equals behavior. Your role, format, tone, and rules.

NotebookLM notebook equals knowledge base. Your briefs, docs, meeting notes, and links.

Gemini Deep Research equals fresh synthesis when you need current information.

Google has been reportedly building a dedicated Gemini Projects workspace. But it's not fully available yet. Build with what works today.

The 10 Minute Setup That Works Everywhere

This recipe applies to ChatGPT, Claude, and Gemini.

Name the project with a single outcome. Not "Marketing" but "Q1 Campaign Launch." Not "Construction" but "Hyperscale Fit Out Schedule."
Add instructions. Define your role, your audience, your output template, and your constraints.
Upload 3 to 7 high signal docs. Only the ones that matter. Quality beats quantity.
Create a Decision Log. Update it every time you tell the AI "yes, that's right." This becomes your project memory.
Add 2 great examples. Show the AI what good looks like.
Prompt smaller. Ask for one section, one decision, or one comparison at a time.

How Projects Go Wrong

I've watched people sabotage their own setups. Here's what to avoid.

Overstuffing the knowledge base. When you dump everything in, the model averages conflicting information. It gives you mush. Curate hard.

Stale decisions. Your outputs start regressing because the AI is working from old assumptions. Keep a dated change log.

Vague instructions. You'll still fight formatting every single time. Specify structure and length up front.

Mixing unrelated work. Create a new project instead of a new thread. Different workstreams need different context.

The Bottom Line

Projects are the difference between AI that helps and AI that frustrates.

Set up your context once. Reuse it forever. Stop repeating yourself.

Your future self will thank you.