Zach Thomas

Network Engineer

Zach Thomas

Network Engineer

Beginner’s Guide to IT Project Management: My Real-Life Journey

by | Jan 8, 2026 | Engineering Growth, Project Management

Why I’m Learning IT Project Management

I’ve worked in IT and networking most of my life, starting back in middle school. Technology has always made sense to me — but organizing my work hasn’t always been natural.

That’s what pushed me to learn IT project management. As someone with ADHD, staying focused and on track can be a challenge. I work best when there’s structure, clarity, and a system to follow — and project management provides that if applied correctly.

Project management matters in IT because modern businesses rely heavily on technology, and projects are constantly happening: upgrades, deployments, development, security updates, and more. Without planning and management, projects can quickly go off track. Learning how to manage them is essential for keeping technology running smoothly and supporting business goals.

What IT Project Management Actually Means

Before I really understood project management, I pictured it as a mix of checklists, tasks, scheduling, and planning meetings. And while those exist, they’re just the surface layer.

IT project management is about making sure the right work gets done, in the right order, by the right people, without everything falling apart. It’s about creating clarity in chaotic environments.

  • Figuring out what needs to be built or changed
  • Breaking work down into manageable steps
  • Ensuring team communication
  • Adapting when plans inevitably change

Good IT project management isn’t about control — it’s about coordination, keeping projects moving even when requirements shift, bugs are discovered, deadlines change, or priorities are swapped.

Why IT Project Management Feels Different

IT project management is challenging not because the concepts are complicated, but because the environment itself is chaotic.

The biggest challenges I face include:

  • Time management
  • Motivation
  • Feeling overwhelmed by tasks
  • Keeping up with timelines
  • Handling constant interruptions or changes

IT projects rarely move in straight lines. Requirements shift, priorities change, outages happen, and stakeholders often request last-minute updates. Meanwhile, daily operational work continues.

Compared to fields where you can follow a step-by-step plan, IT feels more like juggling objects that change shape mid-air. Project management is the framework that brings order to this chaos.

Early Attempts at Tools and Systems

I tried everything: sticky notes, paper, whiteboards, task charts, even the Eisenhower Matrix. They worked briefly but collapsed when the work became shared. I was the only one following the system, coworkers didn’t check it, and I quickly got lost.

That’s when I realized: tools alone don’t fix disorganization — systems do. Tools are just containers; the real success comes from the habits and structure behind them.

In IT, shared systems are critical. Everyone needs visibility into tasks, priorities, and updates. Without that, even the best tools fail.

Core Concepts: IT Project Management Building Blocks

Understanding these core concepts helps navigate IT projects without getting buried by chaos:

  • Scope – Know exactly what needs to be done. Clear goals prevent overwhelm.
  • Time / Deadlines – Break projects into small, time-boxed chunks to make deadlines manageable.
  • Tasks / Priorities – Not all tasks are equal. Some are urgent, some important. Prioritize to keep moving.
  • Communication – Share progress and clarify expectations to prevent losing track when team members aren’t aligned.
  • Adaptability – Projects rarely go perfectly. Interruptions and changes are normal; learn to adjust without stress.
  • Tracking Progress / Feedback – Quick feedback prevents tasks from getting lost and keeps motivation high.

A Real-World Example: Baking Cookies as a Project

Sometimes it helps to step outside IT to understand these concepts. Imagine baking cookies:

  • Scope – Decide the type of cookies to bake. This is your goal.
  • Tasks / Priorities – Gather ingredients, preheat oven, mix dough, portion cookies, bake, decorate. Each step matters, and some depend on others.
  • Time / Deadlines – Baking takes time. Start too late, cookies burn; too early, they’re raw. Timing matters.
  • Communication / Coordination – If baking with others, miscommunication can ruin the process.
  • Adaptability – Out of sugar? Adjust the recipe. Projects rarely go perfectly.
  • Tracking Progress / Feedback – Taste-test along the way, check timers, adjust baking as needed.

Quick Start Guide: Implementing IT Project Management Today

You don’t need a 1,000-page book to start managing projects. Here’s a simple approach anyone can implement immediately:

Step 1: Define Your Goal (Project Scope)

What it is: Your project’s “north star.”
IT Example: “Upgrade office network switches to improve speed and reliability.”
Quick Tip: Write your goal in one sentence. Split it into smaller objectives if it feels too big.

Step 2: Break Work Into Milestones

What it is: Major checkpoints or phases.
IT Example: Audit hardware → purchase switches → install → test → document.
Cookie Analogy: Prepare ingredients → mix dough → bake → decorate → share.
Quick Tip: Even 2–3 milestones make a project manageable.

Step 3: Create Tasks Under Each Milestone

What it is: Specific steps to complete a milestone.
IT Example: Audit hardware → check switch models, document connections, map devices.
Cookie Analogy: Mix dough → measure sugar, whisk eggs, combine ingredients.
Quick Tip: Keep 3–6 actionable tasks per milestone.

Step 4: Set Deadlines and Priorities

What it is: Know when tasks should finish and what to focus on first.
IT Example: Install Switch A → Deadline: Friday 3 PM, Priority: High.
Cookie Analogy: Preheat oven → Deadline: 10 min before baking, Priority: High.
Quick Tip: Use a calendar or time-blocking tool and focus on high-priority tasks first.

Step 5: Identify Dependencies and Risks

What it is: Dependencies = tasks that rely on others. Risks = things that could delay progress.
IT Example: Can’t install new switches until audit complete; vendor delays.
Cookie Analogy: Can’t bake until dough is mixed; oven may not reach temperature.
Quick Tip: List dependencies and risks ahead of time to reduce surprises.

Step 6: Track Progress

What it is: Monitor what’s done, what’s next, and adjust as needed.
IT Example: Use Trello/Jira/Notion to mark tasks as To Do → In Progress → Done.
Cookie Analogy: Check off steps: dough mixed ✅, cookies baked ✅.
Quick Tip: Pick one simple tool, review daily/weekly, adjust if needed.

Step 7: Review and Learn

What it is: Reflect on what worked, what didn’t, and document lessons.
IT Example: Which milestones were on time? Which tasks caused delays?
Cookie Analogy: Did cookies turn out as expected? Any steps to improve?
Quick Tip: Write 3–5 key takeaways and celebrate small wins.

Tools That Actually Work for IT Project Management

  • Trello / Notion / Jira – Track tasks and milestones.
  • Slack / Teams / Email – Keep team communication consistent.
  • Calendar / Time-Blocking – Manage deadlines and focus.
  • Checklists & Templates – Standardize recurring work.

Insight: One or two tools consistently used beats a dozen half-used systems. Tools reinforce a system — they don’t replace it.

Common Beginner Mistakes and Lessons Learned

  • Trying to do everything at once → Break work into chunks.
  • Relying on tools without a system → Systems matter more.
  • Ignoring communication → Share updates regularly.
  • Underestimating interruptions → Plan buffer time.
  • Letting motivation dictate progress → Habits carry you forward.

Project management isn’t about perfection — it’s about creating a framework, reducing overwhelm, and adapting when things change.

Conclusion: Why Learning IT Project Management Matters

Learning IT project management is a journey full of trial, error, and small victories. It’s not about memorizing rules — it’s about building systems, understanding core concepts, and adapting to change.

Start small, keep it simple, and gradually, the chaos becomes manageable. With the 7-step Quick Start Guide, you can implement IT project management today without a huge textbook.

What’s your biggest IT project management challenge? Share in the comments — let’s learn together!

 

Being Careful Is a Skill (Part 3)

by | Dec 19, 2025 | Engineering Growth

Why restraint is one of the hardest things to learn in networking

Early in my career, I thought being careful meant being slow.

I associated caution with uncertainty, and uncertainty with weakness. The engineers I admired seemed decisive, fast, and confident — so that’s what I tried to emulate.

What I didn’t realize then was that I was misreading what I was seeing.

Carefulness isn’t hesitation

The engineers who appear calm and decisive in production aren’t acting on impulse.

They’re acting from:

  • pattern recognition
  • experience with failure
  • well-developed internal guardrails

Their speed is the result of discipline, not boldness.

What looks like confidence is often restraint that has already done its work.

Why being careful is hard

Carefulness requires you to:

  • slow down when you feel sure
  • pause when you want to act
  • leave things imperfect for the sake of stability
  • accept that the “right” fix can still be the wrong moment

That’s emotionally uncomfortable — especially if you care deeply about quality.

It’s much easier to act than to wait.

Production doesn’t reward intention

One of the most difficult lessons I’ve learned is that production systems don’t care about intent.

They don’t know whether you were being proactive or cautious.
They only reflect outcomes.

That’s why careful engineers optimize for:

  • minimizing blast radius
  • clear change boundaries
  • reversibility
  • communication before action

These aren’t constraints on skill — they’re expressions of it.

Restraint is learned, not innate

Being careful isn’t something you either have or don’t have.

It’s built through:

  • mistakes you remember
  • outages you don’t want to repeat
  • moments where you realize confidence alone isn’t enough

Over time, those experiences harden into instinct.

Not reckless instinct — protective instinct.

What I’m practicing now

Being careful, for me, looks like this:

  • verifying state before changing it
  • assuming memory is incomplete
  • treating “no impact” as a reason to wait
  • preferring visibility over action

None of this feels flashy.

But it feels right.

A different definition of growth

Growth used to mean:

  • touching more systems
  • fixing harder problems
  • acting independently

Now it means:

  • being trusted with more responsibility
  • being predictable under pressure
  • making fewer people nervous

That’s a quieter form of progress — but a lasting one.

Closing thought

If you’re early in your career, don’t mistake speed for skill.

And if you’re further along and struggling with trust, don’t assume the answer is more confidence.

Sometimes the most advanced thing you can learn is when not to act.

That’s when careful becomes professional.

Learning to Trust Process Over Confidence (Part 2)

by | Dec 19, 2025 | Engineering Growth

What I’m changing in how I work

After reflecting on a mistake, the next question becomes unavoidable:

What do you actually do differently?

Insight without behavior change is just self-analysis.
So here’s what I’m intentionally changing in how I work.

I no longer act on “I know this”

Any time I feel that familiar confidence — the “this is obvious” feeling — I stop.

That feeling is no longer permission to act.
It’s a signal to verify.

Confidence now triggers curiosity, not action.

I separate finding problems from fixing them

I’ve stopped treating every issue I notice as something that must be fixed immediately.

    • Now, my default is:
    • identify the risk
    • document it
    • make it visible
    • schedule change intentionally

    This protects the environment — and protects trust.

    I narrate my thinking before touching anything

    I’ve learned that people can’t trust what they can’t see.

    So I’m practicing saying things like:

    “Here’s what I’m seeing.”
    “Here’s why I think it matters.”
    “Here’s what I would change — but I won’t until we agree.”

    That turns internal knowledge into shared understanding.

    I measure success differently

    Success used to mean:

      • fixing the issue

      • being right

      • making things cleaner

    Now success means:

      • no surprises

      • no emergency rollbacks

      • no unexplained outages

    Predictability is the metric.

    A quieter kind of confidence

    I still want to be good at this.

    But I’m learning that real confidence doesn’t come from acting quickly or decisively.

    It comes from trusting a process that slows you down — especially when you feel sure.

    That’s the kind of confidence I’m working toward.

    Final note

    If you’re in a similar place — where you know the technology but struggle to feel trusted with it — you’re not broken.

    You’re recalibrating.

    And that recalibration, while uncomfortable, is often the moment real professionalism begins.

    When Knowing Isn’t Enough (Part 1)

    by | Dec 19, 2025 | Engineering Growth

    A reflection on confidence, mistakes, and learning to slow down

    For a long time, I believed that being a good network engineer meant knowing the right answer.

    Knowing the command.
    Knowing the fix.
    Knowing what should be done.

    And in many ways, I did know those things.

    But knowledge alone doesn’t always translate into trust — especially in production environments where the cost of being wrong is immediate and visible.

    I learned that the hard way.

    The uncomfortable gap between knowledge and outcome

    The hardest part wasn’t making a mistake.

    It was realizing that the mistake didn’t come from rushing or carelessness.
    It came from confidence.

    I recognized the situation.
    I remembered something similar.
    I acted from memory instead of verification.

    From my perspective, I was being careful.
    From the outside, it looked like recklessness.

    That gap — between intent and impact — is where trust erodes.

    Confidence is not the same as readiness

    What I’ve started to understand is that confidence, by itself, is neutral.

    Unstructured confidence can be dangerous.
    Structured confidence is safe.

    In networking, one line of configuration can affect dozens of systems. The CLI doesn’t care how sure you feel — it only cares what you typed.

    I didn’t need more confidence.
    I needed more pause.

    The most dangerous moment

    The most dangerous moment in production isn’t panic.

    It’s comfort.

    It’s the moment you think:

    “I’ve seen this before.”

    That thought shortcuts curiosity.
    It replaces checking with remembering.

    I’ve learned to treat that moment as a warning sign — not a green light.

    Learning to leave things alone

    One of the hardest lessons for me has been this:

    Not every correct fix should be applied immediately.

    Sometimes the right move is to:

    • observe
    • document
    • communicate
    • wait

    That feels wrong when you care about doing good work.
    But restraint is part of professionalism.

    Stability matters more than cleanliness.

    Redefining what “better” means

    I used to think becoming a better engineer meant:

    • faster diagnosis
    • cleaner configs
    • quicker fixes

    Now I think it means:

    • fewer surprises
    • clearer communication
    • predictable behavior under pressure

    Being “boring” in production isn’t a flaw.
    It’s a goal.

    Closing thought

    I still care deeply about doing things right.
    That hasn’t changed.

    What’s changing is how I act on that care.

    I’m learning that growth isn’t always about adding skill — sometimes it’s about adding structure.

    And that kind of growth is quieter, slower, and easier to miss — but far more durable.